Improve Your Website’s Accessibility With WAI-ARIA

The following is an extract from our book, HTML5 & CSS3 for the Real World, 2nd Edition, written by Alexis Goldstein, Louis Lazaris, and Estelle Weyl. Copies are sold in stores worldwide, or you can buy it in ebook form here.

In Chapter 2 and Chapter 3, we covered considerable ground explaining how our pages can become more semantic and potentially more accessible using HTML5’s new semantic elements. Improved semantics alone, however, is often insufficient to make a sophisticated web application fully accessible.

In order to have the content and functionality of our pages as accessible as possible for our users, we need the boost that WAI-ARIA provides, extending what HTML5 already does. We’ll avoid going into an extensive discussion on WAI-ARIA here—that’s a topic that could fill many chapters—but we felt it was important to mention it here so that you’re aware of your options.

WAI-ARIA stands for Web Accessibility Initiative-Accessible Rich Internet Applications. The overview of WAI-ARIA on the W3C site explains it as:

[…] a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced JavaScript-heavy user interface controls developed with Ajax, HTML, JavaScript, and related technologies.

Users who rely on screen reader technology, or who are unable to use a mouse, are often excluded from using certain website and web application functionality—for example, sliders, progress bars, and tabbed interfaces. With WAI-ARIA, you’re able to deal with these shortcomings in your pages—even if the content and functionality is trapped in complex application architecture. Thus, parts of a website that would normally be inaccessible can be made available to users who are reliant on assistive technology.

How WAI-ARIA Complements Semantics

WAI-ARIA assigns roles to elements, and gives those roles properties and states. Here’s a simple example:

<li role="menuitemcheckbox" aria-checked="true">Sort by Date</li>

The application might be using the list item as a linked element to sort content; yet without the role and aria-checked attributes, a screen reader would have no way to determine what this element is for. Semantics alone (in this case, a list item) tells it nothing. By adding these attributes, the assistive device is better able to understand what this function is for.

For semantic elements—for example header, h1, and nav—WAI-ARIA attributes in most cases are unnecessary, as those elements already express what they are. Instead, they should be used for elements whose functionality and purpose cannot be immediately discerned from the elements themselves (or for elements that have little or no accessibility support in one or more of the major browsers).

The Current State of WAI-ARIA

The WAI-ARIA specification is still improving, as is HTML5, so these technologies are yet to provide all the benefits we would like. Although we’ve described the way that WAI-ARIA can extend the semantics of our page elements, it may be necessary to include WAI-ARIA roles on elements that already express their meaning in their names, because assistive technology doesn’t support all the new HTML5 semantics yet. In other words, WAI-ARIA can serve as a sort of stopgap, to provide accessibility for HTML5 pages while screen readers are catching up.

Let’s look at a site navigation, for example:

<nav role="navigation"> <ul>… </ul>
</nav>

It would seem that we’re doubling up here: the nav element implies that the list of links contained within it make up a navigation control, but we’ve still added the WAI-ARIA role navigation to it. In many cases, this sort of doubling up will often be necessary. In the case of the nav element, Internet Explorer is the only browser that doesn’t correctly expose a role of “navigation” by default, so for now, adding this attribute is necessary.

Does this mean that WAI-ARIA will become redundant once HTML5 semantics and accessibility are fully supported? No. There are roles in WAI-ARIA without corresponding HTML5 elements; for example, the timer role. While you might represent a timer using the HTML5 time element and then update it with JavaScript, you’d have no way of indicating to a screen reader that it was a timer, rather than just an indication of a static time.

For a screen reader to access WAI-ARIA roles, the browser must expose them through an accessibility API. This allows the screen reader to interact with the elements similarly to how it would access native desktop controls.

Browser support for ARIA features has been growing and is currently very good. All the latest versions of browsers support WAI-ARIA at least partially. A fairly up to date guide for support of accessibility features like WAI-ARIA in browsers on certain OSes can be found on the Paciello Group’s website.

Finally, it’s worth noting that not all users who could benefit from WAI-ARIA roles are utilizing them. In Janaury 2014, WebAIM (Web Accessibility In Mind) conducted their fifth screen reader user survey, which revealed that about 28% of participants either seldom or never navigated web pages by means of ARIA landmarks. The good news is, the number of users utilizing ARIA landmarks is increasing. In 2010, in a similar survey, more than 50% either didn’t use or didn’t know ARIA roles existed.

In short, there is pretty good support for WAI-ARIA and you won’t hurt your HTML5 documents by including these attributes. They pass markup validation in HTML5 and even though the full benefits are yet to be seen, they’ll only increase over time.