WAI-ARIA 1.0 Primer

An introduction to rich Internet application accessibility challenges and solutions

W3C Working Draft 16 September 2010

This version:
Latest version:
Previous version:
Lisa Pappas, SAS and STC
Richard Schwerdtfeger, IBM
Michael Cooper, W3C


The WAI-WAI-ARIA Primer introduces developers to the use of WAI-ARIA [ARIA] for addressing the accessibility of dynamic Web content for people with disabilities. This primer explains the accessibility problems posed by hybrid technologies such as Dynamic Hypertext Markup Language (DHTML) and Asynchronous Java and XML (Ajax). It introduces the technologies to map controls, Ajax live regions, and events to accessibility application programming interfaces (APIs), including custom controls used for Rich Internet Applications. The primer also describes new navigation techniques to mark common Web elements with roles such as menus, primary content, secondary content, banner information and other types of Web structures. These new technologies can be used to improve the accessibility and usability of Web resources by people with disabilities, without extensive modification to existing libraries of Web resources. This document is part of the WAI-ARIA suite described in the WAI-ARIA Overview.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a Public Working Draft by the Protocols & Formats Working Group of the Web Accessibility Initiative. It supports the Accessible Rich Internet Applications (WAI-ARIA) [ARIA] specification, providing introductory information about the accessibility problem that WAI-ARIA is intended to solve and explaining the technical approach. This version contains information that was previously in the WAI-ARIA specification itself but was deemed introductory and distracting from the main goal of defining Accessible Rich Internet Application features. That information is, however, important for many people to understand WAI-ARIA fully so is provided in this resource. A history of changes to WAI-ARIA 1.0 Primer is available. The summary of actions made in response to comments on the previous two WAI-ARIA 1.0 drafts includes changes that affected this document.

The PFWG seeks feedback on the information explained in this document. The PFWG asks in particular:

Start with the instructions for commenting page to submit comments (preferred), or send email to public-pfwg-comments@w3.org (comment archive). Comments should be made by 29 October 2010. In-progress updates to the document may be viewed in the publicly visible editors' draft.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

The disclosure obligations of the Participants of this group are described in the charter.

Table of Contents

  1. 1. Introduction
    1. 1.1. The Problem
    2. 1.2. Requirements
    3. 1.3. Solution
    4. 1.4. HTML Accessibility API Support Analysis
  2. 2. Filling the Gaps for Content Delivered to Desktop Browsers
    1. 2.1. Use of New Provisions for Keyboard Focus and Semantics to Support Platform Accessibility APIs
      1. 2.1.1. Provision of the Role Attribute: "What is the Object?"
      2. 2.1.2. Provision of the Accessibility State Information: "What meaningful properties does this object have at this time?"
      3. 2.1.3. Provision of the Keyboard or Input Focus: "What object am I working on?"
      4. 2.1.4. Supporting WAI-ARIA in XHTML and HTML 4.01
    2. 2.2. Use of XHTML Role Landmarks to Improve Document Navigation
    3. 2.3. WAI-ARIA Role Taxonomy - Extensible Semantic Role Model, using RDF/OWL
      1. 2.3.1. Interoperability Example: Grid Role
    4. 2.4. Accessibility Events and Event Handling
    5. 2.5. HTML 5 - A Look Ahead
  3. 3. Building Accessible Applications with WAI-ARIA
    1. 3.1. Example: Building a Tree Widget
  4. 4. Reasons for Adopting WAI-ARIA
    1. 4.1. Technical Benefits
    2. 4.2. Business Benefits
  5. 5. Conclusions
  6. 6. Appendices
    1. 6.1. Gap Analysis - Filling the Gaps for (X)HTML in Support of Accessibility API
    2. 6.2. Long Descriptions of Figures
      1. 6.2.1. Long Description of Figure 1.0 Accessibility Interoperability at a DOM Node without JavaScript
      2. 6.2.2. Long Description of Figure 2.0 Accessibility Interoperability at a DOM Node with JavaScript
    3. 6.3. References
    4. 6.4. Acknowledgments
      1. 6.4.1. Participants in the PFWG at the time of publication
      2. 6.4.2. Other previously active PFWG participants and other contributors to the Accessible Rich Internet Applications specification
      3. 6.4.3. Enabling funders

1. Introduction

According to the SecuritySpace Technology Penetration Report, more than 55% of all Web sites today contain JavaScript, dramatically affecting the ability for persons with disabilities to access Web content. New Rich Internet Applications (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 application programming interface (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, creating an accessibility gap for persons with disabilities.

Unfortunately, HTML and other markup languages do not provide adequate support for accessible dynamic content. Until now, the W3C WAI has discouraged the use of JavaScript per Web Content Accessibility Guidelines (WCAG) 1.0 ([WCAG1], Checkpoint 6.1). A number of W3C initiatives underway address this problem using a declarative markup approach. This primer describes a means to bridge the interoperability problem with assistive technologies now by incorporating the appropriate metadata into current HTML and XHTML markup to support today's accessibility APIs. Moreover, the primer provides web developers with a conceptual understanding of WAI-ARIA as a prelude to using the WAI-ARIA specification [ARIA]. WAI-ARIA brings advanced accessibility features of the desktop to the web through the creation of cross-cutting technologies that (X)HTML authors can incorporate in their markup. WAI-ARIA defines roles, states, and properties, where those roles reflect standard GUI elements that are recognized by accessility Application Programming Interfaces (APIs). These metadata that describes these GUI widgets and document structures aides assistive technology vendors in providing accessible, usable solutions. The W3C WAI PF working group is working with User Agent manufacturers, assistive technology vendors, and accessibility tool providers, to ensure an end-to-end working solution.

For an introduction to WAI-ARIA, see the Accessible Rich Internet Applications Suite (WAI-ARIA) Overview. The WAI-ARIA Primer is part of a set of resources that support the WAI-ARIA specification. The Primer provides a basic introduction to the concepts behind and reason for WAI-ARIA, and the WAI-ARIA Authoring Practices [ARIA-PRACTICES] describe recommended usage patterns for Web content developers. The WAI-ARIA Suite fills gaps identified by the Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap) [ARIA-ROADMAP]. These documents serve as important places of clarification where topics appear to be unclear.

1.1. The Problem

Aspects of traditional Hypertext Markup Language (HTML) make accessible support of dynamic content difficult:

  1. Accessibility of dynamic content relies on abstracting semantics from both content and presentational information. Extracting semantic cues from current HTML content is typically unreliable as the cues are limited to tag elements names.
  2. While HTML allows content to be repurposed for presentational formatting, it lacks the ability to attach meaningful metadata about document structure and to convey semantic information. A common example of this is content formatted with tables rather than style sheets.
  3. When combined with script and cascading style sheets (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 graphical user interface (GUI) content.
  4. Custom components built from common HTML elements often are not keyboard accessible.

Authors of JavaScript-generated content do not want to limit themselves to using standard tag elements that define the actual user interface element such as tables, ordered lists, etc. Rather, they make extensive use of elements such as DIV tags in which they dynamically apply a user interface (UI) through the use of style sheets and dynamic content changes. HTML DIV tags provide no semantic information. For example, authors may define a DIV as the start of a pop-up menu or even an ordered list. However, no HTML mechanism exists to:

In short, JavaScript needs an accessibility architecture to write to such that a solution can be mapped to the accessibility frameworks on the native platform by the user agent.

The following diagram illustrates a typical document object model (DOM) node in a Model-View-Controller architecture. Accessibility information surfaced to assitive technologies is provided only by the HTML element's tag name, with only the accessibility attributes that tag can provide.

Figure 1.0 shows that 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.

Accessibility infomation mapped to a DOM element in the Document Object Model
Figure 1.0 Accessibility Interoperability at a DOM Node without JavaScript

The box between the DOM node and the assistive technology contains 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 name 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.

In contrast, with JavaScript, user actions can trigger updates in the data and presentation, but the default accessibility information available in the element tags is no longer valid.

DOM Element with JavaScript controller
Figure 2.0 Accessibility Interoperability at a DOM Node with JavaScript

Figure 2.0 shows the same DOM node provided in Figure 1.0 but with JavaScript acting as the new controller. JavaScript overrides the default user agent behavior at the DOM node. It manipulates the data, content, and style in response to events caused by user interaction to produce custom widgets. In this situation, the default accessibility information is no longer valid and, therefore, the contract is now invalid. Figure 2.0 shows the contract with asterisks in front of role, state, actions, value, event changes, and relations. These asterisks represent potential accessibility errors and gaps in the base markup. These gaps result from the author's inability to provide the new semantic data needed to support the contract.

1.2. Requirements

Any solution to facilitate the creation of accessible rich Internet applications (RIAs) must:

Allow for discovery of custom UI components through the use of Semantic Web technologies
Web ontologies allow for storage of semantic information about objects and how they relate to others in the ontology.
Support today's accessibility architectures
Accessibility architecture today is centered around object technology. Each object in an application or document exposes its accessible properties to an assistive technology.
Allow for separation of content and presentation
Dynamic content authors must be able to store the accessible meta data in the document independent of how it is rendered.
Allow for passive monitoring of the application by an assistive technology
Assistive technology vendors should not be required to poll an application for changes in accessibility information.
Leverage new W3C efforts to solve the problem
This problem needs to be solved quickly. A number of efforts are underway, such that minimal changes may be required to bring them to the level needed.
Be light weight
The solution needs to be light-weight in order to promote adoption by Web authors.
The solution needs to be scalable; it must make simple things easy while making complex things possible.
Like other Web solutions, our solutions must be internationalizable.
Guarantee user agent support up front
User agent manufacturers must be involved up front to ensure support for the solution when the specification is complete.
Involve assistive technology vendors up front
To ensure interoperability, assistive technology vendors need to be involved from day one. The effort must leverage support by AT vendors to ensure that a total solution is available when the specification is complete.
Produce Developer Guidelines during the process
This is a critical mistake made by people creating a new accessibility model. Developers must be engaged early on so that they can contribute feedback and start producing workable solutions early.

1.3. Solution

What is clear from the problem statement is that developers of dynamic web content cannot provide the appropriate accessibility information in the markup to support the accessibility APIs on the target platform. This problem is not limited to HTML. It extends to other markup, including Scaleable Vector Graphics [SVG]. This primer addresses the problem for web content delivered to desktop browsers and introduces you to common extensions to both HTML and XHTML called Accessible Rich Internet Applications (WAI-ARIA) Version 1.0 [ARIA]. The goal is to make these standard features in HTML 5.

1.4. HTML Accessibility API Support Analysis

Using Figure 1.0 as a template for addressing the problem and U.S. Section 508 accessibility standards, Table 1.0 illustrates gaps in the infrastructure and identifies W3C standards that should be used to address the problem. In the right column, table cells that are empty or that indicate a limitation represent accessibility gaps in HTML and XHTML.

Table 1.0 Platform Gap Analysis for Accessible Dynamic Web Content for HTML and XHTML
Required ComponentsWho does what today? (HTML)
FocusChangeDOM 2, 3 events
ActivationUser Agent API
Caret ChangeUser Agent API
Value Change 
State Change 
Selection ChangeUser Agent API
MutationDOM Events
Accessible Actions: 
Event Handler functional information to label the actions 
Access to the available event handlers for enumerating the actions 
State Information: 
Role Information:Limited to standard HTML tag names. (Mix Content/presentation)
Relationships: Parent/childLimited DOM (affected by style) (Mix Content/presentation)
Relationships: (Label, MemberOf - Group, ControllerFor)Limited to HTML (Title, alt, label)
TextCore DOM from parsed HTML
Content selection:Browser-dependent (incomplete)
Font/Font Style Information:Can set but can't get final format
Description/Help:Limited to HTML 4.0 - Alt Text, title text
Accessible value:Limited to form elements
Coordinates (Bounding rectangle, etc.):User Agents. platform accessibility API
Accessible Name: 
Respond Desktop Font/Color Changes:Partial (conflicts with CSS and JavaScript)
Device independent navigation: 
Accessibility API Mapping:Partial - User Agents
Provide focus to all active elements (important for equivalent keyboard access on desktops)Limited to forms and anchors

2. Filling the Gaps for Content Delivered to Desktop Browsers

At this time,W3C WAI Protocols and Formats working group's primary focus is on extensions to HTML 4.01 and XHTML 1.X by extending the host language to include WAI-ARIA with a migration path to HTML 5. This will require the creation of new hybrid document type definitions (DTDs) that incorporate the extensions. This work will be in the Accessible Rich Internet Applications [ARIA] specification. WAI-ARIA will constitute extensions to fill most of the gaps needed to support accessibility API infrastructures and dynamic (X)HTML content. The comprehensive gap analysis of (X)HTML, used to form WAI-ARIA is found in Table 1.0 and how WAI-ARIA fills those gaps. In the future we hope to incorporate WAI-ARIA into many host languages to improve their accessibility. The critical extensions needed to make accessible dynamic Web content accessible, through rich interoperability with assistive technologies, are summarized here:

States, and Property attributes - This is the set of attribute modifications to (X)HTML necessary to provide full keyboard focus and states and properties that may be mapped directly or indirectly to platform accessibility APIs to ensure full interoperability with assistive technologies for WAI-ARIA.

Role attribute - The role attribute, borrowed from the, Role Attribute [ROLE], allows the author to annotate host languages with machine-extractable semantic information about the purpose of an element. It is targeted for accessibility, device adaptation, server-side processing, and complex data description. WAI-ARIA uses the role attribute to provides the role information, in Figure 2 - Accessibility Interoperability at a DOM node with JavaScript to an assistive technology.

Role document landmark values - These values, borrowed from the Role Attribute [ROLE] provides a standard set of role attribute values designed to define pertinent parts of a document (landmarks) for the purpose of accessibility. User agents may incorporate device equivalents, such as key mappings in the case of a desktop user agent, to navigate to these sections of a document.

Taxonomy of WAI-ARIA role values - The necessary core roles found in Accessibility API sets for Windows and Linux as well as roles representative of document structure, such as banner or treegrid. Use of document structure is necessary for assistive technologies to navigate complex documents and to know when they have entered active areas of a Web page such as in the case of a dynamic scripted Web application. The taxonomy is designed to help user agents or authoring tools determine what properties a given role supports and to assist with accessibility API mapping of these properties. The taxonomy will is like a class hierarchy used to convey semantics and structure and includes knowledge about each role. At this time, that taxonomy is modeled using Resource Description Framework [RDF] and Web Ontology Language [OWL].

In short, WAI-ARIA will be used to fix the dynamic accessibility of scripted Web content, in particular the use of JavaScript with (X)HTML markup. They are meant to be cross-cutting and should apply to other markup like SVG. Less critical for (X)HTML but helpful for accessibility will be the descriptive extensions to XML events and the new Access element [XHTML Access]. Web Content Accessibility Guidelines 2.0 calls for the WAI-ARIA properties in guideline 4.1 Maximize compatibility with current and future agents, including assistive technologies (roles, states, properties, and values) and section guideline 1.3 Create content that can be presented in different ways (for example spoken aloud, simpler layout, etc.) without losing information or structure (relationships).

The next section describes how the specifications are used together as well as how they will be implemented in HTML 4.

2.1. Use of New Provisions for Keyboard Focus and Semantics to Support Platform Accessibility APIs

Adaptive technologies, which need to provide alternative access to complex user interfaces authored via HTML, are often left guessing at the semantics behind specific portions of HTML document. As an example, an XHTML document might use a certain HTML construct, such as a collection of DIV tags, to create navigation bars, a site-navigation menu, and other GUI-like user interface widgets. To fix the problem, we incorporate the role attribute, assign the accessible state properties, and give the object focus using the new TABINDEX feature. Addition of this information helps authors to provide the necessary information to enable the user agent to support the accessibility API accessed by the adaptive technology.

2.1.1. Provision of the Role Attribute: "What is the Object?"

Each platform accessibility API has the notion of a "role" for a GUI object. This is the case for Java Accessibility API [JAPI], Microsoft Active Accessibility [MSAA], The Mac OS X Accessibility Protocol [AXAPI], and the Gnome Accessibility Toolkit (ATK) [ATK], or UI Automation for Longhorn [UIAUTOMATION] (called content type in UI Automation). The WAI-ARIA specifications are based on XHTML 1.X and include the role attribute. The "role" attribute takes a qname, enabling authors to reference the role attribute from the WAI-ARIA Roles. In the following example, we use qname to reference the menu role in the WAI-ARIA specification.

Example: Use of WAI-ARIA to incorporate role information information into XHTML 1.x

<?xml version="1.1" encoding="us-ascii"?>
<!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN" 

<html xmlns="http://www.w3.org/1999/xhtml"
        <div role="menu">

WAI used RDF/OWL to model our taxonomy for WAI-ARIA. In fact, if a host language sought to use namespaces or qnames, they could do so to reference the WAI-ARIA role taxonomy. The WAI-ARIA role taxonomy could be used by authoring tool developers to ensure that states and properties assigned to a given role are accurate.

2.1.2. Provision of the Accessibility State Information: "What meaningful properties does this object have at this time?"

Since this is dynamic content, the state of these new repurposed objects will change. The WAI-ARIA specification shall provide the common accessible properties needed to support the accessible state or property information provided by the platform accessibility API defined previously. This specification was created based on an analysis of the accessibility properties defined in MSAA and ATK. The following example extends the previous approach by adding the aria-haspopup accessibility property.

Example: Use of WAI-ARIA to incorporate accessible state information information into XHTML 1.x

<?xml version="1.1" encoding="us-ascii"?>
<!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN" 

            <div role="menu" aria-haspopup="true">

A Windows user agent may now map this property to the Microsoft Active Accessibility state of STATE_SYSTEM_HASPOPUP. Adding or removing this state would result in the Windows user agent sending an EVENT_OBJECT_STATECHANGE event to the assistive technology. The task of the JavaScript page author would be to maintain this state attribute, which can easily be done through the use of Document Object Model calls.

2.1.3. Provision of the Keyboard or Input Focus: "What object am I working on?"

Virtually all adaptive technology solutions, such as screen readers and onscreen keyboards, must know which object currently has focus. For example, an author might want to insert text into the current object with focus or to announce information about the object that has focus. With today's HTML 4.01 and XHTML 1.x, script authors can only provide focus to form and anchor elements yet the Document Object Model Specification allows all elements to receive events including keyboard events. This means that HTML, by design prohibits script authors from making all HTML elements keyboard accessible. This single problem effects usability of Web pages where one gains access to elements by using the Tab key on desktop browsers. This slow, unproductive, approach makes portal navigation difficult because all active elements must be tabbed through to put focus on an active element in the last portlet in a document. To solve this problem in XHTML 1.x, we are incorporating a feature in Firefox and Internet Explorer to define the tabindex for -1. This allows a script author to give an element focus without placing it in the tab order: The following table describes these changes that will be incorporated into the new Accessible Adaptive Application specification.

Accessible Adaptive Application Changes to Support Use of tabindex to give Element Focus
tabindex attributeFocusable with mouse or JavaScript via element.focus()Tab navigable
not presentFollows default behavior of element (yes for form controls, links, etc.)Follows default behavior of element
Negative, e.g. tabindex="-1" YesNo, author must focus it with element.focus() as a result of arrow or other key press
Zero, e.g. tabindex="0" YesIn tab order relative to element's position in document
Positive, e.g. tabindex="33" YesTabindex value directly specifies where this element is positioned in the tab order. These elements will be positioned in the tab order before elements that have tabindex="0" or that are naturally included in the tab order (form elements and links)

The following example shows the introduction of TABINDEX to provide focus to a DIV having the new accessibility meta data:

Example: Use of tabindex to give non-form and anchor elements focus in XHTML 1.x

<?xml version="1.1" encoding="us-ascii"?>
   <!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN" 

        <div role="menu" aria-haspopup="true" tabindex=-1>

2.1.4. Supporting WAI-ARIA in XHTML and HTML 4.01

Unlike XHTML, HTML 4.01 is non-extensible in that it is not possible to extend HTML 4 through the use of namespaces. That said, members of the working group have worked with the HTML working group to agree on a vehicle that does not use namespaces, which at this time is supported by XHTML and HTML which will be supported in HTML 5 when it becomes recommendation. Firefox 3 is leading the way to implement this, and other browser manufacturers are working to support it as well. The technique allows all role values specified in WAI-ARIA (including those specified by the XHTML Role attribute module) to be specified without a namespace prefix. Additionally, WAI-ARIA states and properties shall be represented as aria- followed by the concatenated WAI-ARIA state or property.

Example: Browser supported HTML technique for the tabindex example in section 5.1.3

<html lang="en">
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
</head> <body> <div role="menu" aria-haspopup="true" tabindex=-1> File </div> </body> </html>

In order to validate these extended attributes for HTML and XHTML the WAI-PF working group will investigate the creation of an enhanced schema or DTD for each host language.

2.2. Use of XHTML Role Landmarks to Improve Document Navigation

In addition to the common roles which will reside in WAI-ARIA Roles, both XHTML 2.0, and the XHTML Role attribute module ([ROLE], Section 4) defines a collection of common role, regional, landmarks that define pertinent parts of a document for the purpose of accessibility. User agents may incorporate device equivalents, such as key mappings in the case of a desktop user agent, to navigate to these sections of a document independent of the Web site. The addition of these semantics allows the user agent to provide standardized navigation to common document sections. This is especially important for portals to improve the usability. These may be used as attributes in XHTML 1.x by applying them to sections of the document as shown in this example. Note: since these roles are a part of XHTML they do not need to be namespace qualified.

Example: Use of XHTML navigation role to define a landmark for the navigation section in an XHTML 1.X document

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">    
<html xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
  <title>application/xhtml+xml: Navigation Roles Example 1</title>        
  <link rel="stylesheet" href="css/nav1_xhtml.css"  type="text/css" ></link>    
  <script type="text/javascript" src="../js/globals.js"></script>    
  <script type="text/javascript" src="../js/widgets_xhtml.js"></script>  <link rel="icon" href="http://www.cites.uiuc.edu/favicon.ico" type="image/x-icon" />    
  <link rel="shortcut icon" href="http://www.cites.uiuc.edu/favicon.ico" type="image/x-icon" />    
<body onload="widgets.init()">
<div id="leftnav">         
<h2 class="nav" id="leftnav_label">Career Center Services</h2>         
 <ul title="Career Center Services" role="navigation" aria-labelledby="leftnav_label">        
   <li><a href="http://www.uiuc.edu/">Career Home</a></li>  
   <li><a href="http://www.uiuc.edu/">Career Counseling</a></li>        
   <li><a href="http://www.uiuc.edu/">Pre-Health Advising</a></li>        
   <li><a href="http://www.uiuc.edu/">Services</a></li>        
   <li><a href="http://www.uiuc.edu/">Workshops</a></li>        
   <li><a href="http://www.uiuc.edu/">Resource Center</a></li>        
   <li><a href="http://www.uiuc.edu/">Question Board/FAQ</a></li>  



The example above was taken from the header from the Career Center Web page at the University of Illinois at Urbana-Champaign. Students from this university, under Jon Gunderson's guidance created Accessibility extensions for Mozilla/Firefox, in part, to allow a page author or user to view a list of navigation landmarks. This tool, shown in Figure 3.0, lists the navigation sections on the page. Keyboard navigation of the list of navigation bars causes the corresponding document section to be highlighted. The title for each navigation region displays in the list.

Table of Contents from Landmarks
Figure 3.0 Table of Contents generated from navigation landmarks in the header

Figure 3.0 shows the accessibility extensions for Mozilla/Firefox from the University of Illinois at Urbana-Champaign to render the document landmarks. This picture shows the Firefox browser rendering the University of Illinois Career Career Center home page. In this example. The "List of Navigation Bars" viewer is shown, launched from the extension on the toolbar. The viewer shows that the secondary "Career Center Services" is selected resulting in that section of the document being highlighted in yellow. The Navigation Bar Lists Viewer lists the following list of titles corresponding to the navigation sections:

2.3. WAI-ARIA Role Taxonomy - Extensible Semantic Role Model, using RDF/OWL

The WAI-ARIA role taxonomy was modeled using semantic web technology, in the form of Resource Description Framework (RDF) [RDF] and the Web Ontology Language (OWL) [OWL], as a vehicle to define a knowledge-based class hierarchy for roles. This model shows what states and properties are supported, by each role in the taxonomy. The role in the class hierarchy inherits properties from its ancestors and defines its own properties. Where applicable, semantic web technology is used to define related concepts within other namespaces. This information is critical in determining how to choose a role and how to interact with it. The role taxonomy uses RDF as a way for using data to describe data and provides a W3C standards-based approach to represent this information.

Sample Semantic Map for Taxonomy
Figure 4.0 Example, Partial RDF Map for a possible ButtonUndo role as an extended role to WAI-ARIA

Figure 4.0 shows a basic RDF mapping that defines a set of terms and relationships defining an object. At the center is a Widget object that defines common states and properties for all GUI widgets. The Button object extends Widget and inherits defined accessibility properties from the superclass Widget. It also defines a relatedConcept property to a Link object. The ButtonUndo role extends Button. It has a relatedConcept of an HTML input object. ButtonUndo will introduce Dublin Core meta data such as the description of the object. The terms relatedConcept and requiredState are terms that will be defined as part of the corresponding RDF schema. Each role instance will represent standard Roles found in the platform accessibility APIs of platforms like Windows and Gnome as well as content structure. These roles will form the taxonomy. Although host language browser implementations may reference WAI-ARIA roles without namespaces, the RDF representation for a given role may be referenced using a qname from a Host XML markup language. This examples shows an XHTML reference to a grid role in the RDF representation of the WAI-ARIA taxonomy:

<div role="grid"> whereby grid expands to: http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#grid in the button markup.

The power of this design is that it enables a web authoring tool to go back into the corresponding RDF/OWL markup and determine what properties it supports for Accessibility API mapping. Additional, middleware solutions can now make intelligent transformations of Web Content by processing the semantics behind rich browser and rich structured frameworks to adapt accessible solutions for a broader user base. Our immediate goal is to fix the accessibility problem with scripted Web content. Assistive technologies will use the standard roles to determine how to render most content.

2.3.1. Interoperability Example: Grid Role

To understand the power of this approach, consider the case of a Grid Role, analogous to a table. Figure 5.0 shows a DHTML example using XHTML, JavaScript, and CSS to produce a GUI-like application. This example developed in IBM shows a notebook tab with a data grid that behaves like a traditional desktop GUI. The user uses arrow keys to navigates the data grid and among the page tabs. Using the Tab key, a user navigates between the notebook tab, the edit fields, buttons, and the data grid.

DHTML example of GUI-like notebook tab with a data drid
Figure 5.0 DHTML Example

Accessible role and state meta data from the WAI-WAI-ARIA Roles, States, and Properties specification, are added as attributes to each of the XHTML elements repurposed as GUI widgets dynamically. The user agent, in this case Firefox, maps this information to the platform accessibility API. Figure 6.0 shows the Microsoft Active Accessibility rendering of the new accessibility markup provided on the DataGrid page tab which has focus.

MSAA Inspect Tool diagnostics for Notebook page tab
Figure 6.0 Microsoft Inspect Tool rendering of the page tab DataGrid

Figure 6.0 show a Microsoft Inspect 32 rendering of the DataGrid Page page tab in Figure 5.0. Inspect32 provides Microsoft Active Accessibility information; here it shows the accessible role of "page tab" and accessible state information of focused, focusable, and linked. There are no page tab elements in XHTML. Here, an XHTML DIV element is repurposed by a JavaScript controller to look like a notebook tab. It is now able to receive focus, unlike in standard XHTML 1.X, and it does so without requiring tabbing. With these specifications, the script author can now add the accessibility properties to support platform accessibility API. Accessible state properties for the DataGrid page tab are shown as focused, focusable, and linked. Unlike a GUI application, authors need only enable their applications once for multiple operating system platforms.

Beyond scripted Web content, the working group intends to extend the use of roles to enable other user cases. These may include:

  • Structured Textual Markup - enhancing structure of the markup of a document, including Data Tables , or translating the structure of an XML document to a markup structure that user agents are used to dealing with (e.g. myXML to XHTML) Binding sections of a document to a common role. This allows for different navigation techniques though a document
  • Knowledge representation of Web content - As a secondary benefit, roles improve compatibility with Knowledge-Based Services and the Semantic Web. By integrating accessibility and the semantic Web, accessibility can be moved forward, paving the way for customized accessible searches and intelligent user agents with additional applications.
  • Adding concepts in the type of content for adaptation to the user scenario - The more that is understood about content, the better it can be adapted for the end user. For example:
    1. If it is known that a page hyperlink has the role of taking the user to the site's home page, then that knowledge can be used to create enhanced accessibility in different ways in many different scenarios, such as icons or access keys.
    2. If it is known that a text box is for the user email address, then the user agent can support users filling in the form by labeling it with an icon or symbol, automatically validating it, or even form filling.
    3. If it is known that a paragraph is complex, then a simple equivalent can be shown in its place
    4. If a word is ambiguous, then a role of a concept can be given, providing clarity An example of this may be : <span role="role:nonliteral" aria:hasAlternate="no">

2.4. Accessibility Events and Event Handling

Interoperability between applications and assistive technologies requires event notification for accessibility. The events defined in Table 2.0 will be fired via the user agent. The accessible value and state property changes will be generated in response to changes in the DOM attributes as defined by the WCAG 1.0 AAA specification. User agents supporting the platform accessibility API, will support event notification such as the state change or value change events.

2.5. HTML 5 - A Look Ahead

HTML 5 and the "serialized" XHTML version of HTML 5 are years away from standardization. We have preliminary consensus to add the WAI-ARIA states and properties, role, and tabindex changes needed for WAI-ARIA in HTML 5 as demonstrated in section 5.1.4. This is subject to change between now and when the specification goes to recommendation. In HTML 5, we will see many more standard controls that developers may choose to use and that should be used in preference to WAI-ARIA features. We shall continue to promote WAI-ARIA's use and adoption in industry to ensure that there continues to be the ability to provide support accessibility of new types of controls. A number of gaps remain, such as named event handlers and enhancements for access key, that we need to address. This work is in progress.

3. Building Accessible Applications with WAI-ARIA

This section provides a brief introduction to the process of making applications accessible using WAI-ARIA. The choice and usage of roles can be complex and context dependent. It is beyond the scope of this document to explain implementations for all the possible WAI-ARIA use cases. WAI-ARIA Authoring Practices [ARIA-PRACTICES] provides detailed guidance on WAI-ARIA implementation methodology as well as references to sample code.

First steps to making an application accessible:

  1. Each element or widget has correct and complete semantics that fully describe its behavior (using element names or roles);
  2. The relationships between elements and groups are defined;
  3. States, properties, and container relationships are valid for each element's behavior and are accessible via the Document Object Model [DOM] and the platform accessibility API; and
  4. Keyboard focus should be maintained for the duration of the user's interaction with the application.
  5. All interactive components should be keyboard operable.

WAI-ARIA provides authors with the means to make the different elements in a web application semantically rich. User agents use the role semantics to understand how to handle each element. Roles convey additional information that the assistive technologies need to anticipate the behavior of the elements inside the application such as how to present the corresponding WAI-ARIA states and properties to the user. The user agent will use the accessibility semantics from the host language and WAI-ARIA accessibility semantics (which may augment or override those of the host language) and present them to assistive technologies through the Document Object Model or the platform accessibility API. The user agent will create an accessible representation of each element in the web page, and will use the appropriate accessibility API to notify assistive technologies of changes to the semantics of those elements.

The following steps are recommended when WAI-ARIA is applied to content:

  1. Use native markup when possible.

    Use the semantic elements that are defined in the host markup language. For example, with HTML or XHTML, it is better to use the native checkbox than to use a div element with role checkbox as these should already be accessible through your browser. There may also be cases where WAI-ARIA can augment an existing element in the host language. For example, a grid and gridcell elements can reuse the functionality of a table when overlaying it. WAI-ARIA roles, states, and properties are best used when the markup language does not support all the semantics required. When a role attribute is added to an element, the semantics and behavior of the element are augmented or overridden by the role behavior.

  2. Apply the appropriate roles.

    Set roles to make sure elements behave predictably and correctly describe the behavior of each element within the application, unless element behaviors are fully described by the native markup language. Roles for interactive elements should support all the attributes that the element could use. Once a role attribute is set it should not be changed as this may confuse the end user. This does not preclude an element being removed which has the role attribute set, but only states and properties (aria-* attributes) should be changed for a given element.

  3. Preserve semantic structure.

    Structural information is critical to providing context to persons with disabilities. Preserve DOM hierarchy within structural elements and widgets:

    • Form logical groups within user interface widgets, such as treeitem elements in a group.
    • Identify large perceivable regions and apply a landmark role to those areas. This will facilitate keyboard navigation. It will also facilitate content management by assistive technologies by providing semantics to manage how much information is rendered at a given time. The use of WAI-ARIA landmarks helps everyone, including vision-impaired users, dexterity-impaired users, and even users with cognitive or learning impairments.
    • For areas of the page that contain a group of elements that are likely to change through an Ajax application it may be specified as a live region, through the use of the aria-live attribute or it may be marked with pre-defined roles, such as log, which has assumed behavior of a live region.
  4. Build relationships.

    Look for relationships between elements, and mark them using the most appropriate property or attribute. For example, if a page contains both a search form and search results region, mark each container as a region and set the aria-controls attribute of the search form to reference the search results. See relationships in WAI-ARIA.

    Some relationships are determined automatically from the host language, like label elements associated with input elements in HTML.

  5. Set states and properties in response to events.

    Once the role for an element has been set, change states and properties as appropriate during the element's life cycle, usually in response to user input events. Only use attributes supported for the chosen role or element.

    User agents should notify assistive technologies of state changes. Conversely, assistive technologies' notification of property changes depends on the method by which assistive technologies communicate with the user agent. For example, the aria-multiline attribute (a property) is not something that changes frequently, whereas the aria-checked (state) attribute (a state) changes frequently in response to user input.

  6. Support full, usable keyboard navigation.

    Usable keyboard navigation in a rich internet application is different from the tabbing paradigm in a static document. Rich internet applications behave more like desktop applications where the user tabs to significant widgets and uses the arrow keys to navigate within a complex widget, such as a menu or spreadsheet. The changes that WAI-ARIA introduces in keyboard navigation make this enhanced accessibility possible. Tabbing in the document should follow a logical navigation structure. Authors implementing arrow key navigation should, where possible, follow the design patterns in the WAI-ARIA Authoring Practices Guide [ARIA-PRACTICES]. When using these features, it is important as always to ensure keyboard navigation is logical.

  7. Synchronize the visual interface with the accessible interface.

    This will allow the state of your UI to be perceivable to the user as well as assistive technologies. For example, the author should use the appropriate WAI-ARIA attribute on a form element that is visually styled to appear required (aria-required) or a gridcell that is visually styled to appear selected (aria-selected (state)). Authors may choose to achieve visual synchronization of these interface elements by using a script or by using CSS attribute selectors. Refer to the WAI-ARIA Authoring Practices [ARIA-PRACTICES] for techniques on proper UI synchronization with the accessible state of the document.

3.1. Example: Building a Tree Widget

Graphic of an example tree view.

A basic tree view allows the user to select different list items and expand and collapse embedded lists. Arrow keys are used to navigate through a tree, including left/right to collapse/expand sub trees. Clicking the visible expander button with the mouse also toggles expansion. Further keyboard implementation details for tree widgets may found in the [WAI-ARIA Authoring Practices Guide Design Patterns [ARIA-PRACTICES, section 9].

To make this feature accessible we need to:

Following the steps below:

  1. Look at the native markup language

    Although standard list behavior is supported by the native ul and li elements in HTML, there is no element that natively supports list expansion and selection. Since there is not, we will need to use roles.

  2. Finding the right roles

    Since there is no native tree element in HTML, we need to add roles from the taxonomy that support the additional states and properties needed. The roles that support tree behavior are:

    • tree: A tree is the main container element for our tree. It is a form of a select where sub-level groups of treeitems may be collapsed and expanded.
    • treeitem: A treeitem is an option item of a tree. This is an element within a tree; sub-level groups of treeitems may be expanded or collapsed.
    • group: A group encloses a set of sub-level treeitems.
  3. Look for groups and build relationships

    Tree relationships can be made simply via the DOM and logical structure of the page. A tree element will be the main container encompassing all other elements in the tree. Each selectable item in the tree will be a treeitem.

    When a treeitem contains an embedded list of treeitems they will be all be embedded in a group. A group should be contained inside the tree item that is the parent item.

    <h1 id="treelabel">WAI-ARIA Tree Example</h1>
    <ul role="tree" aria-labelledby="treelabel" aria-activedescendant="example_id" tabindex="0">
      <li role="treeitem" aria-expanded="true">Animals
        <ul role="group">
          <li role="treeitem">Birds</li>
          <li role="treeitem" aria-expanded="false">Cats
            <ul role="group">
              <li role="treeitem">Siamese</li>
              <li role="treeitem">Tabby</li>
          <li role="treeitem" aria-expanded="true">Dogs
            <ul role="group">
              <li role="treeitem" aria-expanded="true">Small Breeds
                <ul role="group">
                  <li role="treeitem">Chihuahua</li>
                  <li role="treeitem" id="example_id">Italian Greyhound</li>
                  <li role="treeitem">Japanese Chin</li>
              <li role="treeitem" aria-expanded="false">Medium Breeds
                <ul role="group">
                  <li role="treeitem">Beagle</li>
                  <li role="treeitem">Cocker Spaniel</li>
                  <li role="treeitem">Pit Bull</li>
              <li role="treeitem" aria-expanded="false">Large Breeds
                <ul role="group">
                  <li role="treeitem">Afghan</li>
                  <li role="treeitem">Great Dane</li>
                  <li role="treeitem">Mastiff</li>
      <li role="treeitem" aria-expanded="true">Minerals
        <ul role="group">
          <li role="treeitem">Zinc</li>
          <li role="treeitem" aria-expanded="false">Gold
            <ul role="group">
              <li role="treeitem">Yellow Gold</li>
              <li role="treeitem">White Gold</li>
          <li role="treeitem">Silver</li>
      <li role="treeitem" aria-expanded="true">Vegetables
        <ul role="group">
          <li role="treeitem">Carrot</li>
          <li role="treeitem">Tomato</li>
          <li role="treeitem">Lettuce</li>

    The use of aria-expanded should mirror that which is visibly expanded on screen, so authors may wish to use CSS attribute selectors to toggle visibility or style of an item based on the value of an WAI-ARIA state or property. The following example would hide the sub-level groups of a collapsed tree node.

    [aria-expanded="false"] [role="group"] { display: none; }

    Note: At the time of this writing, this CSS example, while technically correct, will not redraw styles properly in some browsers if the attribute's value is changed dynamically. It may be necessary to toggle a class name, or otherwise force the browser to redraw the styles properly.

    Sometimes a tree structure is not explicit via the DOM and logical structure of a page. In such cases the relationships must still be made explicit using the states and properties. In the following example, the aria-owns attribute indicates that the div with id "external_treeitem" should be considered a child of the ul element with the attribute, even though it is not a child in the DOM.

    <li role="treeitem" aria-expanded="true" aria-owns="external_group">Vegetables</li>
    <ul role="group" id="external_group">
      <li role="treeitem">Carrot</li>
      <li role="treeitem">Tomato</li>
      <li role="treeitem">Lettuce</li>

    Sometimes trees (and other lists or grids) cannot be completed represented in the DOM due to performance limitations of the browser. For example, an application interface may only need to display 100 items out of a set of 100,000. Including all 100,000 items in the DOM could cause performance problems on both the client and server machines.

    If items in a managed widget are loaded, for example, via the XMLHttpRequest object, and not present in the DOM at all times, authors should use aria-level, aria-posinset and aria-setsize, and ensure that aria-owns is not required to convey membership with the widget.

    <li role="treeitem" aria-level="1" aria-posinset="3" aria-expanded="true" aria-setsize="3">
      <ul role="group">
        <li role="treeitem" aria-level="2" aria-posinset="6" aria-setsize="8">Carrot</li>
        <li role="treeitem" aria-level="2" aria-posinset="7" aria-setsize="8">Tomato</li>
        <li role="treeitem" aria-level="2" aria-posinset="8" aria-setsize="8">Lettuce</li>
  4. Use states and properties in response to events

    Control the behavior of the element in response to user input events such as from the keyboard and the mouse, which includes maintaining the current states and properties for that element. For example, a tree control will need to respond to click events on the expand/collapse triggers, and key events on the currently active descendant. Use device-independent events with supporting JavaScript to handle user interaction. For detailed examples of this please refer to the Design Patterns section of the WAI-ARIA Authoring Practices [ARIA-PRACTICES].

4. Reasons for Adopting WAI-ARIA

By adopting WAI-ARIA, both developers of static web sites and of dynamic Internet applications can improve the usability, accessibility, and scalability of their products. Developers of static web content can continue to follow the 1999 WCAG 1.0 standards, while improving usability and accessibility through the use of WAI-ARIA landmark roles, aria-labelledby relationships, and properties like aria-invalid (state) and aria-required that can apply to HTML form controls. In richer, dynamic content, developers create custom widgets like calendars and spreadsheets based on technologies such as Ajax and CSS; to achieve accessibility, they need to use WCAG 2.0. Previously, when delivering rich Internet applications to users, to comply with WCAG 1.0, developers resorted to providing alternative, static content. While such measures met the WCAG 1.0 requirements, people using assistive technologies were not provided the richer user experience. When tables are used for layout, rather than CSS absolute positioning, historically, they have been problematic for assistive technologies to interpret. When the WAI-ARIA role of presentation is used on such tables, the assistive technology ignores the table structure, providing a more accessible experience without requiring major recoding.

4.1. Technical Benefits

Consider a rich Internet application where developers attempt to achieve keyboard accessibility using markup language. Without WAI-ARIA, results may be keyboard accessible but not highly usable; consider a user having to press Tab thirty times to put focus on a checkbox. To achieve keyboard accessibility in HTML without WAI-ARIA, developers must code active elements either as a link or as a form element. Accordingly, this means that no additional semantics are required or provided, other than that provided by the host language. In addition, WCAG 1.0 requires that content be renderable with Cascading Style Sheets turned off in the browser. This approach creates the following general usability problems:

WAI-ARIA and WCAG 2.0 coding techniques are useful for developing content and applications that can scale across a variety of user agents, including those on mobile devices.

For all these reasons, adopting WAI-ARIA makes good technical as well as business sense. For a further illustration, compare how accessibility is achieved with WCAG techniques without and with WAI-ARIA, as shown in Figure 7.0.

Editor's Note: Figure 7, described as WAI-ARIA tree widget usability comparision, refers to a resource that has not yet been found.

Figure 7.0 Usability of Tree Widget Using WAI-ARIA Semantics to Implement WCAG 2.0 Guidelines Compared to WCAG 1.0 Without WAI-ARIA

Figure 7.0 shows an "accessible" widget for a tree item, within a tree widget, using WCAG 1.0 without WAI-ARIA, which ,when supplied to a screen reader, may say "link folder Year." There is no information to indicate that the folder is closed (aria-expanded (state) = "false"). There is no information to indicate its depth (aria-level="2"), position in the set and the set size at the level, all of which provides the user with context something sighted users may take for granted. The role is used to indicate that it is a treeitem which indicates that the item should behave and navigate with the keyboard like a tree item. A screen reader using the WAI-ARIA version might say "Closed Folder Year, Closed Folder one of two, Depth two, unchecked." Furthermore, the WAI-ARIA version can allow the tree items to be navigated with arrow keys and without requiring they be navigated as part of a global web page tabbing scheme. This is not what any user would expect of a tree widget. Finally, if you were told all widgets were links on the web page, consider how usable -- or not -- that would be.

4.2. Business Benefits

If, as described above, coding techniques to achieve accessibility compliance do not promote overall usability, then business strategists must ask "Why invest in accessibility?" With WAI-ARIA, businesses can invest in accessible development and reap benefits for all users, not just those with disabilities or using assistive technologies. Some benefits include:

5. Conclusions

This primer is designed to address the accessibility of dynamic, scripted, Web content that may be rendered in today's browsers while bridging to future declarative standards, such as XHTML2, in the W3C. The extensions being created for XHTML 1.X are intended to be cross-cutting. This primer clearly indicates that the Web Content Accessibility Guidelines (WCAG) [WCAG20], the Authoring Tool Accessibility Guidelines (ATAG) [ATAG2], and the User Agent Accessibility Guidelines (UAAG) [UAAG] should be in lock step for a common strategy. The web, tool, and user agent groups are effected and are interdependent. Additionally, close work with mainstream working groups, like HTML, CSS, and Device Independence will not only produce a working solution but it will produce a working solution that will have a broader impact than just XHTML. Moreover, this convergence stands to benefit users and businesses in significant measure.

6. Appendices

6.1. Gap Analysis - Filling the Gaps for (X)HTML in Support of Accessibility API

Table 2.0 GAP Analysis - Progressive Filling of the Gaps for (X)HTML in support of Accessibility API
Required ComponentsWho does what today? (X)HTML Technique to fill the gaps for HTML 4.01, and XHTML 1.X
FocusChangeDOM 2 UI Events ([EVENTS], Section 1.6.1) DOM 2 UI Events ([EVENTS], Section 1.6.1)
ActivationDOM Level 2 Device Independent UI Events ([EVENTS], Section 1.6.1, UIEvent)  
Caret ChangeUser Agent API User Agent API
* Value Change User Agent to monitor valuenow, valuemax, and valuemin states in the WAI-ARIA Roles, States, and Properties for (X)HTML. For properties representing platform accessibility API values as specified by a given role, it will generate an accessible value change event. (See State Change Event below).
* State Change 

User Agent to monitor specific accessibility states and properties in the WAI-ARIA Roles, States, and Properties for (X)HTML. For states and properties representing platform accessibility API states or properties specified by a given role, it will generate an accessible state or property change event. (See State Change Event below).

Selection ChangeUser Agent APIUser Agent API
MutationDOM EventsDOM Events mapping
Accessible Actions:  
* Event Handler functional information and descriptive shortcuts  
* Access to the available event handlers for enumerating the actionsDOM 3 Events 
* State Information: States and properties form WAI-ARIA Roles, States, and Properties specification
* Role Information:Limited to standard HTML tag names. (Mix Content/presentation)

Roles and their corresponding values as defined by the WAI-ARIA Roles, States and properties specification

Relationships: Parent/childLimited DOM (affected by style) (Mix Content/presentation) 
Relationships: (Label, MemberOf - Group, ControllerFor)Limited to HTML (Title, alt, label) 
Text:Core DOM 1 from parsed HTML 
Content selection:User Agent 
Font/Font Style Information:Can set but can't get final formatUser Agents final format styling using CSS2 APIs or platform accessibility APIs
* Description/Help:limited to HTML 4.0 - Alt Text, title textThe describedby property as defined in the WAI-ARIA Roles, States, and Properties specification WAI-ARIA]
* Accessible value:limited to form elementsThe valuenow, valuemax, and valuemin properties as defined in the WAI-ARIA Roles, States, and Properties specification WAI-ARIA]
Coordinates (Bounding rectangle, etc.):User Agents. platform accessibility API 
Accessible Name:User Agent determines from HTML tag 
* Respond Desktop Font/Color Changespartial (conflicts with CSS and JavaScript) 
* Device independent navigation:Use of XHTML landmarks through the <link rel""> 
*Accessibility API Mapping:partial - User Agents 
Provide focus to all active elementsTABINDEX=-1 best practice 

Table 2.0 shows the roadmap for filling the gaps in Table 1.0 for (X)HTML. The effort is designed to fill the gaps for HTML content using the W3C technique to embed role and state attributes into HTML documents. Required components marked with an asterisk indicate gaps to fill in the roadmap.

6.2. Long Descriptions of Figures

For graphics that need longer descriptions, see the following items.

6.2.1. Long Description of Figure 1.0 Accessibility Interoperability at a DOM Node without JavaScript

Figure 1.0 shows how a document element is extended by an accessibility contract that filters communication between Assistive Technology (AT) and the Document Element (Controller). In a Model-View-Controller scenario, the:

  • Model provides the Data for the DOM Node.
  • View is the user interface for a standard user agent.
  • Controller is the Document Element semantics

Through the Contract with the AT:

  • Input is received form the Document Element controller and passed to the AT through the contract filter.
  • Input is received from the user and passed to the Document Element controller through the contract filter.

Attributes of the contract include:

  • Role
  • States
  • Actions
  • Caret
  • Selection
  • Text
  • Hyper Text
  • Value
  • Name
  • Description
  • Children
  • Changes
  • Relations

6.2.2. Long Description of Figure 2.0 Accessibility Interoperability at a DOM Node with JavaScript

Figure 2.0 shows that with JavaScript, the AT Contract described in Figure 1.0 is discarded. When JavaScript is used, JavaScript widgets replace the normal document element controller with a substitute controller defined by the JavaScript. With JavaScript the AT Contract is discarded. The Java script manipulates the document data (DOM), the document elements (content), the user interface (style). It is driven by external events and produces custom widgets. Key elements of the contract including role, states, action, value, changes and relations are not communicated with assistive technology (AT).

6.3. References

This section is informative.

Resources referenced informatively provide useful information relevant to this document, but do not comprise a part of its requirements.

Accessible Rich Internet Applications (WAI-ARIA) 1.0. J. Craig, M. Cooper, L. Pappas, R. Schwerdtfeger, L. Seeman, Editors, W3C Working Draft (work in progress), 16 September 2010. This version of WAI-ARIA is available at http://www.w3.org/TR/2010/WD-wai-aria-20100916/. Latest version of WAI-ARIA available at http://www.w3.org/TR/wai-aria/.
WAI-ARIA Authoring Practices. J. Scheuhammer, M. Cooper, L. Pappas, R. Schwerdtfeger, Editors, W3C Working Draft (work in progress), 16 September 2010. This version of WAI-ARIA 1.0 Authoring Practices is available at http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/. Latest version of WAI-ARIA Authoring Practices available at http://www.w3.org/TR/wai-aria-practices/.
Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap), R. Schwerdtfeger, Editor, W3C Working Draft (work in progress), 4 February 2008. This version of WAI-ARIA Roadmap is available at http://www.w3.org/TR/2008/WD-wai-aria-roadmap-20080204/. Latest version of WAI-ARIA Roadmap available at http://www.w3.org/TR/wai-aria-roadmap/.
Authoring Tool Accessibility Guidelines 2.0, J. Richards, J. Spellman, J. Treviranus, M. May, Editors, W3C Working Draft (work in progress), 8 July 2010, http://www.w3.org/TR/2010/WD-ATAG20-20100708/. Latest version of ATAG 2.0 available at http://www.w3.org/TR/ATAG20/.
Gnome Accessibility Toolkit. Available at http://library.gnome.org/devel/atk/unstable/.
The Mac OS X Accessibility Protocol. Available at: http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Accessibility/cocoaAXIntro/cocoaAXintro.html.
Document Object Model (DOM) Level 2 Core Specification, L. Wood, G. Nicol, A. Le Hors, J. Robie, S. Byrne, P. Le Hégaret, M. Champion, Editors, W3C Recommendation, 13 November 2000, http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/. Latest version of DOM Core available at http://www.w3.org/TR/DOM-Level-2-Core/.
Document Object Model (DOM) Level 2 Events Specification, T. Pixley, Editor, W3C Recommendation, 13 November 2000, http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/. Latest version of DOM Events available at http://www.w3.org/TR/DOM-Level-2-Events/.
Java Accessibility API (JAPI). Available at http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140174.html.
Microsoft Active Accessibility (MSAA). Available at http://msdn.microsoft.com/en-us/library/ms697707.aspx.
OWL Web Ontology Language Overview, D. L. McGuinness, F. van Harmelen, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-features-20040210/. Latest version of OWL Overview available at http://www.w3.org/TR/owl-features/.
Resource Description Framework (RDF): Concepts and Abstract Syntax, G. Klyne, J. J. Carroll, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/. Latest version of RDF Concepts available at http://www.w3.org/TR/rdf-concepts/.
Role Attribute, S. McCarron, Editor, W3C Working Draft (work in progress), 5 August 2010, http://www.w3.org/TR/2010/WD-role-attribute-20100916/. Latest version of Role Attribute available at http://www.w3.org/TR/role-attribute/.
User Agent Accessibility Guidelines 1.0, I. Jacobs, J. Gunderson, E. Hansen, Editors, W3C Recommendation, 17 December 2002, http://www.w3.org/TR/2002/REC-UAAG10-20021217/. Latest version available at http://www.w3.org/TR/UAAG10/.
Microsoft Accessibility Model (UI Automation). Available at http://msdn.microsoft.com/en-ca/windows/bb735024.aspx.
Web Content Accessibility Guidelines 1.0, W. Chisholm, G. Vanderheiden, I. Jacobs, Editors, W3C Recommendation, 5 May 1999, http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/. Latest version of WCAG 1.0 available at http://www.w3.org/TR/WAI-WEBCONTENT/.
Web Content Accessibility Guidelines 2.0, B. Caldwell, G. Vanderheiden, L. Guarino Reid, M. Cooper, Editors, W3C Working Draft (work in progress), 11 December 2007, http://www.w3.org/TR/2007/WD-WCAG20-20071211/. Latest version of WCAG 2.0 available at http://www.w3.org/TR/WCAG20/.

6.4. Acknowledgments

The following people contributed to the development of this document.

6.4.1. Participants in the PFWG at the time of publication

  1. David Bolter (Invited Expert, University of Toronto Adaptive Technology Resource Centre)
  2. Sally Cain (Royal National Institute of Blind People)
  3. Ben Caldwell (Invited Expert, Trace)
  4. Charles Chen (Google, Inc.)
  5. Michael Cooper (W3C/MIT)
  6. James Craig (Apple, Inc.)
  7. Dimitar Denev (Frauenhofer Gesellschaft)
  8. Steve Faulkner (Invited Expert, The Paciello Group)
  9. Kentarou Fukuda (IBM Corporation)
  10. Andres Gonzalez (Adobe Systems Inc.)
  11. Georgios Grigoriadis (SAP AG)
  12. Jon Gunderson (Invited Expert, UIUC)
  13. Markus Gylling (DAISY Consortium)
  14. Sean Hayes (Microsoft Corporation)
  15. John Hrvatin (Microsoft Corporation)
  16. Kenny Johar (Vision Australia)
  17. Masahiko Kaneko (Microsoft Corporation)
  18. Matthew King (IBM Corporation)
  19. Diego La Monica (International Webmasters Association / HTML Writers Guild (IWA-HWG))
  20. Gez Lemon (International Webmasters Association / HTML Writers Guild (IWA-HWG))
  21. Thomas Logan (HiSoftware Inc.)
  22. William Loughborough (Invited Expert)
  23. Anders Markussen (Opera Software)
  24. Matthew May (Adobe Systems Inc.)
  25. Shane McCarron (Invited Expert, Aptest)
  26. Charles McCathieNevile (Opera Software)
  27. James Nurthen (Oracle Corporation)
  28. Joshue O'Connor (Invited Expert)
  29. Artur Ortega (Yahoo!, Inc.)
  30. Simon Pieters (Opera Software)
  31. T.V. Raman (Google, Inc.)
  32. Gregory Rosmaita (Invited Expert)
  33. Tony Ross (Microsoft Corporation)
  34. Janina Sajka (Invited Expert, The Linux Foundation)
  35. Martin Schaus (SAP AG)
  36. Joseph Scheuhammer (Invited Expert, Inclusive Design Research Centre, OCAD University)
  37. Stefan Schnabel (SAP AG)
  38. Richard Schwerdtfeger (IBM Corporation)
  39. Lisa Seeman (Invited Expert, Aqueous)
  40. Cynthia Shelly (Microsoft Corporation)
  41. Andi Snow-Weaver (IBM Corporation)
  42. Henny Swan (Opera Software)
  43. Gregg Vanderheiden (Invited Expert, Trace)
  44. Léonie Watson (Invited Expert, Nomensa)
  45. Gottfried Zimmermann (Invited Expert, Access Technologies Group)

6.4.2. Other previously active PFWG participants and other contributors to the Accessible Rich Internet Applications specification

Special thanks to Aaron Leventhal for effort and insight as he implemented a working prototype of accessibility API bindings. Special thanks to Al Gilman for his work while chair of the PFWG in bringing the ARIA technology to fruition.

Jim Allan (TSB), Simon Bates, Chris Blouch (AOL), Judy Brewer (W3C/MIT), Christian Cohrs, Donald Evans (AOL), Geoff Freed (WGBH/NCAM), Becky Gibson (IBM), Alfred S. Gilman, Andres Gonzalez (Adobe), Jeff Grimes (Oracle), Barbara Hartel, Earl Johnson (Sun), Jael Kurz, Aaron Leventhal (IBM Corporation), Alex Li (SAP), Linda Mao (Microsoft), Shane McCarron (ApTest), Lisa Pappas (Society for Technical Communication (STC)), Dave Pawson (RNIB), David Poehlman, Marc Silbey (Microsoft Corporation), Henri Sivonen (Mozilla), Vitaly Sourikov, Mike Squillace (IBM), Ryan Williams (Oracle), Tom Wlodkowski.

6.4.3. Enabling funders

This publication has been funded in part with Federal funds from the U.S. Department of Education, National Institute on Disability and Rehabilitation Research (NIDRR) under contract number ED05CO0039. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.