Skip to main content

Introduction

The new paradigm of using Ajax (Asynchronous JavaScript and XML) to create rich Internet applications with dynamic interactions and elaborate user interfaces has pushed the limits of existing Web technologies. With the increased complexity of these Web applications has come the concern that the accessibility of the Web will be compromised.

In addition, because the applications themselves are becoming more complex to build, a number of toolkits have been created to make the process easier. Many of these toolkits do not address accessibility. Dojo is an open-source JavaScript toolkit for building Web 2.0 interactive applications that is being updated to address accessibility issues. The widget set of the Dojo 0.9 release has been made accessible using Accessible Rich Internet Applications (ARIA) techniques. Using an accessible toolkit such as Dojo allows the creation of Web 2.0 applications without compromising accessibility.

Dojo overview and timeline

The goal of Dojo is to make building sophisticated Web applications faster and easier. The toolkit provides an abstraction layer for the coding differences between Internet browsers. A Web developer codes to the Dojo application programming interfaces (APIs) and the Dojo code efficiently handles the nuances of the browsers, intricacies of Ajax and back-end data integration. In addition, Dojo provides a rich set of user-interface widgets that are accessible and can be richly styled for a custom theme.

The Dojo 0.9 beta was released on July 3, 2007. This is a major rewrite of the Dojo code from the previous 0.43 release. The focus of the 0.9 and subsequent 1.0 release is performance, code size, build customization, and custom themes. In a departure from previous Dojo releases, the API of the 0.9 release is not backwards compatible with the 0.4 release. This important change was not taken lightly by the Dojo team but was deemed necessary to allow for the significant code re-architecture to move Dojo from good to great. The early feedback has been positive - Dojo is faster, smaller, and more accessible!

Dojo 1.0 core widget set - dijit

A core set of Dojo widgets is being rewritten for the 1.0 release. This is the dijit component of the Dojo toolkit. The goal of the rewrite is to provide:

  • Standard APIs.
  • A standard look and feel.
  • Customization using CSS.
  • Support for data integration.
  • Internationalization.
  • Accessibility.

In order to achieve these goals, the code has been streamlined. There are fewer options when creating the widgets in order to maximize performance and leverage browser support for Cascading Style Sheets (CSS). Drag and drop is no longer as widely implemented within the widgets and not all drag and drop operations will be keyboard accessible in the first release. The following browsers are supported by the Dojo core Widget set: Internet Explorer (IE) versions 6 and 7, Firefox 2, and the latest version of Safari/Webkit.

Applying ARIA to Dojo

When the original Dojo user-interface components were first created, the goals were high-performance, sophisticated widgets. The controls originally worked only with the mouse and used Cascading Style Sheets (CSS) background images to create a look and feel that could be easily customized by application designers. Accessibility for persons with disabilities was missing. IBM contributes resources to work within the Dojo open-source community to address these accessibility shortcomings.

Keyboard support
The first step is to make the widgets work with the keyboard as well as the mouse. Most applications are created using form controls and links to allow the user to tab from component to component. As the user-interface components get more sophisticated, interaction can require excessive tabbing to accomplish simple tasks. The IE and Firefox browsers allow any HTML element to receive focus by adding a tabindex attribute to the element. Using this technique, any element can receive keyboard focus and arrow key navigation can be implemented. Now users can tab between controls and use the arrow and other keys to navigate within the component rather than relying solely on the Tab key for navigation and interaction.

Widgets all need to be activated using the keyboard as well as the mouse. There is a special onklick event (misspelling intentional to indicate the Keyboard support - although the name may change) implemented in the dijit system to provide support for a mouse click, Enter key press or Spacebar key press to invoke an action. By subscribing to the onklick dijit event, the implementation of keyboard and mouse activation of an element is implemented by the dijit infrastructure. This event is utilized by the core dijit widget set and is available to developers building custom widgets.

Using these techniques, the Dojo widgets are being updated for full keyboard accessibility. The keystrokes used mimic the desktop equivalents of the user-interface components wherever possible. An industry consortium is working to define the style for user-interface components used on the Web so that all applications will behave in a similar manner and a user will not have to learn a new set of keystrokes for each individual Web application.

Assistive technology support
Just being able to navigate through an application is not enough; the user must understand the function of each component in order to know what keystrokes and interactions are possible. The ARIA roles and states are applied to the Dojo widgets to allow for full access using screen readers. The screen reader user can now hear the type of each component and its current state. Consider a tree component. When screen reader users encounter the tree component they are informed that it is a "tree." The user can then navigate through the tree using the arrow keys and get detailed information from a screen reader about the level and state—expanded or collapsed—for each tree node and what level that node is within the tree.

Support for ARIA is built into each widget by adding the role and initial state information into the template that is used to generate the widget or by scripting within the widget. Web application developers using the Dojo 1.0 widgets do not need to be aware of the details of ARIA support. Developers creating new widgets or customizing existing widgets need to be aware of the dijit APIs for supporting ARIA. These APIs are found in the dijit.util.wai.js in the dijit branch of the Dojo source tree.

dijit.util.wai.setAttr/*DomNode*/node,/*String*/ ns, /*String*/ attr,/*String|Boolean*/value) is used to set an ARIA role or state. For example:
dijit.util.wai.setAttr( focusNode, "waiRole", "role", "treeitem"); or
dijit.util.wai.setAttr( focusNode, "waiState", "expanded", "true");

There are also dijit.wai APIs to get or remove attribute values:
dijit.util.wai.getAttr(/*DomNode*/node, /*String*/ ns, /*String*/ attr, /*String|Boolean*/value);
dijit.util.wai.RemoveAttr(/*DomNode*/node, /*String*/ ns, /*String*/ attr, /*String|Boolean*/value);

Low-vision support
One of the requirements of Section 508 of the U.S. Rehabilitation Act that is that Web pages run with cascading style sheets turned off. (At IBM, this is implemented as CI 162 Web Accessibility checkpoint 1.3f, "Web pages are readable without requiring style sheets.") This Section 508 requirement was created before browsers and assistive technologies provided consistent support for CSS. At that time, users who have low vision often would create a separate, personal style sheet to provide the necessary font sizes and colors to interact with Web pages. The user would indicate to the browser to use the personal style sheet rather than the one provided in the Web page. Today, browser and assistive technology support for CSS is more comprehensive. Many sophisticated Web applications use extensive CSS positioning to create complicated layouts. These applications will not run well if CSS is turned off. This includes the Dojo widget set.

Web applications that use the Dojo widget set will not be able to claim compliance to U.S. Section 508 Technical Standard 1194.22 Web-based intranet and internet information and applications part d: Documents shall be organized so they are readable without requiring an associated style sheet but they can claim that "equivalent facilitation" for vision impairments has been provided. This means that the user can override font sizing and colors and that the Web application is still usable by people with vision impairments without turning CSS off. For Dojo, this means that all font size information is encoded in relative measurements and all of the widgets support high-contrast mode set using the operating system.

High-contrast mode
The use of CSS background images to create the look and feel of the components causes accessibility problems. If the operating system high-contrast mode is enabled, the images added using CSS are no longer displayed. A user with high contrast enabled can no longer see the user interface, making the application unusable. The simple solution would be to require all Dojo components to use real HTML <img> elements. There are performance problems with using <img> elements because downloading each one requires interaction with the Web server. CSS background images are used for performance reasons because all of the necessary images can be combined into one file for download, and the appropriate part of the image can be made visible using standard CSS properties. In addition, designers can easily customize the look and feel of an application by modifying the CSS. When using HTML <img> elements, customization requires modification of the HTML markup or JavaScript code. Thus, allowing the use of CSS background images to create the widgets was important for Dojo.

This problem is solved in Dojo by checking for high-contrast mode when the widgets get loaded. If high-contrast mode is detected, an additional style sheet is added to the body element of the page. This is NOT a style sheet to provide a set of high-contrast mode colors and styles - it is an enhancement to the existing style sheet to enable text equivalents for the items that rely on CSS images.

For example, in the default Dojo theme called tundra, the close icon for a dialog box is represented using a CSS background image of an x within a shaded circle which is displayed in the upper right hand corner of the dialog box (figure 1).

Sample dialog box with CSS background image used for the close icon.

Figure 1

Within the dialog template there is an additional span that contains the character 'x' to serve as the text alternative for the background image icon. This span has a style of .closeText which is defined as follows:

.dijitDialog .closeText {
display:none;
position:absolute;
}

Notice that the closeText style is encapsulated within .dijitDialog so this style applies when it is cascaded within an element which has the .dijitDialog style applied. The span with .closeText applied is set to display:none. The dijit.css style sheet contains an additional style:

.dijit_a11y .dijitDialog .closeText {
display:inline;
}

When high-contrast mode is detected the .dijit_a11y class is applied to the body element of the page and now the span with class .closeText is made visible via the display:inline directive. In high-contrast mode, the background image of the close icon is no longer visible but the character 'x' is displayed (figure 2).

Sample dialog box in high-contrast mode. The CSS background image used for the close icon is not visible. The character x is displayed instead.

Figure 2

In some cases, rather than using an image at all, an HTML entity character is used such as, ▼ - the Unicode black down pointing triangle (?). This character is used to provide the down arrow character to indicate a popup is available. This provides some issues for screen readers that may not correctly speak the HTML entity character, but the ARIA describedby and labelledby attributes are used to provide the correct text description for the character when necessary.

Summary

The paradigm shift to a dynamic Web does not have to compromise accessibility. Using Accessible Rich Internet Application (ARIA) techniques and good coding practices, Web applications and toolkits for building Web applications can be made accessible. Dojo is an open-source JavaScript toolkit that supports easy-to-build, next-generation Web applications while also promoting accessibility.

About the author

Becky Gibson is a Web Accessibility Architect in the IBM Emerging Technologies Group. She focuses on accessibility and the Web and is currently assisting with the development of the Accessible Rich Internet Applications (ARIA) specification and implementing accessibility in the user-interface components of the Dojo Open Source Toolkit for JavaScript. Becky has been an active contributor to the W3C Web Content Accessibility Guidelines (WCAG) working group. Becky came to IBM through Lotus and Iris where she worked on Lotus 1-2-3, Lotus Notes, and Workplace.

The IBM approach

Open computing and accessibility

Open computing and accessibility