Skip to main content

The WAI forward for accessibility

How IBM is making its Web applications more accessible

David Todd, IBM Human Ability & Accessibility Center

Introduction

Early Web applications were relatively simple to make accessible because, for the most part, accessibility was built into the standard HTML elements that were used to build applications. As the Web evolved, increasingly complex user interfaces began appearing. Many complex interfaces were built with rich Internet widgets which looked like desktop application widgets (e.g., trees, menus, tab list, etc.). However, often screen reader users could not use the new Web widgets because they could not determine the type of widgets they were navigating or how to operate them.

Rich Internet widgets were not accessible to screen reader users because they were built using a combination of JavaScript, CSS and standard HTML elements. However, the composite widgets lacked the information needed to make them accessible to disabled users. For example, there was no mechanism for the widgets to communicate name, role and value information to screen readers. Therefore, applications containing rich Internet widgets were often difficult if not impossible to use.

Because of its longstanding commitment to accessibility, IBM recognized that disabled users were being left behind by rich Internet applications and incorporated the Accessible Rich Internet Applications (WAI-ARIA) specification into its corporate accessibility guidelines in order to bridge the information gap between rich Internet applications and assistive technologies. This page presents how WAI-ARIA techniques and examples are being incorporated into:

Incorporating WAI-ARIA into IBM's accessibility guidelines

IBM maintains an internal Web accessibility checklist that incorporates requirements from Section 508 of the US Rehabilitation Act, the W3C Web Content Accessibility Guidelines (WCAG) 2.0 and requirements drawn from the WAI-ARIA specification. The checklist contains checkpoints along with supporting examples and test techniques on how to implement code to meet the checkpoint requirements. IBM product teams must complete a Web accessibility checklist and store it in the IBM Accessibility Compliance Database prior to releasing a product. Completed checklists are used to generate Voluntary Product Accessibility Templates (VPATs) which are an industry standard for indicating how accessible a product is to people with disabilities.

WAI-ARIA requirements for IBM Web applications

The following sections describe the WAI-ARIA requirements for IBM rich Internet applications. The requirements are documented in the IBM Web checklist, a version of which is available on the IBM Accessibility Web site.

Notify users when input is required

One of the traditional techniques for indicating input data is required before a form can be submitted is to add an asterisk next to fields that require data. However, a screen reader user may fail to find an asterisk next to a required field, especially if form fields are formatted using a layout table, and the asterisk is placed in one table cell and the field label is placed in another cell. Therefore, in addition to an asterisk, IBM requires an aria-required attribute on the field. The aria-required attribute causes a screen reader to notify blind users that a field requires input when the field receives focus.

Notify users when input is incorrect

Prior to WAI-ARIA, there was no consistent way for a screen reader user to identify a field containing invalid data. For example, it is common practice for developers to use a combination of an asterisk and error message to identify a field containing invalid data. However, when a form contains many fields, a screen reader user must explore all of the fields in order to find the offending data. During the exploration process, they may forget what the error message said. Therefore, they must reread the error message and start the exploration process again.

To make it easier for screen reader users to identify fields containing invalid data, IBM requires an aria-invalid attribute on form fields when user input falls outside the expected range of values. The aria-invalid attribute causes a screen reader to notify blind users that they have entered invalid data into an input field and makes the field easier to find in order to correct the problem.

Make Web applications easier to navigate

The IBM Web checklist requires developers to add WAI-ARIA landmark attributes to Web applications in order to make applications easier to navigate for screen reader users. WAI-ARIA landmarks mark important information on a page and enable a screen reader user to jump directly to the information. For example, landmarks provide easy navigation to a page’s main content, search area and navigation area.

Communicate name, role and value information

The IBM Web checklist requires rich Internet widgets to have proper WAI-ARIA name, role and value attributes. For example, a tree constructed from JavaScript, CSS and standard HTML elements must have a tree role on the tree container element. Tree nodes must have a treeitem role. The tree and treeitem roles cause a screen reader to notify blind users that they are interacting with a tree widget and navigating tree nodes. Additional WAI-ARIA attributes are required to indicate which tree node is selected and whether nodes are open or closed.

Navigating rich Internet widgets

Rather than tabbing through a tree, tab list or menu, arrow key navigation is the preferred method of navigation. The IBM Web checklist requires developers to implement arrow key navigation through a combination of the tabindex or activedescendant attribute and JavaScript.

Incorporating WAI-ARIA into IBM's product accessibility reviews

The IBM Accessibility Architecture Review Board (AARB) helps developers incorporate the WAI-ARIA specification into products by conducting user interface (UI) reviews to determine where WAI-ARIA would make a UI more accessible. Product teams schedule walkthroughs with the AARB to demonstrate their UIs, and AARB members give feedback about where WAI-ARIA can be incorporated to make the UIs more accessible. For example, AARB members often see tree, tab and menu widgets without the necessary semantic information to convey name, role and value information to assistive technologies. Therefore, AARB members will recommend applying the proper WAI-ARIA attributes and recommend implementing the WAI-ARIA keyboard navigation model (i.e., arrow key navigation).

Automated accessibility testing with IBM Rational Policy Tester

IBM Rational Policy Tester (RPT) helps to ensure that a Web site is accessible by running close to two hundred accessibility checks and reporting on the results of the tests. Developers and testers can iteratively run RPT on a Web site while correcting problems. For example, developers or testers can run RPT, correct reported problems, and then run RPT again to ensure all errors have been corrected.

The RPT accessibility checks are embodied in a set of JavaScript rules which traverse the document object model (DOM) and generate error messages when accessibility problems are found. Many of the rules are traditional accessibility checks such as verifying a skip to main content link. But recently, WAI-ARIA rules have been incorporated into the rule set. For example, some of the WAI-ARIA rules:

References

  1. WAI-ARIA Overview Copyright © 1994-2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved.
  2. Accessible Rich Internet Applications (WAI-ARIA) 1.0 Copyright © 1994-2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved.
  3. WAI-ARIA 1.0 Authoring Practices Copyright © 1994-2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved.

Join the conversation

RSS

RSS

Subscribe to get the latest IBM accessibility news


Contact us

How can we help your agency or business become more accessible?


IBM accessibility feature articles