As I mentioned in my previous post about RAP and Selenium, EclipseSource offers a commercial Add-On that adds WAI-ARIA support to RAP. While we use it mainly for UI-Tests, that’s not really the purpose of ARIA.
It defines a set of HTML attributes intended to provide Assistive Technologies (AT, mostly screen reader) with enough information to work with modern day Internet applications. You see, traditional static websites based mostly on links, tables, logical markup and forms work fine with most screen readers. But changing content and elements that convey their purpose by styling are pretty much a mystery to them. Most RIA can therefore not be operated by users that are visually impaired.
It’s important to note that adding ARIA attributes to your web application does not automatically make it accessible. There is another W3C recommendation for that, the Web Content Accessibility Guidelines (WCAG), also created by the WAI group. However, ARIA support is very likely required if you want to your RIA to be able to fulfill the WCAG. (ARIA is specifically mentioned in the “Understanding Success Criterion XYZ” WCAG notes). WCAG compliance is occasionally required by government institutions, NGOs, or larger enterprises.
The RAP Aria Add-On automatically renders all ARIA attributes that can be derived from the class and state of a widget, like a checkbox being a checkbox (and not just a
<div> element), and whether it is checked or not. As of RAP 2.3, the application developer can also set some additional ARIA attributes on a widget, like a label for an image-only
Button, or a landmark role for a
It’s been a while that I tried any screen reader with RAP, so I picked three to see how they would perform with and without ARIA attributes. Specifically I tested:
Without ARIA, none of them did anything really useful, as expected. Jaws was the only one to associate a
Text with its preceding
Label, but it also blocked some key events when focusing other widgets, making it impossible to press buttons using the space bar. That’s because screen readers don’t only present the user what’s on screen (using either speech synthesis or a Braille terminal), they also define a whole bunch of keyboard shortcuts to navigate a website without a mouse. In this case Jaws didn’t know that the website “needed” the key event (assuming it was just a passive element) and consumed it itself.
Activating the ARIA Add-On and setting a couple of custom ARIA-attributes (mostly “aria-label” and “aria-labeledby”) improved the results considerably for all tested readers.
<iframe src="//player.vimeo.com/video/96504639" width="800" height="410" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe> <p><a href="https://vimeo.com/96504639">Watch on Vimeo</a></p>
All readers recognized the role/type of the widgets I tried (even though NVDA reported push buttons as toggle buttons), and announced (if provided) their associated label. Jaws now allowed me to push a button with the space bar. ChromeVox worked great except when focusing a
Spinner, which actually caused it to throw an exception.
The results varied more regarding widget state and content, which were sometimes reported incorrectly or not at all when changing at runtime. More complex widgets like
Table also worked only in some reader/browser combinations, which didn’t surprise me. ARIA has graduated from “Proposed Recommendation” to “Recommendation” just a few months ago, so support for it is likely still improving in both browser and screen reader software.