WAI-ARIA is WAY COOL! In part two of the three-part series on accessible form validation and usability enhancements we’re going to use WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) to communicate information to screen reader users only.
Limitations of ARIA
ARIA only works on some of the latest screen readers and browsers. It does not work with all AT (Assistive Technologies). There is no support for speech recognition software such as Dragon NaturallySpeaking. Window-Eyes and ZoomText have limited support.
Derek Featherstone (@feather) has an excellent blog post on A List Apart titled ARIA and Progressive Enhancement where he documents ARIA support on Window Eyes & ZoomText. There are also good ARIA coding techniques and live form examples.
Enhancing Forms with ARIA
Sometimes developers use color alone to alert users that required fields are not filled. DON’T DO THIS! What you should do to indicate a required field is to place text in the label that says so. Many times you see a red * or the text (required) placed in the label. This is the recommended approach. Other recommendations involve creating a star graphic and placing it in the label with alt=”Required”. This works as well but it is buggy in OS X Lion where the alt attribute is not announced in a label.
By default NVDA will not speak an asterisk * as “star”. VoiceOver & JAWS both say “star”. NVDA users can adjust their Symbol Pronunciation settings to force * to be spoken by setting the Level to “some” but not all users are aware of this feature and will usually be running on default settings. By placing the aria-required=”true” attribute on all required fields NVDA will now announce they are required at the default settings. VoiceOver and JAWS will speak the star and the required attribute.
The easiest enhancement is to add the aria-required=”true” attribute to all required fields in your form.
Below is a screenshot of the VoiceOver Caption Panel on OS X Lion which provides an excellent way to visualize ARIA/screen reader output if you’re deaf or hard of hearing or don’t want to annoy others in the room with your computer speaking everything out loud. I think it would be cool if iOS could do this as well!
Don’t worry about having the HTML5 required attribute and the aria-required=”true” attribute and causing repetition. All the screen readers I’ve tested only speak required once. Here aria-required is your fallback for browsers who do not support HTML5 like Internet Explorer. This way screen readers which support ARIA will speak the ARIA attribute when used with IE and ignore the HTML5 attribute.
ARIA Techniques for WCAG 2.0
WAI-ARIA 1.0 Authoring Practices
Other ARIAs for Consideration
How do assistive technology users navigate forms? Do they tab through the inputs like I do to quickly fill the fields out with the keyboard? Do they use their arrow keys to go down through the fields and the text between the fields? Or do they use other screen reader shortcuts like the F key for form fields?
In most of my experience testing forms and receiving feedback from others in the industry, tabbing through forms is the most popular interaction method. This is why I recommend placing all instructions and errors in the labels. As the user tabs through they would hear all instructions spoken by a screen reader.
What if the instructions to complete a form field are just really long and you’d rather not include them all in the field’s label? Well if the user’s AT & Browser have support for ARIA you could instead include those long instructions above or below the field and then point to them with the aria-describedby attribute causing the supported screen reader to speak those instructions after the label.
ARIA Techniques for WCAG 2.0
If you are using explicit labels and aria-describedby then there should not be many reasons to need to use aria-labelledby on form fields. Marco Zehe has a good example of where aria-labelledby could be useful on forms. Easy ARIA tip #2: aria-labelledby and aria-describedby. The example illustrates a problem where a text input field might be placed in the middle of a sentence but it needs to be labelled by the first part of the sentence, the input’s value itself, and the final part of the sentence.
aria-label is meant to be used in cases where a text label is not visible on the screen and a visual tooltip is not desired like when using the title attribute.
In the second version of the ARIA demo form I’ve used the aria-describedby attribute as a replacement for placing input formatting instructions in the label and positioning it below the form field with CSS. Instead of using visually hidden labels with CSS I used the aria-label attribute to label inputs that do not need a visual label like when a phone number is split into three fields.
Final Thoughts on These Other ARIAs
In these other ARIAs for consideration I’ve only been talking about their usage on forms, however, they are many times meant to be used to label and describe “desktop-like” HTML widgets that have been built using non-form tags such as divs and list tags. For more information read: Using the aria-labelledby attribute & Using the aria-describedby attribute from the Mozilla Developer Network.
Last Steps – Add jQuery Validation
In the last blog post we’ll add the final layer of client-side form validation using the jQuery Validation Plugin and tweaking its settings to maximize the accessibility and usability of our form for all users on all devices. It will even work for IE 6!
Links to all three posts in this series:
- Accessible Client-side Form Validation with HTML5
- Accessible Client-side Form Validation with HTML5 & WAI-ARIA
- Accessible Client-side Form Validation with HTML5, WAI-ARIA, & the jQuery Validation Plugin
So what do you think about these WAI-ARIA form enhancements? Would you take the approach a different way?
Do you think all instructions, cues, input formatting requirements should be placed in the label? Or would that make the labels too big so longer instructions should be in adjacent text and pointed to with aria-describedby?
Would you rather just add tabindex=”0″ to the instructions to put them in the default tab order and keep the labels as small as possible? Are you a big fan of the title attribute and would rather put everything in there instead of using ARIA?
A lot of forms accessibility practices are up for interpretation and debate so I’d love to hear your thoughts and feedback in the comments!
Let me know if you have any suggestions for improvement or find any mistakes. Leave a comment below or send me a message on Twitter @pauljadam.