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 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
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|
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.
Let's look at the four common problems identified by WCAG 2.0 and discuss some strategies to address them.
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,
<div> can be a pop-up window, a text input, or many other
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 (http://www.aol.com).
Figure 2. A typical Web site
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
<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>
Then the page will be separated in three areas as shown in Figure 3.
Figure 3. The Web site with landmark roles
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
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;"> <p> You should not be able to <br /> drag this dialog </p> </div> </div>
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 </p>
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.
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
<div> that displays the
important messages. Usually, almost all HTML elements can receive focus using
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
Table 3 shows the use of the
Table 2. tabindex attribute use
|Tabindex attribute||Focus||Tab Order|
|Not present||Default focus behavior (only form controls and links can receive focus)||Follows the default tab order|
<span> as an example. The
following code is the default
<span> element in
<span>span text here</span>
following element can't receive focus from the mouse or keyboard; it can only
receive focus by using the
<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 here</span>
The following element can't receive focus using the tab key.:
<span tabindex="-1">span text here</span>
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.
Figure 5: Combo box widget
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:
- The text field should be in the tab sequence.
- When the down key is pressed, the pop-up list should be shown.
- Users can change the selection in the list by using the up and down keys.
- Users press Enter to enter the selected item into the text field.
- 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
- Each item in the list should have a
- If the text field is not editable it must have
- 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" id="widget_combo1" dojoattachevent="onmouseenter:_onMouse,onmouseleave:_onMouse,onmousedown:_onMouse" dojoattachpoint="comboNode" wairole="combobox" tabindex="-1"> <div style="overflow: hidden;"> <div role="presentation" class="dijitReset dijitRight dijitButtonNode dijitArrowButton dijitDownArrowButton dijitArrowButtonActive" dojoattachpoint="downArrowNode" wairole="presentation" dojoattachevent="onmousedown:_onArrowMouseDown,onmouseup:_onMouse, onmouseenter:_onMouse,onmouseleave:_onMouse"> <div class="dijitArrowButtonInner">?</div> <div class="dijitArrowButtonChar">▼</div> </div> <div class="dijitReset dijitValidationIcon"><br> </div> <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" dojoattachevent="onkeypress:_onKeyPress,compositionend" dojoattachpoint="textbox,focusNode" wairole="textbox" waistate="haspopup-true,autocomplete-list" type="text"></div> </div> </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.
- See the current WCAG 2.0 document at the project Web site.
- Dig deeper into implementing WCAG 2.0
directives through the Understanding WCAG 2.0 document on the project Web site.
- Learn more
information about IBM Accessibility.
Get products and technologies
- You can find
information for WAI-ARIA from w3.org.
- For Dojo technology,
you can find out more information from DojoToolkit.org .