The Accessible Rich Internet Applications (ARIA) Best Practices Guide (BPG) is intended to provide readers with an understanding of how to use ARIA to create an accessible Rich Internet Application. The ARIA BPG starts with a review of the ARIA Roadmap, which identifies accessibility deficiencies in today's markup related to enabling Rich Internet Applications (RIAs). It continues with a description of how the Web Accessibility Initiative's (WAI) Protocols and Formats working group (PFWG) plans to address these deficiencies through several W3C standards efforts, with a focus on the ARIA specifications.
The BPG is meant to accompany the Roles for ARIA Specification and the States and Properties for WAI-ARIA specifications to aid in the understanding.
Interoperability and Today's Web Content
Aspects of traditional HTML make accessible support of dynamic content difficult:
- 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 elements names.
- HTML allows content to be repurposed for presentation formatting without providing a way to convey semantic information. A common example of this is tables used to format content rather than style sheets.
- 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 GUI content.
- HTML lacks the ability to attach meaningful metadata about document structure.
- HTML elements commonly used for repurposing produce custom components that are not keyboard accessible.
- Identify the role of the DIV as a pop-up menu
- Alert assistive technology when these elements have focus
- Convey accessibility property information, such as whether the pop-up menu is collapsed or expanded
- Define what actions can be formed on the element other than through a device-dependent means through the event handler type (onmouseover, onclick, etc.)
Figure 1.0 illustrates a typical DOM node in a Model-View-Controller architecture. On the node, data, or the "Model", which should include semantic information, is separated from the user interface presentation, the "View." Here, the document element is managed by the user agent based on the default behavior of the element. The user agent's default behavior at the document element forms the controller. Placed between the DOM node and the assistive technology is a box containing the contract provided by the user agent to the assistive technology. This data includes typical accessibility information found in the accessibility API for many accessible platforms for GUIs (role, state, caret, selection, text, hypertext, name description, parent/child information, parent/child information, and relations). For HTML and other W3C markup, the accessibility information provided solely depends upon what the element's tag--and any accessibility attributes that map to that tag--provides. For example, the accessible role of a table is table. The author provides an accessible description by assigning a title attribute.
Filling the Gaps with ARIA
Deficiencies in HTML make the task of creating accessible RIAs difficult or impossible. Most of these problems can be addressed through the use of the W3C ARIA specifications. Problems ARIA addresses include:
- Incomplete keyboard support in HTML and XHTML
- Inability to provide the necessary semantics to enable full interoperability with Assistive Technologies
- Unusable keyboard navigation due to a dependence on tabbing
- Lack of structural semantics to assist content restructuring for diverse users
The ARIA specifications include:
- Roles for Accessible Rich Internet Applications
- States and Properties Module for Accessible Rich Internet Applications
- XHTML Role Attribute Module Specification (included in ARIA States and Properties Module)
Table 1 lists gaps in accessibility support in HTML, mapping them to the ARIA specification and feature that address each gap.
Table 1. Accessibility Gap in HTML Mapped to ARIA Specifications
|| GAP in (X)HTML || ARIA Specification filling the gap || Specification feature || || Full Keyboard focus with author control over what is included in the tab order || States and Properties || tabindex modifications || || value and value change notification || States and Properties || valuenow, valuemax, and valuemin. valuenow changes mapped to accessibility value change events || || state and property change notification || States and Properties || States and Properties mapped to accessibility state or property change events || || GUI-supporting states and properties || States and Properties ||All non-abstract States and Properties || || Live region properties || States and Properties || Live region properties || || Device Independent Navigation || XHTML Role Attribute Module, Roles for ARIA, States and Properties || XHTML role landmarks, Region, Directory roles in Roles for ARIA, Drag and Drop Properties of the States and Properties Module || || Role Information (for re-purposed) markup || Roles for ARIA || All non-abstract roles in the taxonomy || || Relationships and Labels || States and Properties || labelledby, controls, flowto, owns properties || || Descriptions or help || States and Properties, Roles for ARIA || special describedby relationship property referenced to the description role in Roles for ARIA ||
ARIA may also be used to improve the accessibility of static (X)HTML documents. The XHTML role landmarks can vastly improve navigation of static (X)HTML by providing device-independent landmarks that any site can use. Once set, the user agent or assistive technology can assign a common set of keys or discrete device-specific inputs to move programmatic focus to the corresponding document parts. The ARIA states and properties provide missing form control properties, indicate invalid and required, and flag (X)HTML form controls with the appropriate properties. Finally, ARIA roles provide a presentation role that can be applied to tables used only for layout. This directs the user agent to tell an assistive technology that the table is only presentational and is used for layout purposes only. This eliminates the need to rewrite existing applications to use a style sheet to reproduce a table layout.
Applicability to XHTML and HTML
The ARIA States and Properties Module defines a collective extension to XHTML that includes:
- The addition of the XHTML 1.X role attribute module, which provides for the role attribute and standard document sections that aid navigation
- Changes to TABINDEX to allow the author to set keyboard focus to all XHTML elements while specifying if and where the elements may show up in the tab order.
- States and properties needed to enable an author to provide accessibility semantics to assistive technologies for RIAs
The ARIA Roles for Accessible Rich Internet Applications specification provides role values needed to support rich internet applications. The common role values provided in the specification are defined in a taxonomy using an RDF and OWL. The RDF/OWL role taxonomy uses semantic web technology to define a class hierarchy and inheritance model to show state and property inheritance as well as related concepts for the roles in other industry applications. The role taxonomy establishes a basis for extensibility of constructions of new taxonomies in the future. For ARIA 1.0, developers should use the taxonomy to determine what states and properties a particular role can support. Role values are referenced using a qname.This example uses roles and states in XHTML to convey that a
<?xml version="1.1" encoding="us-ascii"?>
<!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN" http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
As this example shows, extensibility to XHTML, for ARIA, is achieved through namespaces (i.e.: aria:haspopup). HTML documents do not support namespaces, so the required accessibility role and state metadata cannot be included directly in these documents. In HTML 4, authors can define accessible role and accessible states as keywords in the class attribute, then use an ECMAScript library to parse the class keywords and copy them into the appropriate role and state namespaces after the document has been loaded. This enables provision of ARIA states and properties while circumventing the HTML validator by using the class attribute.
After declaring any classes used for styling, the accessible DHTML control defines a class of "axs". This signals to the ECMAScript compatibility library that this element defines additional role and state information. The next class in the space-separated list of classes is the DHTML role. The remaining classes in the class attribute list represent state information.
A state is a key-value pair, separated by a hyphen. For example, to represent that a checkbox control is currently checked, one could use class="axs checkbox checked-true". Because checkboxes are so common, a true Boolean state may be represented simply by the state name. So instead of class="axs checkbox checked-true", one can simply say class="axs checkbox checked".
For more details see the : Embedding Accessibility Role and State Metadata in HTML Documents.
Simple Tree Widget Example
Consider this simple tree widget example in XHTML: Simple Tree Widget example.
Brief Introduction to the Use of Semantic Web Technology
For years, assistive technologies and application developers have lacked a mechanism to describe the user interface objects in Web applications. When creating new custom interface component, RIA developers have difficulty informing assistive technologies of what UI properties to expect from the UI component and of what other UI components known to the AT that the component resembles.
Semantic Web Technology is a World Wide Web technology, represented in natural language, that is machine-processable. The Roles for ARIA specification uses the semantic web technologies Resource Description Framework (RDF), a way to describe a resource; RDF Schema (RDF-S), a knowledge representation language; and the Web Ontology Language (OWL) to represent the roles in a class hierarchy. OWL describes classes and their properties, along with their related properties and instances.
In the case where gridcell is used in XHTML:
the qname wairole:gridcell expands to http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#gridcell resolves to the gridcell OWL class with ID of "gridcell" represented here from the ARIA Role taxonomy:
<rdfs:subClassOf rdf:resource="#section"/> <rdfs:subClassOf rdf:resource="#widget"/> <role:baseConcept rdf:resource="http://www.w3.org/TR/html4/struct/tables.html#edef-TD"/> <role:scope rdf:resource="#row"/> <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#expanded"> <role:default>undefined</role:default> </role:supportedState> <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#readonly"> <role:default>false</role:default> </role:supportedState> <role:supportedState rdf:resource="http://www.w3.org/2005/07/aaa#selected"> <role:default>undefined</role:default> </role:supportedState>
Here we see gridcell represented as an OWL class. We also see that RDF-S is used to indicate that gridcell is a subclass of the OWL classes section and widget. So, a gridcell is a section (structural) and a widget. We also see that it has a base concept of <TD> in HTML. We also see that gridcells have a scope within an OWL class of row. Finally, we see that gridcell explicitly supports the expanded, readonly, and selected states from the ARIA States and Properties module, so the readonly property specified by the developer is valid.
Due to inheritance from widget and section, gridcell inherits some ARIA states and properties (atomic, busy, channel, controls, disabled, live, relevant, templateid, and a set of global states). By referring to the ARIA states and properties module you can see that, based on the properties used, a gridcell can take on live region properties, a disabled state, and a templateid to help assistive technologies map customizations to. It also inherits a number of global states defined by the ARIA role taxonomy.
These capabilities will facilitate test tool validation of ARIA-enabled applications and it can help assistive technologies process ARIA semantics provided in a RIA. OWL facilitates greater machine interpretability of Web content than that supported by XML, RDF, and RDF Schema (RDF-S) by providing additional vocabulary along with a formal semantics.
Through the use of semantic web technology, the ARIA standards team was able to build a rich taxonomy of common roles used by RIAs. The role taxonomy will help RIA developers and AT vendors to determine when to use an ARIA role and how to process it respectively. RIAs re-purpose existing XHTML markup. The ARIA Roles specification helps the accessibility testing tools to validate whether the ARIA properties provided are supported for the associated role (XHTML DTD cannot do this validation because the DTD validates attributes supported by the associated XHTML element). The supported ARIA properties for an XHTML element change depending on the ARIA role assigned.
Preview of the Rest of this Document
With an understanding of the issues, the BPG provide direction on how to make RIAs keyboard accessible; then follows guidance on how to provide layout and structural semantics within the web page. These semantics are critical to enable assistive technologies to provide a usable experience when processing RIAs with rich documents on the same page.
The BPG will then introduce the different types of relationships provided by ARIA followed by: guidance on dynamic document management; use of ARIA Form properties, ARIA Drag and Drop, and then the creation of ARIA-enabled alerts and dialogs.At this point, you will have a good understanding of how ARIA provides for interoperability with assistive technologies and support for a more usable, accessible experience. The BPG will then discuss the construction of accessible simple and complex ARIA examples and some reusable component libraries available to help produce ARIA enabled applications quickly. The BPG appendix provides substantial information including code samples for developers of user agents, assistive technologies, and web pages.