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:
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
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
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.
As mentioned, a full primer on all of the WAI-ARIA roles is beyond the scope of this book, but if you’re interested in learning more, we recommend the official specification first and foremost. The W3C has also put together a shorter Primer and an Authoring Practices guide.
You can also check out Stephan Max’s Introduction to WAI-ARIA on SitePoint. Finally, you might find it useful to review HTML5 Accessibility a website maintained by accessibility expert Steve Faulkner that summarizes in chart form how different browsers handle HTML5’s semantic elements from an accessibility standpoint.