Accessibility in Web 2.0 technology

Introduction

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.

Back to top

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

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

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.

Back to top

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

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 (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

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

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.

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

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
here</span>

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 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"
	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 ".

Back to top

Conclusions

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.

Resources

Learn

• 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 .

Comments

Dig deeper into Web development on developerWorks

• Overview
• New to Web development
• Technical library (tutorials and more)
• Forums
• Open source projects
• Events

• 

  developerWorks Premium

  Exclusive tools to build your next great app. Learn more.

• 

  developerWorks Labs

  Technical resources for innovators and early adopters to experiment with.

• 

  IBM evaluation software

  Evaluate IBM software and solutions, and transform challenges into opportunities.

Back to top