By Richard Schwerdtfegger and Becky Gibson, IBM
With the rapid adoption of rich-client technologies, Web 2.0 applications have proliferated. By incorporating Ajax libraries, like Dojo or other client side technologies that use JavaScript and CSS, Web sites are vastly changing the user experience. Currently, many Web 2.0 features are not accessible to people with disabilities, especially people who rely on screen readers and people who cannot use mouse devices. WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Application) defines new methods of communicating Web 2.0 functionality to assistive technologies (AT). With WAI-ARIA, developers can make advanced Web applications accessible and usable to people who have disabilities.
This article explains how to use WAI-ARIA to overcome the following accessibility issues for Web 2.0 applications:
- Presentation of document structure
- Dynamic content updates
- Keyboard accessibility enhancements
- Widget accessibility
Framework for developing accessible Web content: WAI-ARIA
WAI-ARIA is a framework for developing accessible Web 2.0 content and applications containing dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript and related technologies. The WAI-ARIA framework contains a set of attributes that can be applied to HTML and mapped to accessibility APIs by the browser.
WAI-ARIA acts like a contract between the AT and application to enable access to rich content with the semantic information necessary to make the content accessible. Figure 1 shows the relationship between the contract, AT and Web UI.
Figure 1. The contract, AT and Web page relationship using WAI-ARIA
WAI-ARIA contains Roles, States and Properties. Figure 2 shows the WAI-ARIA taxonomy.
SVG class diagram | PNG class diagram | Class diagram description
Figure 2. WAI-ARIA taxonomy 1
Browsers and AT that are supported by IBM Web applications and support WAI-ARIA include FireFox 3.0 and later, Internet Explorer 8, Safari 5, Opera 9.5 and JAWS 10 and later.
Using WAI-ARIA to provide a navigable page structure
The WAI-ARIA regional landmark roles such as main, search and navigation can be used to provide a navigable structure within a Web page.
The following example (Figure 3) demonstrates how to use these regional landmark roles to support screen reader keyboard navigation to their respective regions.
Figure 3. A typical Web site with regional landmarks indicated.
This Web site has several parts: search, navigation, main, and so on. As shown in the following example HTML, the aforementioned regional landmark roles can be used to make navigation easier for a screen reader user:
<html>
<body>
…
<div role="search">
The search area
</div>
<div role="navigation">
The navigation area
</div>
<div role="main">
The main content area
</div>
…
</body>
</html>
In addition to the regional landmark roles, you can use other WAI-ARIA roles that define page structure. Guidance on incorporating these additional roles is located in the "Providing Navigable Structure within Web Pages" section of the WAI-ARIA Authoring Practices.
WAI-ARIA live regions
Before WAI-ARIA, screen readers like JAWS often did not read text that was dynamically rendered on different regions of a page. As a result, people with disabilities found it difficult to use rich Web 2.0 applications that contained content such as mash-ups, an auto-updating stock ticker or an auto-updating message log.
With the advent of WAI-ARIA live regions, Web application developers can easily make dynamic content accessible to screen reader users. The following example uses a WAI-ARIA live region in a stock ticker widget to enable JAWS to read quotes as the ticker displays them. The widget automatically displays a new stock quote every second.
When live region information is auto-updating, you should provide a mechanism to stop and restart the flow of information so as not to overwhelm a screen reader user. Therefore, the stock ticker widget provides a "pause ticker" checkbox to pause the flow of stock quotes displayed by the ticker, as shown in Figure 5.
Figure 4. Stock quote ticker
The following HTML is used to render the ticker. The aria-live attribute on the fieldset element enables a screen reader to announce quotes as they appear in the ticker.
<input type="button" id="startQuotes" name="startQuotes" value="Start stock
ticker"
onclick="showQuotes();">
<input type="checkbox" id="tickerOff" name="tickerOff"
onclick="toggleTicker(this)">
<label for="tickerOff">Pause ticker</label>
<fieldset id="quote" aria-live="polite"><legend>Stock
Quotes</legend></fieldset>
The showQuotes() function starts the flow of quotes into the ticker box. When the "pause ticker" checkbox is checked, toggleTicker() is called which stops the flow of quotes. When the checkbox is unchecked, the ticker resumes displaying quotes.
<script type="text/javascript">
var t;
/* Start quotes */
function showQuotes(){
/* Simulate a stock ticker */
var quotes = new Array("IBM 97.75", "GLW 7.87", "C 8.75", "WB 5.98",
"SUN 3.65", "RIG 72.25");
var quoteStr =
document.createTextNode(quotes[Math.floor(Math.random()*6)]);
var msgContainer = document.createElement('div');
msgContainer.appendChild(quoteStr);
document.getElementById('quote').appendChild(msgContainer);
/* Show a quote every second */
t=setTimeout("showQuotes()",1000);
}
/* Pause/resume quotes */
function toggleTicker(obj){
if (obj.checked == true){
clearTimeout(t);
} else {
showQuotes();
}
}
</script>
To create a live region using WAI-ARIA, developers should add the aria-live property to an element with one of the following values:
aria-live="off"tells the screen reader to ignore the updated contents.aria-live="polite"tells the screen reader to notify the users of the updated content as soon as he/she finishes his/her current job. This may alert the user with a beep sound to indicate that the Web page has updated. Users can choose to jump directly to the updated regions or ignore the update. The"polite"value is useful for status notification, weather or stock updates, chat messages, and so on.aria-live="assertive"notifies the user of the updated content immediately. The"assertive"value is useful for error messages.
Using the above aria-live options, developers can divide content dynamically changed or updated into several criteria levels and decide how to inform users of the updated content.
Using WAI-ARIA to enhance keyboard navigation
In HTML, only links and form elements can receive keyboard focus, meaning that the Tab key is used to set focus on those elements. However, for Web 2.0 applications, the application may need to focus on span or div elements that define, for example, tree nodes or tabs within a tablist.
WAI-ARIA enables all HTML elements to receive keyboard focus by extending the tabindex property to apply to any element.
| Tabindex Attribute | Focusable | Tab Order | Example |
|---|---|---|---|
| Not present | Default focus behavior: only form controls and links can receive focus | Follow the default tab order | <span>span text here</span> |
Tabindex="0" |
Can be focused by mouse, keyboard, and JavaScript | In tab order relative to element's position in document | <span tabindex="0">span text here</span> |
Tabindex="X" (where X is a positive integer between 1 and 32768) |
Can be focused by mouse, keyboard, and JavaScript | The tab order is based on numeric value. Will appear before items in the natural tab order such as anchors and form elements. | <span tabindex="1">span text here</span> |
tabindex="-1" |
Can be focused only by JavaScript | Must focus it with element.focus() as a result of arrow or other key press |
<span tabindex="-1">span text here</span> |
Applications can implement WAI-ARIA arrow key navigation by capturing arrow key keypress events and manipulating tabindex to set focus to the proper UI element. More information can be found on implementing keyboard navigation in the "Providing Keyboard Navigation for Widgets" section of the WAI-ARIA Authoring Practices.
Using WAI-ARIA to enable widget accessibility
Widgets in Web 2.0 refer to components that are not native to HTML, or components that are highly enhanced by JavaScript. Web 2.0 sites contain many widgets, some of which are inaccessible for people with disabilities using screen readers. To solve this problem, you should enable WAI-ARIA keyboard navigation and communicate accessibility information to screen readers, using role, name, and state attributes as well as value.
The following is a combo box widget:
Figure 5. Combo box widget
The combo box widget includes:
- Editable text field
- Drop-down button
- Popup item list
The following are keyboard interactions for the combo box:
- The text field should be in the tab sequence.
- With the <Down> key pressed, the popup list displays.
- User can change selection in the list with the <Up> and <Down> key.
- User presses the <Enter> key to enter the selected item into the text field.
- Auto-complete feature when user enters characters in the field.
Implementation of these keyboard features is not difficult, yet communicating attributes of the widget to screen readers is. With WAI-ARIA Roles, States, and Properties attributes, developers can communicate properties and current status of a widget to accessible technologies.
The following are typical steps to make the combo box widget accessible:
- Insert the
role=comboboxon the outer wrap component, which contains the three items. - Insert the
role=buttonfor the drop-down button. - Insert the
role=listfor the popup item list. - Insert the
role=listitemfor each item in the list. - If the textfield is not editable, insert
aria-readonly=true. - Provide a label for the combobox by referencing the textfield in the combobox.
- Implement arrow key navigation of the items in the combo box.
With WAI-ARIA keyboard navigation and WAI-ARIA roles and properties, this combo box widget is accessible to people with disabilities. Note that WAI-ARIA-supported browsers and screen readers must be used.
The following is the Dojo-rendered HTML code for the example combo box that demonstrates how Dojo uses WAI-ARIA to enhance widget accessibility:
<label id="NEStates_label" for="NEStates">New England States:</label>
<div aria-labelledby="NEStates_label" dir="ltr" role="combobox" class="dijitTextBox dijitComboBox" id="widget_NEStates">
<div role="presentation" class="dijitArrowButton" dojoattachevent="onmousedown:_onArrowMouseDown">
<input role="presentation" class="dijitInputField dijitArrowButtonInner" value="? " tabindex="-1" readonly="readonly" type="text">
</div>
<div class="dijitReset dijitValidationContainer">
<input role="presentation" class="dijitValidationIcon" value="? " tabindex="-1" readonly="readonly" type="text">
</div>
<div class="dijitInputContainer">
<input value="Connecticut" title="New England States" tabindex="0" id="NEStates" aria-invalid="false" aria-autocomplete="list" aria-haspopup="true" role="textbox" name="NewEnglandST" autocomplete="off" dojoattachevent="onkeypress:_onKeyPress" type="text">
</div>
</div>
Note: When tabbing into this Dojo combo box, the screen reader reads: "To move through items press up or down arrow."
By using WAI-ARIA, Web 2.0 applications can be made fully accessible to all users. Developers can start by adding WAI-ARIA landmarks and by identifying regions that are incrementally updated. Adding landmarks to Web sites will identify important parts of the page and make navigation easier for assistive technology users. Using the aria-liveregion attribute with an appropriate value will insure that screen reader users are aware of all information on the page and can interact with it. Adding keyboard support assists all users and is a prerequisite for access by screen reader users. The WAI-ARIA roles, states and properties enable all of the rich user interface controls for full accessibility. Developers should embrace WAI-ARIA now to make the Web accessible for all.