Improving Accessibility Through ARIA
July 2nd, 2009 by rdohertyAccessibility is a pretty hairy issue in web development. When attempting to determine if your site is accessible, there are so many standards and recommendations to follow. 508, WCAG, WCAG 2.0, WAI Priority 1, 2 & 3.
Well, now there is a new standard from the W3C called WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications)
The simplest definition of ARIA is adding UI semantics via HTML element attributes. Simply, you add things like ‘<div role="nav">‘ or ‘<form role="search">‘ to specific HTML elements to give screen readers a better understanding of your content.
The ARIA spec is huge (160 pages), so I won’t go over every part of it in detail. The four areas I will focus on are landmarks, required, invalid and live regions.
ARIA Landmarks
Today, when a blind user encounters a website, navigation between elements of the page can be difficult because there is no established method of marking areas of the page as navigation, content, footer, etc. Luckily with ARIA, we can.
Here’s some example markup of a typical webpage:
<div id="header">
<h1>My Awesome Website</h1>
<form> </form>
</div>
<div id="content">
<ul id="nav"></ul>
My website rocks!
</div>
<div id="footer"></div>
And here’s what it looks like with ARIA Landmarks:
<div id="header" role="banner">
<h1>My Awesome Website</h1>
<form role="search"> </form>
</div>
<div id="content" role="main">
<ul id="nav" role="navigation"></ul>
My website rocks!
</div>
<div id="footer"></div>
What I’ve done is add ARIA roles to certain parts of the page (header, nav, search form, primary content). Because the roles are a defined spec, screen readers can parse the page for roles and allow a user to jump to each part without having to navigate through all the content.
ARIA Required & Invalid
Another part of the ARIA spec is the attribute ‘aria-required’ and ‘aria-invalid’. These attributes are for communicating to screen readers that a particular form field is required and/or invalid without requiring the user to look for asterisks or other text near the field. The screen reader would alert the user to this information. Here’s an example:
<form id="searchform" role="search">
<p class="error">You did not enter a search term</p>
<input name="query" value="" aria-required="true" aria-invalid="true" />
</form>
The above code has the ‘aria-required’ and ‘aria-invalid’ attributes set to true. When a screen reader encounters this code, it will read aloud ‘required’ and ‘invalid’. This is a lot simpler for a user than attempting to find error messages and/or asterisks in the page.
ARIA Live
A particularly difficult area of accessibility is dealing with AJAX. How can you communicate to a screen reader that content is loading or has changed? Thankfully, with ARAI Live Regions, it is quite simple. Here’s an example:
<div id="sidecontent" aria-live="polite"> AJAX content goes here... <div>
Adding the ‘aria-live’ attribute to an element alerts a screen reader that content will change in this region and to read it aloud when it does. The aria-live attribute has ‘politeness’ levels, which allow you to specify how polite the updates should be. The four levels are
- off - updates are not communicated
- polite - notify of changes only when the user is not doing anything
- assertive - announce as soon as possible, but not interrupting the user
- rude - which will be read aloud immediately
The various levels of politeness allow for different situations where users would need to be notified immediately of important information or for content that is not as important.
Summary
This is just a quick overview of ARIA and its uses, but I’m really excited about the possibilities it creates. We can communicate the intent of our content much more explicitly. There’s also a lot of other aspects to ARIA including widgets (slider, checkbox), application structure (alerts, log, progressbar) and document structure (article, grid, definition) that are exciting.
