In Chapter 2 and Chapter 3, we covered considerable ground explaining the potential benefits of using HTML5’s new semantic elements for greater accessibility and portability of our pages. Yet, improved semantics alone is sometimes 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 (or any markup language) 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 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.
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 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.
The WAI-ARIA specification is new, 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 the screen readers are catching up.
Let’s look at a site navigation, for example:
<nav> <ul role="navigation"> … </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 the list. Because
WAI-ARIA and HTML5 are new technologies, this sort of doubling up will
often be necessary: some browsers and screen readers that may lack support
for HTML5 will have support for WAI-ARIA —and
the inverse is possible too.
Does this mean that WAI-ARIA will become redundant once HTML5 is
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.
An article on A List Apart, published in late 2010, summarized WAI-ARIA support in browsers and assistive devices by saying:
Support for some parts of WAI-ARIA […] is already quite good in later versions of browser and screen readers. However, many problems remain.
Finally, it’s worth noting that not all users who could benefit from WAI-ARIA roles are utilizing them. In December, 2010, an organization called WebAIM (Web Accessibility In Mind) conducted their third screen reader user survey, which revealed that more than 50% of participants didn’t use WAI-ARIA features, nor knew they existed.
In short, there is some support for WAI-ARIA—and you won’t hurt your HTML5 documents by including these attributes, as they validate in HTML5. 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.