On the plus side, I get to go Iron Man and answer a potential “when did you become an expert on the Grid Layout spec?” question on Friday with “Last night.”
[dean] Bumping my question ;) - brand team have two colours which pass WCAG AA contrast & color blindness…. except for the 0.01% with Tritanopia. Any advice?
Are there actually specific tests for the color blindness? I've always taken screenshots and passed it through online tools and manually looked at the results to determine if they worked well enough.
I developed it with a specific use in mind - on our site when you are browsing products, if you click a filter such as 'blue', a new result set of products replaces the current view.
This definitely works for that use case. I just think that you may get more usage if you added something that made it work with elements that are visually on a page as well. Yes, a dev could simply add the necessary ARIA attributes, but there are a lot of devs that don't know enough about that stuff but see a library that they can plug in to make it work better for screen readers they'll use it.
Basically, if the id already existed on the page use that and the text inside as a message (if one wasn't already there). And again, that's just a suggestion that may get it used more. Your use case definitely has value, and seemed to work for me in my testing.
So I'm reading the spec for progressbars and it looks like they're "labelable" elemnets like inputs... yet all the examples I'm seeing are using divs or p's or whatever with aria-labelledby
This plugin that lets devs create messages on the fly is great. I have a filterable portfolio on my site, and would like to alert screen reader users when the results change after they activate a particular button. Thanks!
I wonder if VO today still needs a progressbar to be focusable for it to reach the value... someone mentioned in their comments/docs that it was necessary, but they didn't state which version of VO or what year the progressbar example was created...
[evanleach] I’ll use an example to ask my question. An event organizer creates a ticket on Eventbrite and we name it 'General Admission’ by default. If the user clears this required field we could A) reveal an error state immediately while the field is in focus, but empty, or B) wait until they tab out or move focus to introduce the error state. Is there a best practice in place for accessibility?
On our forms, we wait until the user tabs out - as the user could be correcting an item, and you don't want to error until they are done with the field
Here's a demo of our basic form standards: https://jsfiddle.net/jasonday/zeg8oqag/ - validation on focusOut and on submit. Errors are associated with field using aria-describedby, aria-live region at the top of the form
[evanleach] I agree with you in terms of usability, but is there a difference between approaches when using a screen reader? Will the error state be presented to the user before accessing the form field below?
depends on the screenreader/browser combo - using the aria-describedby technique, the error is announced as it is associated with the form field on tab out, but I think this is not true for every combination
but even from an a11y pov, you can be too assertive or overly verbose - you don't want to error a user on field entry until they are done with the field
but we do actively validate if a field is already in error - if a user corrects a field in error, we validate the success of the field even if they haven't tabbed out
so for example...a user enters an invalid format for an email and tabs out; an error presents, they go back into the field and correct the formatting error - as soon as the field is valid, we remove the error state
[evanleach] In the demo you provided you have inline help zip code: ‘U.S. zipcodes only’. When the field is in an error state, the help content is no longer visible. I’ve seen sites like Etsy use popover error states on focus only, preserving space for inline help. Would a screen reader pick up on both the error state and help text in this case? Would maintaining both help in terms of accessibility?
ALthough the helper text is no longer visible, it is still associated with the field, so both the helper text and error state are announced by the screenreader
[evanleach] I agree. I was primarily concerned with how both would be interpreted by a screen reader. Since they’re both announced I’ll move towards something a bit sleeker.
[evanleach] We’re overhauling our styleguide currently and it’s really important to us that it’s accessible from the beginning. I’m sure I’ll be back with more questions :slightly_smiling_face:
i've been working on our pattern library for a while now, ensuring a11y, and it's a lot of work - glad to hear you guys are working it in in your revamp
Gitter Channel Archive 11th of May 2016
