Dojo Accessibility Strategy

Support High Contrast /Images Off

NOTE:As of February, 2007 the High contrast mode accessibility strategy has changed. Dojo will NOT be using background images to convey information. Since Dojo will use real img elements there is not a high contrast issue and separate a11y versions of the widgets will not be necessary. This documentation will be updated when the strategy for creating multiple themes is in place. -Becky

Customizing the Dojo Widgets look and feel is very important, as is performance. The Dojo team uses background images in the creation of the widgets because it allows the look and feel of the widgets to be easily customized by modifying the CSS.In addition, using CSS allows several images to be combined into one file and then the proper subset of the image to displayed using positioning. Thus all of the images for a particular widget element can be retrieved via one HTTP request rather than a separate request for each separate image file.For these reasons, Dojo did not want to require the use of image elements when creating widgets. This presents a problem for users with high contrast mode settings because in this mode, background images are not displayed. The solution is to create an accessible version of each widget which will work in high contrast mode.

The accessible version of each widget will be derived from the original widget.Then, only the necessary methods need to be overridden and the general functionality of the widget is maintained. Dojo already has a mechanism to load a particular widget class based on the technology in use so this has been extended to accessible widgets as well. When high contrast or images mode is detected, the accessible version of a widget will be loaded if it exists.

The accessible version of a widget may use HTML img elements to replace the CSS background images used in the widget, or in some cases, it may fall back to the HTML default version of the control.The checkbox widget uses CSS background widgets to create a graphical look and feel for the Dojo checkbox.Since that graphical look and feel and coloring will be lost in high contrast mode, the solution for the checkbox is to fall back to the default HTML input type=checkbox element in high contrast or images off mode.The dojo.widget.checkbox.a11y class is defined within checkbox.js and is a subclass of dojo.widget.checkbox. It overrides only the necessary methods to implement the accessible version of the checkbox.

The TabContainer widget uses background images to create the close icon on tabs that can be closed.Since there is no HTML alternative for the TabContainer, the accessible version uses img elements in place of the CSS background images.The TabContainer widget uses a TabButton widget to create the tabs.A dojo.widget.a11y.TabButton widget creates the tabs using an img element rather than a background image.The img element will display when the system is in high contrast mode. There is still a possibility that the user may not be able to discern the colors in the close image and will turn images off.With images turned off, the alt attribute of the image element will display and allow the user to properly interpret and interact with the tab.

The main functionality of the TabContainer is maintained in that module.The section of the TabContainer that needs modification to support high contrast and images off mode, the tabs, have been separated out into a separate widget.Thus the minimal adjustments needed to support high contrast and images off mode accessibility are provided in the helper a11y.TabButton class.

Support Device Independent Interaction

One way of providing keyboard support in HTML is to use form and list elements which can accept keyboard focus by default.The user can use the tab key to navigate to these types of elements.The problem is that building sophisticated widgets using these elements in not practical. And, navigating via only the tab key can be very tedious.The solution is to provide full keyboard support within the widgets using additional keystrokes such as the arrow keys to provide more intuitive navigation.

One of the keys to supporting the keyboard is to allow focus to be set to any element.The tabindex attribute can be used to include additional elements in the tab order and to set programmatic focus to them.This was a feature implemented in Internet Explorer that has been extended to Firefox and Mozilla.The following table outlines the use of the tabindex attribute:

Tabindex Attribute Value	Focusable via mouse or scripting via element.focus()	Tab Navigation
not present	Follow default behavior of element (only form controls and anchors receive focus)	Follows default behavior of element
zero - tabindex="0"	Yes	In tab order relative to element's position in document
positive - tabindex="x" (where x is a positive integer between 1 and 32768)	Yes	tabindex value directly specifies where this element is positioned in the tab order
negative - tabindex="-1"	Yes	Not in tab order, author must focus it with element.focus() as result of a key press.

Adding a tabindex of -1 to an element allows the element to receive focus via JavaScript using the element.focus() method.This is used to allow arrow key navigation to elements.Each element that can be navigated to via arrow keys must have a tabindex of -1 to allow it to receive focus.A keydown event handler can determine the next object to receive focus and call that element's focus() method.In addition, the style of the element may need to be updated in order to show the focus as brower's are inconsistent in displaying focus for items that receive focus programmatically.

In order to assist with key event handling, an onkey event has been added to Dojo to normalize key events. The appropriate key event, either onkeydown or onkeypress, will be used depending upon the browser.The key codes have been normalized as well. See dojo.event.browser class in dojo.event.browser.js.

Device Independent behavior means more than just supporting the keyboard. Where ever possible use the most generic event handler possible. For example, consider a widget where the down arrow key selects an element in the widget.The selection needs to be distinguished with a specific style.Rather than modifying the style of the element when processing the down arrow key event , focus the item from the down arrow key event handler and change the style via a focus event handler. This way, if focus is set from a means other than the keyboard such as a voice input system, the styling is properly set and does not depend solely on keyboard actions.

When implementing keyboard navigation, the ideal solution is to mimic the behavior of the operating system..For example, the right and left arrow keys are used to expand and collapse nodes in a Windows tree control and the up and down arrow keys move between nodes in the control.Unfortunately it is not always possible to mimic the operating system or browser behavior because the widgets may not be able to capture the necessary keys. A group of industry representatives are working to create a style guide to describe the navigation and behaviors of Web widgets. When completed, this Style Guide will be provided to open source and Dojo plans to implement the recommendations.The Style Guide will attempt to normalize the differences between operating systems and provide a generalized solution for Web components

Implement ARIA Specification

ARIA techniques allow creating sophisticated UI components using scripting which can be identified to assistive technology. In the future, user agents can also make use of this information to provide additional visual clues about components as well. For example, client side validation of a text entry component that was marked using the ARIA invalid attribute could be visually identified by the browser rather than requiring the developer to provide a specific style or text identification on the component.



The ARIA information will be added into the base widget modules rather than the accessibility extension to insure that the ARIA information is updated whenever behavior changes are made to the widget. Methods have been added to Dojo to enable setting the ARIA information. The roles and states for a widget can be set via the widget template or within the widget scripting code. The details of these methods are discussed later in this document. In addition to providing the roles and states for each component, there are some architectural considerations as well. For components that represent a hierarchy, such as a tree or menu, it is important to identify parent and child relationships. For items where position or count are important it may be necessary to hierarchically group elements or identify a set of related elements as a group. In some cases there are specific ARIA roles for grouping items such as treegroup for tree items within the same level. If no specific grouping role is provided the generic group role can be used.