Accessibility has become a hot topic as increased awareness and growing requirements demand that applications take into account the needs of all potential users. Accessibility covers not only the Web application, but document, desktop application and hardware, and so on. In the Web application domain, making static Web pages accessible is relatively easy. But for Web 2.0 technology, dynamic content and fancy visual effects can make accessibility testing very difficult. This article introduces the WAI-ARIA standard, which is designed to make future Asynchronous JavaScript and XML (Ajax) widgets accessible. The article also covers accessibility principles in Web 2.0 design and provides several code samples to get you started.


Jie Hu (, Staff Software Engineer, IBM  

Photo of Jie HuJie Hu is a technical leader in the Globalization Development area at the IBM China Development Lab in Shanghai. He has six years experience in J2EE development.

Luo Ling (, Software Engineer, IBM  

Photo of Luo LingLuo Ling is an expert on Dojo development and accessibility technology

Dan Wang, Staff Software Engineer, IBM  

Photo of Dan WangDan Wang has worked in the IBM China Development Lab since 2006 and has participated in several J2EE projects. He is interested in new Web technology including Web 2.0 and mashup technologies.

Shi Wei, Staff Software Engineer, IBM  

Photo of Shi WeiShi Wei Ji is a software engineer from CDL Shanghai. He is an expert of User Technology.

01 September 2009

Also available in Chinese Japanese


Accessibility, which removes the barriers that prevent certain groups of people from accessing information, is becoming a common requirement for Web applications. The groups that accessible Web apps are targeted to help include people with disabilities, mature users, and other people who may be challenged by the visual and physical elements of operating a program. With the help of modern assistive technologies, these people are able to interact with a software application, but only if the application is developed in full compliance with accessibility standards.

With the rapid development of rich client technologies, many Web applications have evolved into the Web 2.0 age. Using Ajax libraries like Dojo or other client-side technologies such as Flash, Web sites are bringing a more robust user experience to the browser. Web elements can be updated dynamically or dragged and dropped anywhere in the page. User experiences once considered only applicable for desktop applications are now available for the Web user as well.

In 2008, the World Wide Web Consortium (W3C), an international group that works to develop Web standards, published the Web Content Accessibility Guideline (WCAG) 2.0. The WCAG 2.0 document defines a list of guidelines that can make Web content more accessible for people with disabilities. It is designed to cover most of the existing Web technologies as well as conceivable future technologies, including dynamic content in Web 2.0 technology.

According to WCAG 2.0, there are some common accessibility issues that are typically found in Web 2.0 applications. These issues can be categorized into four kinds of problems:

  • Document structure
  • Dynamic content updates
  • Enhanced keyboard accessibility
  • Widget accessibility

Within this article, we take a look at each of these problems and propose possible solutions.

WAI-ARIA introduction

WAI-ARIA stands for the Web Accessibility Initiative – Accessible Rich Internet Application suite. It defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with Web 2.0 characteristics such as dynamic content and other advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. WAI-ARIA is a set of tag-libs for normal HTML tags that can only be mapped to useful information by browsers and Assistive Tools (AT) that support them.

WAI-ARIA acts like a contract between the ATs and the Web user interface, which brings more rich information such as roles and states to the Web page user interface. Figure 1 shows the relationship between the Assistive Tools and the Web user interface.

Figure 1. The AT and Web pages relationship using WAI-ARIA
A box representing the Assistive Tools interacts back and forth with another box showing various elements of an application such as Roles, States, Text. All of these elements are governed by a contract which is fed by document elements which is, in turn, fed by the Data and User Interface.

WAI-ARIA mainly has two parts of content: WAI-ARIA Roles and WAI-ARIA States and Properties. Table 1 shows the main taxonomy of WAI-ARIA contents.

Table 1. Main content of WAI-ARIA
Roles States and Properties
Base Types Widget Attributes
User Input Widgets Live Region Attributes
User Interface Elements Drag-and-Drop Attributes
Specialized Regions Relationship Attributes
Landmark Roles

Currently, many Web 2.0 characteristics are not accessible to people with disabilities, especially those who rely on screen readers and those who cannot use mouse devices. WAI-ARIA defines functionality for ATs, which we cover in some detail in the following sections. Additionally, some browsers and Assistive Tools already support WAI-ARIA, such as FireFox 3.0 and JAWS 10.x.

Solve common accessibility Issues in dynamic Web contents using WAI-ARIA

Let's look at the four common problems identified by WCAG 2.0 and discuss some strategies to address them.

Document structure

"Programmatically determined"

Quoting from the document "Understanding WCAG20" (See Resources): "Content that can be 'programmatically determined' can be transformed (by user agents including AT) into different sensory formats (e.g., visual, auditory) or styles of presentation need by individual users. If existing assistive technologies cannot do this, then the information cannot be said to be programmatically determined." In other words, the content must have some sort of consistent self-definition that can be recognized and used by something such as a screen reader.

With the current HTML version, the function or purpose of page elements can't be identified programmatically. Therefore, it is almost impossible for the screen reader to tell the users where they are in the page. Screen readers also can't identify the purpose of a page element. For example, a <div> can be a pop-up window, a text input, or many other things.

WCAG 2.0 states that the Web application should provide a shortcut (usually some links) allowing users to directly locate the main content of a page. This link is recognized as the "skip to main content" link. This helps a user to quickly identify the main content of the page, but it is not enough.

The common solution in GUI accessibility APIs such as IAccessible or IAccessble2 is to provide a "role" attribute for a GUI object, which specifies its purpose. The W3C ARIA standard also defines this "role" attribute. Let's look at the magic of the role attribute and see how you would use it to give your Web application clear structure.

According to WAI-ARIA, all HTML elements in a page can be categorized into the following roles:

Base Types — Roles used to describe the highest level of the role hierarchy. The base type roles are all abstract and should not be used in content. These base roles include composit, landmark, roletype, structure, widget, and window.

User Input Widgets — Roles used as form elements or other common user input widgets. Therefore, the elements with these roles are used to collect and maintain user input. These roles include checkbox, combobox, radio, and so on.

User Interface Elements — Roles used for graphical user interfaces. These elements are quite useful to show the widget types to users. These roles include button, link, tree, and so on.

Document Structure — Roles describing structures that organize content in a page. Document structures are usually not interactive. These roles include article, document, heading, and so on.

Specialized Regions — Roles describing special, self-contained areas of an application user interface. These roles include alert, dialog, progressbar, and so on.

Landmark Roles — Roles that are quite similar to Document Structure, but are intended as navigational landmarks and usually describe an area of the Web page. These roles include application, banner, complementary, contentinfo, main, navigation, and search.

Now take a look at an example of how to use the landmark roles to identify the areas of your Web page. Figure 2 shows a typical Web site (

Figure 2. A typical Web site
A screen shot of the AOL home page with a number of elements including a menu across the top with a search tool, a menu down the left side with multiple sections, and a number of widgets for mail, news stories, advertisements, etc. all arranged in the main content area.

This Web site has several parts: search, navigation, main, and so on. In this case, you can use the landmark roles by writing the code shown in Listing 1.

Listing 1. Adding landmark identifiers to page elements
	<div role="search">
	The search area
	<div role="navigation">
	The navigation area

	<div role="main">
	The main content area

Then the page will be separated in three areas as shown in Figure 3.

Figure 3. The Web site with landmark roles
The AOL screen shot from Figure 2 is repeated, but now there are labeled boxes overlaying the Search, Navigate and Main sections of the page

Dynamic content updates

The most characteristic feature of Web 2.0 is dynamic content updating. With Ajax techniques, some parts of pages can be dynamically changed instead of refreshing the whole page. But this kind of update might cause accessibility problems because it is very hard to alert users with disabilities when updates occur. It's not because we can't tell the changes; they can be caught by JavaScript codes or other approaches. But, not all the messages and changes are intended for the user; some are part of the page's operation, and it would be inappropriate to alert users to them. With traditional techniques, it is not easy to determine which changes should be prompted to users.

Before the use of WAI-ARIA, screen readers like JAWS could read out the messages or texts of elements that received focus as well as some labels having the "for" attribute associated with the ones that could receive focus. In HTML, only links and form elements can receive keyboard focus. Typically, elements that can receive focus indicate that they can be manipulated. However, there are some purely informational elements that are necessary to inform the user, but which don't receive focus. Figure 4 shows a Dojo pop-up window with a message to alert users.

Figure 4. A Dojo pop-up window with a message
A screenshot shows a popup window entitled unmovable and the message You should not be able to drag this dialog which is circled in red

When the window opens, the screen reader cannot tell the user that there's a window open with a message on it. This window also locks the rest of the screen outside its window region. This could cause the users to become lost because they cannot control the Web page and nothing else can be read. Listing 2 shows the source code of this pop-up window.

Listing 2. Source code of the pop-up window
<div id="cantmove" class="dijitDialog dijitContentPane dijitDialogFixed" 
  waistate="labelledby-cantmove_title" wairole="dialog" tabindex="-1" role="dialog"
  aria-labelledby="cantmove_title" widgetid="absolute; top: 194px; opacity: 1; 
            left: 611p;" title="">
   <div class="dijitDialogtitleBar" dojoattachpoint="titleBar" title="unmovable" />
   <div class="dijitDialogPaneContent" dojoattachpoint="containerNode" style="width: 
            auto; height: auto;">
         You should not be able to
         <br />
         drag this dialog

With WAI-ARIA, you can identify regions that will change dynamically as a "live" region. This provides a way for screen readers to understand the dynamic update of the contents. Using this technique, you can add additional functions to prompt the user, provide controls for the live region, determine the amount of new content that would be read, and so on.

With the help of WAI-ARIA "live" region definition, you can solve the pop-up window problem. Listing 3 shows the window text code from Listing 2 with an added ARIA "live" tag.

Listing 3. Altered text section from the pop-up window
<p aria-live="assertive">
         You should not be able to
         <br />
         drag this dialog

After adding this ARIA tag, when the window opens, screen readers such as JAWS 10 will be aware of it and can read the message to the users.

To create a live region using WAI-ARIA, you should add an "aria-live" property to the element with a value of "off", "polite", "assertive", or "rude". These values, which we can also call politeness levels, specify what a screen reader should do when the element value is updated.

  • aria-live="off" tells the screen reader to ignore the updated contents. You would use this with content that isn't considered important.
  • aria-live="polite" lets the screen reader notify users of the updated contents as soon as the users finish their current job. The screen reader might alert users with a sound that there are some updates in the Web page. Users can choose to jump directly to the updated regions or ignore the update and deal with it later. The "polite" value is one of the most common values used for content updates, especially for things like status notification, weather or stock updates, chat messages, and so on.
  • aria-live="assertive" lets the screen reader immediately alert users to the updated contents, and these messages must be read by users. One example of this is an error message.
  • aria-live="rude" is used for updates that are determined to be critical. This value immediately informs the users of the changes and sets the focus to the regions to ask users for input or manipulation.

With the help of WAI-ARIA live regions, you can divide all contents dynamically changed or updated into several criteria levels and then decide how to inform and interact with the users.

Enhanced keyboard accessibility

In HTML, only links and form fields can receive the keyboard focus, which means that the user can use the tab key to set focus on those elements. But in Web 2.0 applications, this basic behavior is not enough. For example, the application may need to focus on the <span> or <div> that displays the important messages. Usually, almost all HTML elements can receive focus using a script language such as JavaScript. But these elements are still not accessible to the screen reader or to users that only use the keyboard.

WAI-ARIA has the ability to enhance the keyboard accessibility. It allows all HTML elements to receive keyboard focus because ARIA extends the tabindex property scope. You can specify the tabindex attribute to any HTML elements.

Table 3 shows the use of the tabindex attribute:

Table 2. tabindex attribute use
Tabindex attributeFocusTab Order
Not presentDefault focus behavior (only form controls and links can receive focus)Follows the default tab order
Tabindex = "0"Can be focused by mouse, keyboard, and JavaScriptDepends on the position of the element in the document
Tabindex="X" (where X is a positive integer between 1 and 32768)Can be focused by mouse, keyboard, and JavaScriptIf the tabindex value is smaller, the tab order is higher
Tabindex="-1"Can only be focused by JavaScriptNo, but the author can focus it with element.focus() as a result of an arrow or other key press

Let's use <span> as an example. The following code is the default <span> element in HTML:

<span>span text here</span>

The following element can't receive focus from the mouse or keyboard; it can only receive focus by using the focus() method.

<span tabindex="0">span text here</span>

The following element can receive focus from the mouse or keyboard. It lets the user use the tab key to focus on this element, and the tab order depends on the position of the element in the document:

<span tabindex="1">span text

The following element can't receive focus using the tab key.:

<span tabindex="-1">span text here</span>

Setting tabindex to -1 means you remove the element from the tab sequence. Therefore, you cannot focus on this element using a keyboard or mouse. But you can still use the focus() method to focus it programmatically.

Widget accessibility

In Web 2.0, widget refers to a component that is not native to HTML or a component that is highly enhanced by a JavaScript feature. There are many widgets in some common Web 2.0 Web sites, and some of them will be too complex to be accessible for people with disabilities. However, there are some solutions to solve this problem. Basically, you should enable keyboard interaction and try to "tell" screen readers what the widget is and what its current states and attributes are. Figure 5 shows a combo box widget.

Figure 5: Combo box widget
A combo box labeled ComboBox with the cursor in the text field with the letter t entered and a drop box with the options two, three, and ten

A combo box enables the user to type in a field, and at the same time chose a predefined value from a list. The combo box is a widget combined by:

  • One editable text field
  • One drop-down button
  • One pop-up item list

The following steps are keyboard interactions of the combo box:

  1. The text field should be in the tab sequence.
  2. When the down key is pressed, the pop-up list should be shown.
  3. Users can change the selection in the list by using the up and down keys.
  4. Users press Enter to enter the selected item into the text field.
  5. Use the auto-complete feature when the user types characters in the text field.

It will not be hard to implement these keyboard features, but it is difficult to tell screen readers the attributes of this widget. With ARIA Roles, States, and Properties attributes, you can let accessible technologies know the properties and current status of a widget.

  • The outer wrap component that contains the 3 items of the combo box should have the role "combobox."
  • The drop-down button should be an HTML button or it should have a role of "button."
  • The pop-up item list should have a role="list".
  • Each item in the list should have a role="listitem".
  • If the text field is not editable it must have aria-readonly="true".
  • Provide a label that labels the combo box by referencing the text field in the combo box.

With key interaction and ARIA support, this combo box widget can be accessible to people with disabilities by using ARIA-supported browsers and screen readers. The code in Listing 4 is the Dojo-rendered HTML code for the combo box in Figure 5, and it shows how Dojo uses ARIA to enhance widget accessibility:

Listing 4. Accessible combo box definition
<label id="combo1_label" name="ComboBox" for="combo1"> ComboBox:  </label>
<div aria-expanded="false" aria-labelledby="combo1_label"
	widgetid="combo1" role="combobox"
	class="dijit dijitReset dijitInlineTable dijitLeft dijitComboBox"
	dojoattachpoint="comboNode" wairole="combobox" tabindex="-1">
<div style="overflow: hidden;">
<div role="presentation"
	class="dijitReset dijitRight dijitButtonNode dijitArrowButton 
              dijitDownArrowButton dijitArrowButtonActive"
	dojoattachpoint="downArrowNode" wairole="presentation"
<div class="dijitArrowButtonInner">?</div>
<div class="dijitArrowButtonChar">▼</div>
<div class="dijitReset dijitValidationIcon"><br>
<div class="dijitReset dijitValidationIconText">Χ</div>
<div class="dijitReset dijitInputField"><input
	aria-owns="combo1_popup" value="one" tabindex="0" id="combo1"
	aria-invalid="false" aria-autocomplete="list" aria-haspopup="true"
	role="textbox" name="combo1" autocomplete="off" class="dijitReset"
	dojoattachpoint="textbox,focusNode" wairole="textbox"
	waistate="haspopup-true,autocomplete-list" type="text"></div>

When the user tabs into this Dojo combo box, the screen reader says, "To move through items press up or down arrow ".


Of course, we cannot cover all accessibility issues in this article, but if you are aware of the issues, you can generally find a way to make Web 2.0 applications accessible. Before WCAG 2.0, the solutions varied, and there were no standard solutions for some common issues. With WCAG 2.0, you can use common features to make your application accessible.

Designing applications to these existing standards will help you provide function to the broadest possible audience, even as new Assistive Tools evolve.



Get products and technologies

  • You can find information for WAI-ARIA from
  • For Dojo technology, you can find out more information from .


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Web development on developerWorks

Zone=Web development
ArticleTitle=Accessibility in Web 2.0 technology