Accessibility of Rich Internet Applications
Article Contents
Translations
Translations of this article are available in:
French - External Link - courtesy of Pompage.
Overview
Note
This article is part two of a two part series on AJAX and dynamic content accessibility. Be sure to read Part 1 about general issues of AJAX accessibility.
This article will provide some techniques and general approaches to AJAX and dynamic content accessibility for rich internet applications. This article will not present everything you need to know, but will provide a general overview of making dynamic and complex scripted content accessible.
A Note on ARIA
WAI-ARIA (Accessible Rich Internet Applications or ARIA) is a W3C protocol for enhancing and supporting accessibility of scripted and dynamic content. ARIA provides accessible interactive controls (such as tree menus, drag and drop, sliders, sort controls, etc.), content roles for identifying page structure (navigation, search, main content, etc.), areas that can be dynamically updated (called "live regions" in ARIA), better support for keyboard accessibility and interactivity, and much more.
ARIA is supported by most up-to-date browsers and screen readers. It is also supported by many script libraries. Perhaps the biggest current barrier to ARIA implementation is the lack of support in Internet Explorer. However, Internet Explorer 8 will have full support for ARIA. Although ARIA is not yet universally supported, when used with existing HTML and scripting accessibility techniques, it can provide additional accessibility support where it is supported while not causing compatibility issues where it is not yet supported.
For more details on implementing ARIA, please see the WAI-ARIA FAQ. Read our WebAIM article for more general details on javascript accessibility.
In general, accessibility issues with rich internet applications can be characterized as:
- Providing the semantic structure of page areas and functionality (e.g., navigation, main content, search, etc.)
- Maintaining accessibility of content that is dynamic and may change within the page (e.g., AJAX content updates)
- Allowing certain non-focusable page elements to receive keyboard focus (e.g., setting focus to an error message within the page)
- Providing keyboard and screen reader accessibility with complex widgets and navigation elements (e.g., sliders, menu trees, etc.)
Presenting Document Structure
With current versions of HTML and XHTML, there is no mechanism for identifying the function or purpose of page elements in a programmatically determinable way (this is a fancy way of saying "in a way that a computer can figure it out"). In other words, you cannot, in your code, identify your main content, navigation, search, etc. as such. While you can and should use a proper heading structure in your document, this does not provide a standard way for users to access or determine the semantic role of page elements.
This problem is evidenced by the need for "Skip to main content" or "Skip navigation" links. Because a browser or screen reader has no way of knowing what portion of the page contains the navigation elements, it is necessary for site authors to create a specific link which allows keyboard users to bypass those links. Even directly accessing commonly used page functionality, such as search requires that the user browse through or listen to the page and find or discover it.
WAI-ARIA provides the ability for developers to specify roles for document areas (and many other things). The available Document Landmark Roles are:
banner- Site-orientated content, such as the name of the web site, title of the page, and/or the logo.
navigation- The area that contains the navigation links for the document or web site.
main- The main or central content of the document.
search- This section contains the search functionality for the site.
article- Stand-alone content that makes sense out of context from the rest of the document. Examples might be a blog posting, a comment on a blog, a forum post, etc. Specifically, a blog posting might be identified as an article and individual blog comments might also be marked up with a role of article within that blog posting.
complementary- Supporting content for the main content
contentinfo- Informational child content, such as footnotes, copyrights, links to privacy statement, links to preferences, and so on.
On this site, the logo and tagline might be given a role of banner. The navigation tabs across the top would be identified as navigation. The site search would obviously be given a role of search. The links down the left side might be identified as complementary. The main body of this article would be main. The "See Also" links at the bottom would have a role of contentinfo.
Most pages can apply at least a few landmark roles now - <ul role="navigation"> or <div role="main"> or <form role="search">. This function of ARIA is not limited to rich applications, but can be applied to nearly any current web page.
Assistive technologies are beginning to provide support for document roles. They may provide shortcut keys to jump to specific structural elements (for instance, S for search) and/or provide a list of all structural roles in the document. Additionally, ARIA provides new roles for other types of elements, such as role="presentation" for tables used in layout. It also allows you to identify required form elements, provide better form labeling and descriptions, and allow you to provide instant feedback to screen reader users.
Dynamic Content Updates
When content changes dynamically within a web page, it may cause accessibility problems. What happens if a screen reader is currently reading an element that is updated? If the updated content is important, should you interrupt the user and set focus immediately to the new content, do you simply inform the user of the update, or do you do nothing? How do you set focus or allow the user to jump to the updated content?
With standard scripting, the developer must dictate what happens when a content update, such as an AJAX-driven feedback message, occurs. The developer can simply allow the update to occur and not inform the user of it, alert the user of the update through some sort of embedded audio sound, or can set focus directly to the updated content. The developer must script each of these situations, thus removing the control from the user.
With WAI-ARIA, the developer can identify regions that dynamically change as a live region. A live region allows content updates in a way that a screen reader understands. It also allows the developer to add additional functionality to alert the user, provide controls for the live region, determine the amount of new content that would be read, and much more.
To create a live region, the developer adds the aria-live property to the element with a value of off, polite, assertive, or rude. The value, or politeness level (or alternatively the intrusiveness level), specifies what a screen reader should do when the element is updated.
A value of off (aria-live="off") tells the screen reader to not announce the update. If/when the screen reader user encounters the updated content, it will be read at that time. This would be used for non-important or irrelevant content updates.
A value of polite will notify the user of the content change as soon as he/she is done with the current task. This might take the form of a beep or an audio indication of the update. The user can then choose to directly jump to the updated content. This value would be the most common for content updates, especially for things like status notification, weather or stock updates, chat messages, etc.
An aria-live value of assertive will result in the user being alerted to the content change immediately or as soon as possible. Assertive would be used for important updates, such as error messages
aria-live="rude" is reserved for the most critical of updates. It would immediately inform the user of the update and possibly set focus immediately to the updated content.
The high level of fidelity with ARIA live regions allows great flexibility both for developers and for end users.
Enhancing Keyboard Accessibility
In HTML, only links and form elements can receive keyboard focus. This means that as you 'tab' through a page, the browser stops or sets focus only on these types of elements. With scripting, however, you can add mouse interactivity to nearly any element. This means you can make normal page elements, such as a paragraph or span, interactive and responsive to the mouse (e.g., you can make plain text display and behave like a button). The functionality of these non-focusable elements cannot be made accessible to screen reader and keyboard-only users. Developers often have a need for page elements other than links and form elements to be interactive.
Additionally, it is often necessary to set focus to page elements. For instance, a form validation error message might be displayed as text (not a link or form element) within a page using scripting. Visual users can immediately see the error message. However, a screen reader user may not know that the new message is present. In order to set focus to the error message so it can be read by a screen reader, the message must be able to receive focus - something it cannot typically do unless it is a link or form element.
ARIA again provides mechanisms for non-focusable elements to receive focus through the tabindex property. (See our related article on tabindex). ARIA extends the tabindex property so it can be applied to any element. By setting a tabindex value of 0 (tabindex="0"), an element will be placed in the tab order of the document. This means that the browser will stop and set focus to the element in the navigation order of the document (e.g., when the user tabs to the element). This allows additional functionality and interactivity to be applied to the element, such as triggering functionality when the element receives keyboard focus or when the user presses a key while the element has focus.
A tabindex value of -1 allows an element to receive focus, but only when that focus is set programatically - meaning that the user activates a link to the element (<a href="#maincontent"> ...) or focus is set with scripting (e.g., document.getElementById('errormessage').focus();).
By expanding the focus capabilities in the web browser to elements that otherwise cannot receive focus, ARIA allows additional possibilities for providing accessibility.
Widget Accessibility
The term 'widget' is broadly used to describe interactive elements that are created and controlled through scripting. It refers to controls that are not native to HTML or to HTML controls that are greatly enhanced through scripting. Examples of widgets would include sliders, drop-down and fly-out menus, tree systems, drag and drop controls, auto-completing text boxes, and tooltip windows, to name a few. Accessibility of widgets does not happen natively or naturally. While scripting can often provide accessibility for many of these elements, there is not an easy or standardized way of doing so. In short, making these widgets keyboard and screen reader accessible is often possible, but it's rather difficult and the end result is often only marginally accessible for practical purposes.
For instance, a drop-down menu, as is commonly found on navigation bars for web sites, allows much functionality in a very compact space. Using scripting, it is very possible to provide accessibility to the drop-down menu items. The developer could hide the sub-menu items and make the main menu item a link to a page that contains standard links to the submenu page, but this approach results in additional pages and an additional 'step' for the user. Alternatively, the developer could allow the user to tab through all of the navigation items, but this results in many navigation items (perhaps hundreds on some sites) and no context as to the structure of the navigation menu - all items are simply read in order. Finally, the developer could use scripting to make the navigation system keyboard accessible. The downside of this approach is that there is not a standardized way of making such systems keyboard accessible. Which key opens the menu - Enter, Down Arrow, Space, etc.? Which key navigates through the sub-menus? If the menu uses the arrow keys, how does a blind user know that it is a drop-down menu (use the Down Arrow key) as opposed to a fly-out menu (user the Right Arrow key) if he or she cannot see the menu? How do you present the hierarchical structure of a complex menu system to the screen reader user?
Similar issues arise with other widgets. How do you make a drag-and-drop element keyboard accessible? How do you present ordering details for sortable list items? How do you present visual tooltips or pop-up messages to blind users?
ARIA addresses many of these issues. By establishing a set of roles, properties, and values, ARIA allows developers to address these accessibility issues with relative ease.
The following provide some very basic examples of how ARIA might be implemented.
Required form element
: (required)
<label for="name">First Name</label>: <input name="name" id="name" aria-required="true"> <em>(required element)</em>
This input box demonstrates a common problem - the form element is required, but the word "required" is not contained within the label for the form element and thus would not likely be spoken by a screen reader. ARIA's aria-required="true" will inform a screen reader that the specified form element is required.
Note:
Even though ARIA provides the necessary information in this example, this only works in browsers and assistive technologies that support ARIA. In other user agents, the example would be inaccessible. This example is admittedly flawed (the "required" text should be within the label), but it demonstrates future potential for ARIA to better address these types of issues.
Button Example
The following is a text element (not an actual HTML button) that can be clicked or activated with the keyboard (tab to the button and press Enter or Space).
Push Me
<span style="background-color: #ddd; border: medium outset white;" role="button" tabindex="0" onkeydown="if(event.keyCode==13 || event.keyCode==32) alert('You activated me with the keyboard');" onclick="alert('You clicked me with the mouse');">Push Me</span>
In this example, the text is styled to visually appear like a button. The role="button" tells the browser that the text should behave as a button. tabindex="0" puts the element into the keyboard navigation flow so keyboard users can activate the button. While this example is a bit contrived (why not just use an actual button?), it demonstrates the ability for ARIA to add accessible interactivity to any element.
Form Validation Example
In this example, to allow the browser to navigate to other portions of the page.
Because the keyboard focus is set back to the form element with javascript after an incorrect response, the feedback message will not be read by a screenreader. In this case, the feedback message is given role="alert" when it displays. This causes the feedback message to be immediately read by the screen reader. The user can now re-attempt the response with the appropriate feedback. Once the correct answer is provided, focus is released to the text that immediately follows (which was given tabindex="0" so that it can receive focus rather than focus jumping to the next form element or link in the page).
Conclusion
These examples demonstrate just a few basic ways in which ARIA can be implemented now to enhance accessibility of interactive elements. ARIA, however, supports many additional types of widgets and interactions. For complex widgets and interactions, it is highly likely that a developer, rather than building from scratch, will use existing scripting libraries to create such elements. Fortunately, ARIA is being implemented into many scripting libraries (such as jQuery, Dojo, YUI, and GWT). While developers can certainly implement ARIA into their advanced widgets and applications, using ARIA-supported libraries greatly simplifies the process of providing this level of accessibility.
ARIA cannot solve all accessibility issues and can be a bit difficult to implement, but it provides much greater levels of accessibility than is currently available through HTML and scripting alone. As support in browsers, assistive technologies, and scripting libraries increases, ARIA is becoming a great tool for ensuring accessibility of rich internet content and applications.
WebAIM is an initiative of:
