Archive index

A11y Slackers Gitter Channel Archive 13th of June 2017

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    @zakim-robot
    Jun 13 15:12
    [gokatgo] marcysutton: Currently working on an quiz authoring/playback app. Still working on getting the a11y dialed… will share when it’s released!
  2. zakim-robot
    @zakim-robot
    Jun 13 15:21

    [gokatgo] Surely this question has been asked before: tooltips vs. an app onboarding sequence located in a help button on the page?

    My goal is: better ux that…

    1. is accessible, and
    2. doesn’t annoy the user/make the user overthink.

    Currently, the users testing in the field find the tool pretty intuitive, yet there are occasional requests for more clarity.

    My team is about to discuss how to integrate better clarity for using our app, and I’d rather enter the meeting with a list of pros/cons for each scenario.

    I’m the sole UI/UX dev on the team, so getting buy-in for anything WRT UX and a11y can be challenging.

  3. [clairebones] Sometimes I do think a sequence can be more useful than a tooltip - for a tooltip to work you need to know where to hover in the first place
  4. [clairebones] though ideally (as I think you're suggesting) the user should be able to go through it more than once as not everyone will remember it all immediately
  5. zakim-robot
    @zakim-robot
    Jun 13 15:27
    [gokatgo] Agreed, @clairebones. I need to head into a meeting with articles/anything to share. It helps reduce the pushback from stakeholders that think better UX and a11y === just alt tags and passing color contrast audits. :)
  6. zakim-robot
    @zakim-robot
    Jun 13 15:33
    [garcialo] Tooltips can be fine if implemented properly.
  7. [garcialo] Once the user tries to interact with a thing, they’d get the information they need.
  8. zakim-robot
    @zakim-robot
    Jun 13 15:42
    [gokatgo] And if you’re using a screen reader? What’s the annoyance factor of hearing that tooltip over and over?
  9. [clairebones] Exactly - plus, what about users that are using keyboard or voice navigation but not screenreader technology? Will they get the tooltip?
  10. zakim-robot
    @zakim-robot
    Jun 13 16:20
    [garcialo] Yeah, it could be annoying, so would definitely recommend keeping it discrete. And yes, keyboard users would get the tooltip; it's not like it's just a title attribute. :)
  11. [clairebones] Haha I would hope not :p I just meant that if someone's using keyboard to nav through the site, how do you know if they want the tooltip or they're just focussing there on their way to their intended element
  12. [garcialo] Ah well then you could just use something like an info button. I think it probably depends on the content on whether it should be displayed always, on attention, or by request.
  13. zakim-robot
    @zakim-robot
    Jun 13 16:57
    [gokatgo] The app we’re working on is heavily form based, so that may be overkill… worth considering though!
  14. zakim-robot
    @zakim-robot
    Jun 13 17:06
    [garcialo] Something came to mind on the train this morning and want to see what others’ thoughts are. It’s pretty standard advice to programmatically associate instructional/informational text with the appropriate form field.
  15. [garcialo] In cases where there’s like a notice near the submit, I’ve suggested (and have heard others suggest) to associate that information with the submit.
  16. [garcialo] But the user could submit the form at any time using Enter. I’m thinking just having aria-describedby on Enter to that text wouldn’t be sufficient…and that any statements like that need to have a required checkbox.
  17. [garcialo] …which is also a pretty standard pattern
  18. zakim-robot
    @zakim-robot
    Jun 13 18:22
    [backwardok] seems like it would be useful to have important information for the form at the top of the form instead of at the end
  19. [backwardok] what’s the example of information that you’re providing near the submit?
  20. zakim-robot
    @zakim-robot
    Jun 13 18:36
    [mgifford] Just posted this article on how organizations can embrace accessibility (beyond WCAG 2.0): https://www.linkedin.com/pulse/building-digital-inclusion-mike-gifford
  21. [mgifford] any feedback welcome..
  22. zakim-robot
    @zakim-robot
    Jun 13 18:50
    [garcialo] @backwardok Something like the eBay registration page. I’d link it, but it’s such an ugly URL :p
  23. [backwardok] aha - mm well generally i’d prefer that those be checkboxes of agreement
  24. [backwardok] also because i’d prefer to not sign up for marketing stuff
  25. zakim-robot
    @zakim-robot
    Jun 13 19:06
    [garcialo] I agree that providing a checkbox would be better. Just wondering if having something like that be a describedby (and not a checkbox) could be considered a failure.
  26. zakim-robot
    @zakim-robot
    Jun 13 19:22
    [backwardok] feels like it’d be too easy to miss
  27. [backwardok] (but this isn’t based on any data, just a gut feeling)
  28. zakim-robot
    @zakim-robot
    Jun 13 19:28
    [stevenlambert] Pasted image at 2017-06-13, 1:26 PM
  29. zakim-robot
    @zakim-robot
    Jun 13 19:44
    [mgifford] For folks in SF on Thursday https://www.eventbrite.com/e/drupal-meetup-accessibility-and-drupal-tickets-35085848718
  30. zakim-robot
    @zakim-robot
    Jun 13 21:03
    [jhetrick] @stevenlambert I’m not aware of any exceptions based on using greyscale/inverted colors
  31. [jhetrick] either way, there are definitely some color combinations where neither dark or light text really seems to work well
  32. [jhetrick] light/dark text on blue buttons, on light/dark backgrounds
  33. zakim-robot
    @zakim-robot
    Jun 13 21:08
    [jhetrick] (fwiw, contrast checker says the black text passes, but the white text fails)
  34. zakim-robot
    @zakim-robot
    Jun 13 22:35
    [stevenlambert] ya, i think the wite looks better for me than black
  35. zakim-robot
    @zakim-robot
    Jun 13 23:08
    [jamesn] JOY. My work has ublocked slack :)