Open RIA

Before adopting the Dojo Open Source Toolkit for JavaScript as the IBM RIA toolkit of choice, the core widget set had to meet IBM Web Accessibility Guidelines. This was accomplished by incorporating the Accessible Rich Internet Specifications (ARIA) from the World Wide Web Consortium (W3C) into the Dojo core widget set. The core widget set includes the widgets in the dijit directory of the Dojo directory structure. Dojo was the first JavaScript toolkit to provide a fully accessible set of widgets and currently remains as the most accessible of the open source JavaScript toolkits.

In order for Web components to be accessible they must meet three general guidelines that allows all users to manipulate and interact with the controls. They must be:

1. usable via the keyboard
2. usable by people with various levels of vision
3. usable via assistive technology such as screen readers and screen magnifiers.

Naturally there are more detailed steps required to meet and test for full accessibility but these are the three basic principles.

IBM’s first contribution was to the ARIA specification itself. The original idea and implementation originated within the IBM Emerging Technologies Group. It was donated to the W3C where it is going through the W3C Specification process within the Protocols and Formats Working Group that is part of the Web Accessibility Initiative (WAI) of the W3C.

  Fig. 1 - Dojo Tree Control

The first step towards accessibility was to make all of the widgets usable via the keyboard. This was accomplished by adding the appropriate JavaScript keyboard event handlers and behaviors into each of the Dojo core widgets. Consider the Tree control in Figure 1 as an example.

In order to use this widget via the keyboard, the user must be able to move between nodes within the tree and open and close each node. When focus is on a tree node, if an up or down arrow key is pressed, focus will move to the previous or next node respectively. When focus is on an expanded node, pressing the left arrow key will close the node. Likewise, if an expandable node has focus, pressing the right arrow will expand the node and makes its children visible. IBM engineers participated in the definition of keyboard accessibility, and then followed the keystroke behaviors listed in the WAI-ARIA Best Practices Guide to implement it in all of the core widgets.

A screen reader is an assistive technology that speaks the information on the page to a user and allows the user to interact with the page via the keyboard. The screen reader will announce the type of control that is active and any options for the control. Previously when JavaScript was used to create an interactive control such as the tree control, there was no standard mechanism to indicate to the screen reader the type of control and its properties. The ARIA specification now defines these roles and properties. The developer adds the ARIA information to the HTML elements of the control, and the browser provides the information to the screen reader, which in turn announces it to the user. IBM worked with the Dojo engineers to add the necessary keyboard support and ARIA information to all of the Dojo Core widgets.

For the tree control this means identifying the control itself with a role=tree. Each node is identified with role=treeitem. If the node has children, it is also marked with aria-expanded=true if the children are currently visible, and aria-expanded=false if the children are not visible. The currently selected node is identified with aria-selected=true. Figure 2 outlines the roles and properties for a Dojo Tree Control.

  Fig. 2 - Overview of Tree Control Roles and Properties

When the screen reader tabs into this tree control, focus will land on the Egypt node since it is the selected node. The JAWS screen reader will announce the following, “Tree view open, Continents open, Africa open, Egypt, to move through or expand items, use the arrow keys.” All of the Dojo core widgets have been implemented with ARIA information so the screen reader user has full information about each control and its current states and properties.

  Fig. 3 - High Contrast Tree Control

With keyboard and screen reader support accomplished, IBM engineers had to provide support for users with low vision. In order to accommodate low vision issues, the control must work at various font sizes and must not rely on text color or CSS background images to convey critical information. Consider the plus and minus images within the tree control that visually indicate whether or not a tree node is expanded or collapsed. For performance reasons, these images are implemented using CSS. The problem with that approach from an accessibility perspective is that some low vision users rely on setting high contrast mode on their Windows computer to make items on web pages easier to distinguish. High contrast mode removes all background images and color information specified via CSS, and displays the page with just three colors -- foreground, background and selection. In order to support the use of high contrast mode, the IBM and Dojo engineers worked out a mechanism to detect high contrast mode and to provide appropriate text equivalents for background images, and to represent active states via changes in border style rather than just changes in background color. Figure 3 shows the tree control in high contrast mode. The plus and minus background images are replaced with the text characters ‘+’ and ‘-‘, the non-expandable node is indicated by ‘*’ and the selected node has a dotted border.

Figure 4 shows an example of the New Message page in a mail application.

  Fig. 4 - Compose Page

Figure 5 shows the same page in high contrast with black as the background color and white as the foreground.

  Fig. 5 - High Contrast

While the high contrast page is not as aesthetically pleasing, it does convey all of the necessary information to a user, such as text equivalents for the toolbar icon, the active tab page, the icon to close the current tab, and so on.

Making the Dojo core widget set fully accessible was a great example of open source teamwork. While IBM engineers did a majority of the accessibility work, a grant from the Mozilla foundation enabled engineers from the University of Toronto to help with the effort. All of the Dojo engineers gained a greater respect for accessibility and how to create Rich Internet Controls that are usable by all. IBM and the Dojo team are proud that the Dojo Open Source JavaScript toolkits are some of the most accessible open source toolkits available.