RAP and Accessibility / Screen Reader
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.
ARIA stands for Accessible Rich Internet Applications, and is a W3C recommendation created by the Web Accessibility Initiative group.
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 Composite.
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.
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.
Interestingly, as I understand the WCAG, they do not require web developers to ensure that their application actually works with any existing screen reader. So in theory the degree of support by any given browser/reader combo may not even be relevant (from a legal point of view), only that the guidelines are followed and a future AT has the potential to work with it correctly. I guess this would be acceptable for applications that are expected to be in use for many years to come. But if you know that in the near future an actual disabled person will be required to use your application, you should probably ensure that it plays nice with at least one screen reader. (I would recommend ChromeVox, which has the benefit of providing a JavaScript API that can be used directly if everything else fails.)
