The Accessibility of WAI-ARIA

Web developers interested in accessibility issues often discuss WAI-ARIA, an upcoming W3C candidate recommendation aimed at making web applications more accessible to blind and visually impaired users. But, can we recommend WAI-ARIA without reservation?

The accessibility community has welcomed the development of WAI-ARIA. Clearly, there are many benefits for screen reader users. Previously, when webpages were dynamically updated, screen reader users were unaware that something had changed, or else were thrown back to the top of the page. Now, WAI-ARIA can inform the screen reader about dynamic changes. We can make complex custom widgets—such as pulldown menus, tabpanels, hierarchical trees, or sliders—accessible by mapping their elements to the roles, properties, and states defined in the standard and supported by the system’s accessibility API—provided that users have recent versions of browsers and screen readers that support the standard.

Many users, however, have no access to the latest and greatest technology. Therefore, accessibility testing is typically based on software that “users out there” are likely to encounter at the workplace.

A benchmark for accessibility testing#section2

This is why the German BITV-Test (BITV is the German federal regulation mandating accessible information technology) prescribes using a dated browser (currently Internet Explorer 7) that would typically be used in combination with a dated screen reader like JAWS 8 that does not yet support WAI-ARIA.

For practical reasons the BITV-Test does not involve tests with screen readers. However, its checkpoints consider the limitations of older assistive technologies. The test will lower the score for sites where authors rely on WAI-ARIA—for example, by implementing widgets in a way that makes them inaccessible for users of older screen readers such as JAWS 8.

The question remains: Should accessibility testing settle for an outdated combination of browser and assistive technology that does not yet support WAI-ARIA? Doesn’t this create a disincentive for web developers who embrace WAI-ARIA to turn the dynamic web applications that clients demand into something that may be equally usable by blind users?

We have to step back a little to answer this question. First, what do the Web Content Accessibility Guidelines (WCAG) 2.0 tell us regarding the accessibility support required by technologies like WAI-ARIA? Second, how well do today’s browsers and screen readers support WAI-ARIA? And finally, what are the practical obstacles to deploying WAI-ARIA at the workplace?

“Accessibility support” according to WCAG 2.0#section3

Simply put, “accessibility support” is a bridge with two arches. Only if both arches are present, can users of assistive technologies access all the information that is available to users without disabilities.

The first arch is the web technology used. Web designers sticking to the WAI-ARIA specification and recommended Authoring Practices can ensure that their content is potentially accessible.

Why “potentially?” Because we are still missing the second arch: Suitable user agents. Browsers and screen readers need to be redesigned or modified to be able to actually work with new web technologies. Older versions may simply fall flat.

So declaring “accessibility support” for a particular web technology is not simply a matter of finalizing the standard. We must also gauge the degree to which newer supporting user agents have penetrated a given context of use. The situation tends to vary considerably across counties, languages, and use environments. In a section on Understanding Accessibility Support, the WCAG working group and the W3C therefore

And

While a company’s IT department may ensure accessibility support for its intranet, public websites provide information to a very diverse population using a wide range of user agents and assistive technologies.

That is why WCAG 2.0 clearly states:

If we accept this “general public” as our benchmark, we find that currently, there are still many obstacles to the widespread use of WAI-ARIA.

WAI-ARIA support in browsers and assistive technologies#section4

Support for some parts of WAI-ARIA, such as document landmarks, is already quite good in later versions of browser and screen readers. However, many problems remain.

Uneven level of support across assistive technologies#section5

WAI-ARIA support is still patchy in many screen reader/browser combinations out there, see, for example, the (slightly dated) WAI-ARIA tests on code talks. The sheer number of makes and versions of browsers and assistive technologies makes it hard to gauge the given level of support. And providing workarounds for some known screen reader bugs can make life harder for users of other, more compliant browsers and screen readers.

Blind users without WAI-ARIA support may simply not recognize a web widget if its WAI-ARIA role is not exposed. Take a tab panel implemented according to WAI-ARIA best practices. The screen reader will not tell users that they have just entered a tab panel and can now use the arrow keys to move between tabs. So users are likely to tab on beyond the tab panel’s content. And the scripted focus changes for arrow key navigation between tabs may just not work: entire sections under tabs can become inaccessible.

Let’s not forget visually impaired users. The current versions of popular screen magnifiers have no WAI-ARIA support. ZoomText is apparently not even aware that WAI-ARIA exists. Freedom Scientific plans partial support in MAGic in the next version (the current version is 11.0). Dolphin expects support in HAL and Supernova starting with version 12.5.

Correct and incorrect uses of WAI-ARIA#section6

Currently many implementations do not conform to WAI ARIA best practices to ensure that they work as intended. WAI-ARIA coding errors can actually deteriorate widget accessibility. What contributes to the coding complexity is that the native semantics of HTML elements can be in conflict with the semantics added through WAI-ARIA roles.

The interaction of these problems means that designing with WAI-ARIA can be tricky. Web developers therefore increasingly use screen reader tests to ensure that designs work correctly across a range of assistive technologies (for a start, the NVDA screen reader is free and easy to install).

Implications of widgets for sighted keyboard users#section7

WAI-ARIA’s main benefits are for blind users. For them, desktop-style widgets on a webpage need no longer be inaccessible. But the proliferation of such widgets also has implications for sighted keyboard users.

In contrast to desktop widgets and their conventions, the self-styled widgets on the web come in many flavors. Those that conform to WAI-ARIA best practices are few and far between. What, if any, keyboard interaction a particular widget actually affords is therefore down to guesswork.

Again, take tab panels. There is no easy way to distinguish between a common tab-style main navigation bar and a widget with a tab panel navigation further down the page. And only few tab panels out there afford arrow key navigation instead of tabbing. Sighted keyboard users will have to try out what keys will work. (For blind people using WAI-ARIA capable screen readers, this is actually less of a problem if widget roles are announced in the same way as desktop widgets.)

Another critical point is that custom widgets depend on stylesheets to position their elements. Without CSS or seen with custom stylesheets, these widgets disintegrate and are no longer usable. Widget elements may appear twice or far removed from the intended position. And background images assigned with CSS will disappear (the same happens when using custom color schemes).

Obstacles to using WAI-ARIA in the workplace#section8

There is quite a different set of problems evident in the workplace. Often enough, the problems are outside of the user’s influence:

• Many organizations deploy internet applications customized for a particular browser/screen reader combination. Customization costs are often many times higher than screen reader license or update costs. Known security holes (as in Internet Explorer 7) can necessitate upgrades, but this argument may not suffice if applications are (or ought to be) used exclusively on an intranet.
• Many organizations still use old operating systems such as Windows 2000 which do not accommodate later browser versions such as IE8, and in turn, later screen reader versions. For applications and assistive technology that support rote procedures, there is no real incentive to upgrade unless workflow or major system upgrades demand it.
• Many blind computer users working with WAI-ARIA-capable screen readers such as JAWS 9 or later, are not yet aware of—or trained to take advantage of—its full potential.
• While NVDA and JAWS are currently most capable of dealing with WAI-ARIA, we must not forget users of other, less-capable screen readers.

Often, script-based customization for assistive technologies in the workplace tackles exactly those custom controls that WAI-ARIA could make accessible. Better support for WAI-ARIA may save much time and cost. This, however, presupposes that in creating web or intranet applications, developers use WAI-ARIA consistently and according to best practices.

Who’s without access to WAI-ARIA-capable screen readers?#section9

While we were researching this article, we took a quick sample of one large public German employer. Of the 15 workplaces for blind users we covered, not a single one currently supports WAI-ARIA:

• Seven workplaces use HAL/Lunar (between Version 6 and 10),
• Four workplaces use JAWS 6, and
• Four workplaces use Blindows (between Version 2 and 4).

Of course, the situation may be better at other workplaces. Nevertheless, the sample indicates that a large, possibly very large, share of blind people at the workplace currently have no access to user agents supporting WAI-ARIA.

Survey and usage statistics#section10

Unfortunately, there are no statistics that can reliably quantify how many users have WAI-ARIA-capable screen readers. According to the WebAIM screen reader survey (October 2009), 83.6% of users update their screen reader within one year after the release of a new version. Focusing just on JAWS for a moment and considering the multiple JAWS releases after the first version with WAI-ARIA support in November 2007, the percentage of users still using JAWS 8 should have fallen well below 5%. However, the survey reflects the American market, which will differ from the situation in Germany. Also, it is likely that a high percentage of screen reader users responding to the survey were expert users and therefore, likely early adopters. We can assume that the average update rate across all users is much lower.

Unproblematic ways of using WAI-ARIA#section11

Many applications of WAI-ARIA aim to enrich HTML to rectify some of its semantic deficits. Since HTML 4 knows no explicit elements for marking up page regions, the WAI-ARIA spec offers so-called document landmarks. For example, we can mark up a simple div with role=“navigation” and expose the main page content with role=“main”. This allows screen reader users that support WAI-ARIA to move quickly between the different page regions.

Other attributes improve form markup: For example, we can give an input element the attribute aria-required=“true” to tell screen reader users that the field requires an entry before the form can be sent. ARIA live regions are another useful construct that inform screen reader users about dynamic changes to the page without losing the current keyboard focus.

Pages semantically enriched through WAI-ARIA do not currently validate, but this drawback is acceptable: Common browsers do not mind the additional markup. (The BITV test’s code validation step maintains an exception for validation errors caused by WAI-ARIA markup.) Sooner or later, when the working draft becomes a recommendation and the W3C validator has been updated, that problem will disappear (in HTML5, WAI-ARIA validates). Some sites currently circumvent the validation problem by adding WAI-ARIA attributes to the source code via a script that is executed when the page loads.

More problematic: custom widgets#section12

The WAI-ARIA specification supports a range of custom interface control widgets commonly used in desktop applications so that authors can use them in web-based applications (a full list is contained in the WAI-ARIA Roles Model).

Extensions of standard elements#section13

Authors often aim to extend the behavior of standard elements—for example, to create a tri-state checkbox or a select element that can also accept text input (the combobox). To achieve this, the known HTML elements are recreated by repurposing non-semantic elements such as a div or img, (replacing these as required via scripting to reflect different states), while using WAI-ARIA to inform assistive technology about the intended roles and states.

Self-styled custom widgets#section14

Then there are custom widgets that web designers have built for some time—widgets that WAI-ARIA should now make accessible, including pulldown menus, tabpanels, hierarchical trees, sliders, spinbuttons, and even drag-and-drop interfaces. The desired widget keyboard behavior is not provided like the default behavior of normal focusable HTML elements: It has to be explicitly defined through JavaScript. This constitutes the first problem, since for many custom widgets, there is no standard behavior in response to keyboard input. What works and what doesn’t has to be established empirically by the user.

WAI-ARIA’s lack of robustness is another problem: Its implementation in browsers and assistive technology is not that stable yet. Tricks are sometimes needed to ensure that widgets work as intended, as in a small scripted delay that ensures that elements added to the DOM tree can actually be focused by scripts.

Fallback options for users without WAI-ARIA support?#section15

Is it not possible then, to provide fallback options for user agents that do not support WAI-ARIA? In its coverage of the role presentation, the WAI-ARIA Roles document mentions that it “may be used to provide for an accessible fallback in older browsers that do not support WAI-ARIA.”

Looking around, practical examples of such fallback solutions are conspicuously absent. It is hard to think of any useful application. Consider a custom checkbox with a native checkbox as a fallback option for screen reader users without WAI-ARIA support: moved off-screen via CSS to hide it for sighted users, and marked with role=“presentation” to hide it for WAI-ARIA-capable browsers.

But does it work? The role presentation suppresses WAI-ARIA attributes (apart from global attributes), but still exposes focusable elements like checkboxes. The WAI-ARIA 1.0 User Agent Implementation Guide states clearly:

Therefore, for screen reader users without WAI-ARIA support but with JavaScript on, the custom checkbox would receive focus, but not reveal its role and state. For screen reader users with WAI-ARIA support, the unnecessary fallback checkbox would not announce its role, but would still be in the tab order, be selectable, and change its state after selection. Finally, sighted users would be able to use the custom checkbox, but possibly also tab to and activate a hidden checkbox without any visual feedback. This clearly makes no sense.

WAI-ARIA in JavaScript UI libraries#section16

Many designers drawing on JavaScript functionality provided by popular JavaScript UI libraries will implicitly implement WAI-ARIA, as these libraries are adding support to their widgets and components. The situation is diverse. Dojo is said to offer mature WAI-ARIA support, YUI offers ARIA plugins for a range of widgets, and JQuery is expected to support WAI-ARIA fully in its 2.0 release. Other libraries, however, have no or only very limited support.

The inclusion of WAI-ARIA in JavaScript UI libraries is a good thing since it can be expected that here WAI-ARIA will be implemented according to best practices. However, the fact remains that on the level of hard- and software currently in use, accessibility support for WAI-ARIA cannot be taken for granted.

Recommendations#section17

Appropriate semantic HTML elements, when available, are preferable to using custom widgets made accessible via JavaScript and WAI-ARIA. The difficulty of styling native elements reliably in CSS may appear to be a real pain for web designers: on the plus side for users, interface elements will be more recognizable and predictable when they simply look and work like the known system elements.

Designers should check whether complex custom widgets can be replaced by simpler native elements. Is it really necessary to use a combobox for an autocomplete function? Is it really unavoidable to have a tri-state checkbox? Can radio buttons with discrete values replace a slider?

This is not a call for interface design austerity. There is little harm in using fancy controls if they are given an equivalent accessible alternative. Take, for example, a slider that mouse users can move to set the amount they want to donate to SOS-Kinderdorf, a well-known charitable organization. Check out the second step of the SOS-Kinderdorf donation process (Design by Aperto AG). Depending on the amount specified, a little girl to the right expresses her gratitude in moderate to glowing terms (in German). Apparently, generosity has shot up sharply after the introduction of the slider, which should be sufficient proof of its utility.

While it would have been possible to make the slider work for screen reader users with WAI-ARIA support, the designers preferred a simple text input for the amount donated as an alternative: The tab focus order simply skips the slider. Importantly, the child’s reaction in the speech bubble is triggered by both types of input.

Let’s sum up. It is quite clear that JavaScript has become ubiquitous, and that WAI-ARIA is a welcome solution to address the accessibility gap that this development has created. Developers using WAI-ARIA today can help weed out implementation bugs in browsers and assistive technology. At the same time, they can contribute to best practice examples that can be used by many others as a blueprint.

But as long as older screen reader/browser combinations incapable of interpreting WAI-ARIA still constitute a significant part of the installed base, web designers who care for accessibility should use WAI-ARIA markup only to enrich their sites. They should not rely on it.

Acknowledgements#section18

For hints and comments, many thanks to Carsten Albrecht, Alexander Farkas, Michael GroŸe-Drenkpohl, Jan-Eric Hellbusch, Werner Hoog, Martin Kliehm, Werner KrauŸe, Oliver Nadig, Hans-Herbert Suhling, Timo Wirth, Tiffany Wyatt and Marco Zehe.

Useful resources#section19

• WCAG 2.0 Understanding Conformance—Understanding Accessibility Support This section of WCAG 2.0 describes the concept of accessibility support and lists success criteria.
• WAI-ARIA Overview: An introduction of the W3C Web Accessibility Initiative into WAI-ARIA
• WAI-ARIA 1.0 User Agent Implementation Guide
• WAI-ARIA 1.0 Authoring Practices
• Introduction to WAI ARIA by Gez Lemon
• The DHTML Style Guide. The DHTML Style Guide Working Group (DSGWG) has created a recommendation for keyboard shortcuts to be used in website widgets.
• Using WAI ARIA Landmark Roles by Steve Faulkner (Paciello Group Blog). This includes a comparison of ARIA landmarks and the structural elements in HTML5.
• An HTML5 plus ARIA “Sanity Check”: Working Around Bugs in AT by Jason Kiss describes some of the problems with bugs in assistive technology when using ARIA landmarks in HTML5.
• WebAIM Screen reader Survey: A survey of the preferences of screen reader users. This resource also contains statistics on screen reader software and the upgrade behavior of users.
• There is also a follow-up of the screen reader usage survey.
• Code Talks: Set of ARIA Test Cases. Not quite recent—many combinations of browsers/screen readers were not tested
• Marco’s accessibility blog. Marco Zehe’s blog covers various WAI-ARIA techniques that improve accessibility and usability for blind users, often based on software by the Mozilla Foundation. Slightly dated (July 2009): The WAI-ARIA Windows screen reader shootout (under Firefox 3.5)