WAI-ARIA 1.0 Primer

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:

• 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.)

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.

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.

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.

Scaleable

The solution needs to be scalable; it must make simple things easy while making complex things possible.

Internationalizable

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.

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.

<?xml version="1.1" encoding="us-ascii"?>
<!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

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

<?xml version="1.1" encoding="us-ascii"?>
<!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN" 
    http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">



>
        <body>
            <div role="menu" aria-haspopup="true">
                File
        </div>         
    </body>
</html>

<?xml version="1.1" encoding="us-ascii"?>
   <!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN" 
    http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">



>
    <body>
        <div role="menu" aria-haspopup="true" tabindex=-1>
            File
        </div>
    </body>
</html>

<html lang="en">
  <head>
    <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>
                        

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.

<!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">
<head>    
  <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" />    
</head>    
<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>  
 </ul>

...

</body>

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.

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:

• Career Counseling Resources
• Resources by Audience
• Career Center Services
• Quick Links

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.

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.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

3.1. Example: Building a Tree Widget

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:

• Inform assistive technologies about the role of each element;
• Inform assistive technologies about the relationships between tree items;
• Give a clear keyboard focus that will not confuse users with disabilities; and
• Expose the changing states (expanded and collapsed) of the tree items.

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>
           </ul>
         </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>
               </ul>
             </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>
               </ul>
             </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>
               </ul>
             </li>
           </ul>
         </li>
       </ul>
     </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>
           </ul>
         </li>
         <li role="treeitem">Silver</li>
       </ul>
     </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>
       </ul>
     </li>
   </ul>

   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>
   </ul>
   ...

   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">
     Vegetables
     <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>
     </ul>
   <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.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:

• All keyboard-accessible controls must be either forms or anchors, forcing the user to tab through all focusable elements on the web page to navigate. If you need to navigate from the first link on the page to the last link on the page, that could be a very long trip and takes usability a step back.
• Without WAI-ARIA semantics, you cannot provide contextual information to the user.
• If you repurpose HTML elements you cannot provide the appropriate role and context information for the new widget. Lack of context is a serious usability problem. WAI-ARIA semantics results in providing contextual information to the user.
• CSS is used for absolute positioning. If you remove that capability, usability features of widgets like pop-up menus disappear. Imagine activating the file menu and the menu showing up at the bottom of the page.

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:

• Because WAI-ARIA is being developed through the PFWG with cooperation from browser and assistive technology vendors, accessibility and interoperability with those technologies will be easier to achieve, reducing or eliminating the need for per-browser and per-screenreader coding to achieve accessibility.
• In addition to people with disabilities, all users benefit from WAI-ARIA because it establishes a Web-standard for keyboard interaction, easing the learning curve for users moving among applications, sites, and browsers.
• Implementing WAI-ARIA can facilitate test automation. Test engines require semantic information about user interface elements, unique names, exposure of state, specific properties in order to run automated test scripts. WAI-ARIA provides that semantic information needed for efficient test automation.

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

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.

• Long Description of Figure 1.0
• Long Description of Figure 2.0

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.

[ARIA]

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/.

[ARIA-PRACTICES]

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/.

[ARIA-ROADMAP]

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/.

[ATAG2]

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/.

[ATK]

Gnome Accessibility Toolkit. Available at http://library.gnome.org/devel/atk/unstable/.

[AXAPI]

The Mac OS X Accessibility Protocol. Available at: http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Accessibility/cocoaAXIntro/cocoaAXintro.html.

[DOM]

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/.

[DOM-EVENTS]

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/.

[JAPI]

Java Accessibility API (JAPI). Available at http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140174.html.

[MSAA]

Microsoft Active Accessibility (MSAA). Available at http://msdn.microsoft.com/en-us/library/ms697707.aspx.

[OWL]

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/.

[RDF]

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]

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/.

[UAAG]

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/.

[UIAUTOMATION]

Microsoft Accessibility Model (UI Automation). Available at http://msdn.microsoft.com/en-ca/windows/bb735024.aspx.

[WCAG1]

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/.

[WCAG20]

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.