Accessibility

In this chapter, we detail how RIA’s technology addresses accessibility.

Definition of accessibility

Web accessibility defines how to make Web content usable by people with disabilities. People with some types of disabilities use assistive technology (AT) to interact with content. AT transforms the presentation of content into a format more suitable to the user, and allows the user to interact in ways different than the author designed. To accomplish this, the AT must understand the semantics of the content. Semantics are the knowledge of roles, states, and properties, as a person would understand them, that apply to elements in the content.

Accessibility problems

AT depends on extracting semantics from the document to represent it to the user. The HTML specification defines a limited number of semantic elements and attributes (for example, data tables within the page, or check boxes and radio buttons with a Web form). Web authors who want to create richer interfaces generally use generic HTML elements (<div> and <span>) to build custom controls. These custom controls tend to have poor accessibility, because an AT cannot determine how to represent the generic HTML elements to the user.

Unfortunately, HTML and other languages does not provide adequate markup to support accessible dynamic content.

Aspects of traditional HTML that make accessible support of dynamic content difficult are as follows:

򐂰 Accessibility relies on abstracting semantics from both content and presentation information. Extracting semantic cues from current HTML content is typically unreliable. Today, semantics are limited to tag element names.

򐂰 HTML allows content to be repurposed for presentation formatting without providing a way to convey semantic information. An example of this is using tables to format content instead of style sheets, or using <div> and CSS to define a custom widget.

򐂰 When combined with script and CSS, HTML can be repurposed to create dynamic custom components without providing a means to convey semantic information to native accessibility architectures designed to support dynamic

Also, authors of JavaScript generated content do not want to limit themselves to using standard tag elements that define actual UI element such as tables, ordered lists, and so forth. Rather, they make extensive use of tag elements (such as <div>) in which they dynamically apply a UI through the use of style sheets and dynamic content changes. HTML <div> tags provide no semantic information.

Therefore, the developer of a Web application does not have the ability to provide the appropriate accessibility information in the markup to support the

accessibility application programming interfaces (APIs) on the target platform.

As most of the Web sites today are rich Internet application (RIA) applications and contains JavaScript, they dramatically affect the ability for persons with disabilities to access Web content. New RIAs render custom widgets, modeling rich desktop components to perform UI updates without having to reload the entire page, much like a graphical user interface (GUI). Legacy GUI accessibility frameworks address these issues through a comprehensive accessibility API and infrastructure to foster interoperability with assistive technologies. These APIs constitute a contract between applications and assistive technologies (such as screen readers) to enable them to access rich dynamic content with the

appropriate semantics needed to produce a usable alternative. No such contract exists between modern RIAs and assistive technologies, thus creating an accessibility gap for persons with disabilities.

Solving the accessibility problem

The Accessible Rich Internet Applications (ARIA) specification, given by the W3C - Web Accessibility Initiative's (WAI) Protocols and Formats working group (PFWG), tries to address these accessibility problems. The ARIA specification addresses the accessibility deficiencies in today’s markup related to enabling RIAs by providing an extension to XHTML1.1, and a technique to support W3C ARIA in HTML 4.01. For this, ARIA defines two specifications:

򐂰 ARIA States and Properties

The ARIA States and Properties specification defines changeable states and properties of elements.

򐂰 ARIA Roles

The ARIA Roles specification helps identify element types that do not change with time or user actions.

For example, RIA developers can create a tree control in HTML using CSS and JavaScript even though HTML lacks a semantic element for that. A different element must be used, possibly a list element with display instructions, to make it look and behave like a tree control. AT, however, must present the element in a

present it as a list, which has display and interaction behaviors different than a tree control, and the user may be unsuccessful at understanding and operating the control.

The ARIA Roles specification provides a way for an author to provide proper semantics on custom widgets (like tree control, in the paragraph above) so that these custom widgets are accessible, usable, and interoperable with assistive technologies. This specification identifies the types of widgets and structures that are recognized by accessibility products by providing an ontology of

corresponding roles that can be attached to content. This allows elements with a given role to be understood as a particular widget or structural type regardless of any semantics inherited from the implementing technology.

The ARIA States and Properties specification is used to declare important properties of an element that affect and describe interaction. These properties enable the user agent or operating system to handle the element properly, even when these properties are altered dynamically by scripts.

Accessibility for Dojo widgets

The widget set of the Dojo 1.0 release has been made accessible using ARIA. It provides keyboard support (widgets work with both keyboard and mouse) for all the core widgets. The ARIA States and Properties specification is applied to the Dojo widgets to allow for full access using screen readers. 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

dijit.util.wai.js, in the dijit branch of the Dojo source tree.

Accessibility implementation

W3C defines an extensible framework for Web authors to declare the role of each element on the page. The WAI Working Group is using this extensible framework to create taxonomy of roles [WAIROLE] and states [WAISTATE] to describe common UI controls that are not represented in XHTML. Web authors can

Note: More information about ARIA, ARIA-Roles, ARIA States and Properties, and ARIA best practices can be found at the following Web page:

http://esw.w3.org/topic/PF/ARIA

namespace features of XHTML that HTML documents do not support. The PFWG has come up with a technique to define the roles and states in the HTML4 documents. It allows the role and state information to be embedded into the class attribute so it becomes part of the DOM when the document is loaded.

Accessibility for RefreshArea widget

One of the important things that should be addressed during development is the RefreshArea widget. RefreshArea’s should be treated as Live Regions. Live Regions, according to ARIA specification, are parts of Web page that the Web author expects to change dynamically. Live Regions enable assistive

technologies, such as screen readers, to be informed of updates without losing the users' place in the content. Live Region settings provide hints to assistive technologies about how to process updates. Live Regions allow text to be spoken to the user without getting misinterpreted. The ARIA State and Properties module defines a set of attributes which are related to Live Regions.

More information can be found on the following Web pages:

http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions http://esw.w3.org/topic/PF/ARIA/BestPractices/LiveRegion

http://juicystudio.com/article/wai-aria-live-regions.php