Accessibility of Rich Internet Applications
This article will provide some techniques and general approaches to rich internet application accessibility. This article will not present everything you need to know, but will provide a general overview of making dynamic and complex scripted content accessible.
WAI-ARIA (Accessible Rich Internet Applications or ARIA) is a W3C protocol for enhancing and supporting accessibility of scripted and dynamic content. ARIA enhances accessibility of interactive controls (such as tree menus, drag and drop, sliders, sort controls, etc.), provides 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 scripting libraries. 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.
In general, accessibility issues with rich internet applications can be characterized as:
- Inability to provide the semantic structure of page areas and functionality (e.g., navigation, main content, search, etc.)
- Inaccessibility of content that is dynamic and may change within the page (e.g., AJAX content updates)
- Inability to change keyboard focus to page elements (e.g., setting focus to an error message within the page)
- Difficulty with keyboard and screen reader accessibility with complex widgets and navigation elements (e.g., sliders, menu trees, etc.)
ARIA can help address many of these issues.
The three main components are roles, properties, and states.
ARIA roles define what an element is or does. Most HTML elements have a default role that is presented to assistive technology. For example, a button has a default role of "button" and a form has a default role of "form". With ARIA, you can define roles that are not available in HTML. You can also override HTML's default roles. This allows you to present elements and widgets in HTML to screen readers in a more accurate and accessible way.
An example of an ARIA role is
<form role="search">. In HTML, all forms have the same semantics. But with ARIA, you can add to the semantics of a particular form to define it as the search form.
ARIA properties define... well, properties or meanings of elements. You can extend HTML's native semantics by defining properties for elements that are not allowed in standard HTML. An example is
<input aria-required="true">. This property will cause a screen reader to read this input as being required (meaning the user must complete it).
ARIA states are properties that define the current condition of an element. They generally change based on user interaction or some dynamic variable. An example is
<input aria-disabled="true">. This property will cause a screen reader to read this input as being disabled, but this state value could easily be changed to
false dynamically based on user input.
ARIA roles, states, and properties can be defined in markup or they can be defined and dynamically set and changed using scripting. ARIA states and property attributes always start with "aria-" (e.g.,
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:
- Site-orientated content, such as the name of the web site, title of the page, and/or the logo.
- The area that contains the navigation links for the document or web site.
- The main or central content of the document.
- This section contains the search functionality for the site.
- 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.
- Supporting content for the main content
- Informational child content, such as footnotes, copyrights, links to privacy statement, links to preferences, and so on.
On a site, the logo and header content might be given a role of
banner. The navigation tabs across the top would be identified as
navigation. The site search form would obviously be given
<form role=search>. The related links in a side bar might be identified as
complementary. The main body of an article would be
main. The footer content and link at the bottom of a page would have a role of
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 provide shortcut keys to navigate through elements defined as landmarks, or perhaps to jump to specific structural elements (for instance, S for search), and/or provide a list of all structural elements 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.
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
You can also define which content should be read when an update occurs. Additionally, there are special ARIA roles that define certain types of highly dynamic content, such as alerts, logs, and timers. 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 control.
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.,
By expanding the focus capabilities in the web browser to elements that otherwise cannot receive focus, ARIA allows additional possibilities for providing 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. And HTML has very limited markup for defining complex widgets.
While scripting can often provide accessibility for many of these elements, it is often implemented in varying ways. 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. How do you make a complex menu system intuitively keyboard accessible? 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?
By establishing a standard 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.
<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.
ARIA does not generally change page functionality. In the example above, the
aria-required attribute would not somehow enforce that the user enters something into the textbox. Instead, it simply informs the user that the field is required.
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).
<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. The onkeydown event handler detects whether the user has pressed Enter or the Space bar while focused on the element. While this example is a bit contrived (why not just use an actual button?), it demonstrates the ability for ARIA to add semantics and accessible interactivity to any element.
Form Validation Example
In this example, to allow the browser to navigate to other portions of the page.
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).
For more complex and custom-build widgets, ARIA defines standard ARIA attributes and keyboard interaction patterns to follow. Be sure to follow the standardized ARIA Design Patterns.
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.