The basis of accessibility is that every Web user should have access to the information and experiences available online. The nature of the Web and the tools used to create and access the information it offers means that some users, like those with visual, auditory, or other physical impairment, have difficulty accessing its content. The tenets and practice of the accessible Web aim to ensure these users’ impairments do not prevent them from experiencing the Web as a valuable resource, and they have access to the same content other visitors enjoy.
What do I need to know?
In order to make the content and functionality of our web pages as accessible as possible for our users, we need the boost that WAI-ARIA (Web Accessibility Initiative-Accessible Rich Internet Applications) provides by extending what HTML5 (or any markup language) already does.
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, like sliders, progress bars, and tabbed interfaces. With WAI-ARIA, you are 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
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 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 Current State of WAI-ARIA
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 yet support all the new HTML5 semantics. 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 the example of a site’s navigation:
<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 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
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.
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.
Where do I learn more?
The Sitepoint forums have a great thread: Web Accessibility: Frequently Asked Questions and Resources
Web designers and developers need techniques that work now while keeping an eye on what lies ahead. To do that, I’ve had one focus in every workshop I’ve taught over the past seven years: getting the best real world solutions for creating accessible websites and applications into the hands of developers and designers.
Is it better to release your product and add accessibility later, or build-in accessibility from the start?
Most of the time, my writing focuses on search engine optimization techniques. So, why would I write about accessibility in WordPress? Because, to a large extent, optimizing a site for search engines and optimizing a site for disability access amount to much the same thing.