[contents]

W3C

WAI-ARIA Roadmap 1.0

W3C plans for addressing rich Internet application accessibility gaps

Editors' Draft 15 December 2009

This version:
http://www.w3.org/WAI/PF/aria-roadmap/
Latest public version:
http://www.w3.org/TR/wai-aria-roadmap/
Editors:
Richard Schwerdtfeger, IBM

Abstract

The Roadmap for Accessible Rich Internet Applications addresses the accessibility of dynamic Web content for people with disabilities. The roadmap introduces the technologies to map controls, Ajax live regions, and events to accessibility APIs, including custom controls used for Rich Internet Applications. The roadmap also describes new navigation techniques to mark common Web structures 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 an internal Editor's Draft of the Protocols and Formats Working Group. It is not stable and may change at any time. Implementors should not use this for anything other than experimental implementations. This document is available to W3C Members and should not be distributed to anyone who does not have W3C Member access.

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
  2. 2. The Problem
  3. 3. Executive Summary
  4. 4. The Roadmap for filling the Gaps in Desktop Browsers
    1. 4.1. Roadmap Deliverable Timeline
    2. 4.2. Implementations
  5. 5. The Roadmap for Middleware - A look ahead at filling the Gaps in Emerging Declarative Application Middleware
    1. 5.1. External Deliverable Timeline
  6. 6. References
    1. 6.1. Informative References
  7. 7. Acknowledgments
    1. 7.1. Participants in the PFWG at the time of publication
    2. 7.2. Other previously active PFWG participants and other contributors to the Accessible Rich Internet Applications specification
    3. 7.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 does not provide adequate markup to support 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 are underway to address this problem using a declarative markup approach. This roadmap is designed to create a bridge to fix the interoperability problem with assistive technologies now by incorporating the appropriate meta data in current XHTML markup to support today's accessibility API. It will incorporate some of the advanced accessibility features, originally designed, in technologies like XHTML2. The intent of XHTML 2 is to make the enablement of Web applications and documents easier for authors. This roadmap will create cross-cutting technologies that XHTML authors may incorporate in their markup to describe GUI widgets and document structures to aide assistive technology vendors in providing accessible, usable solutions. The W3C WAI PF working group will work with User Agent manufacturers and assistive technology vendors to ensure a working solution.

2. The Problem

Aspects of traditional HTML make accessible support of dynamic content difficult:

  1. Accessibility relies on abstracting semantics from both content and presentation information. Extracting semantic cues from current HTML content is typically unreliable. Today, semantics are limited to tag elements names.
  2. HTML allows content to be repurposed for presentation formatting without providing a way to convey semantic information. A common example of this is tables used to format content rather than style sheets.
  3. When combined with script and CSS, HTML can be repurposed to create dynamic custom components without providing a means to convey semantic information to native accessibility architectures designed to support dynamic GUI content.
  4. HTML lacks the ability to attach meaningful metadata about document structure.
  5. HTML elements commonly used for repurposing produce custom components that 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 tag elements such as DIVs in which they dynamically apply a 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 it can write to such that a solution could be mapped to the accessibility frameworks on the native platform by the user agent.

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

Figure 1.0 illustrates a typical DOM node in a Model-View-Controller architecture. On the node, data, or the "Model," which should include semantic information, is separated from the user interface presentation, the "View." Here, the document element is managed by the user agent based on the default behavior of the element. The user agent's default behavior at the document element forms the controller. Placed between the DOM node and the assistive technology is a box containing the contract provided by the user agent to the assistive technology. This data includes typical accessibility information found in the accessibility API for many of our 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.

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.

3. Executive Summary

What is clear from the problem statement is that the author does not have the ability to 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 SVG. The WAI Protocols and Formats working group will address the problem at the middleware application layer and web content delivered to desktop browsers. For desktop browsers, we shall be creating common extensions to both HTML and XHTML called the Roles, States, and Properties Module for Accessible Rich Internet Applications 1.0. The goal will to make these standard features in HTML 5.

The W3C is also working on XHTML middleware solutions with a strong focus on declarative markup. Middleware developers prefer to operate on well-formed markup due to a common dependency to merge document fragments. A growing focus on W3C standards work is to use declarative markup which reduces the need for JavaScript. New work being done on XForms and XHTML 2 targets incorporation accessibility features through the declarative markup of the language. This has the added benefit of reducing the enablement burden on middleware authors by leveraging existing accessibility information stored in the markup. Ultimately, middleware, will need to convert the content to traditional markup supported by today's browsers.

4. The Roadmap for filling the Gaps in Desktop Browsers

At this time, the primary effort in the W3C WAI Protocols and Formats working group is to focus on an extension to XHTML and HTML with a migration path to HTML 5. Key deliverables will be the WAI-ARIA Roles, States, and Properties specification which includes a adapted version of the new role attribute from the XHTML Role Attribute Module [XHTML-ROLES] for which a set of accessible role values may be applied from the WAI-ARIA Roles specification in addition to its own standard role document landmarks to assist document navigation and restructuring. For a detailed understanding of how the WAI-ARIA Roles, States and Properties specification and how it is is used to fill the interoperability gaps in HTML and XHTML please refer to the W3C WAI-ARIA Primer.

4.1. Roadmap Deliverable Timeline

Editors Note: This timeline is under revision.

The following table is the anticipated delivery timeline for portions of the WAI-ARIA suite and possible related documents. This is not a prescriptive timeline, but is provided to track the relevant technologies.

Timeline for the Dynamic Accessible Web Content Roadmap
Specification.WD 1.0WD 2.0

WD 3.0

LCCRTest SuitesImplementation ReportPRREC
Accessible Rich Internet Applications (WAI-ARIA) Version 1.0 [ARIA]Q3 2006
Q4 2006
Q2 2007

Q3 2007

Q4 2007Q4 2007Q3 2007Q1 2008Q2 2007
XHTML Role Attribute Module [XHTML-ROLES]Q3 2006  Q3 2007  Q3 2007 
Q4 2007
Q1 2008
Extensible WAI-ARIATBD        
(X)HTML 5 support for WAI-ARIATBD        

4.2. Implementations

The following table provides implementations of the new accessibility specifications for supporting dynamic accessible Web content.

Implementations of Accessibility Specifications for WAI-ARIA Content
ImplementationCategory of Implementation
Firefox 2.0 (including MSAA support) user agent
GW Micro Window-Eyes 5.5 - with Firefox support assistive technology (screen reader)
JAWS 7.0 with Firefox support(partial) assistive technology (screen reader)
Windows Magnifier (with IE or Firefox 1.5) assistive technology (magnifier)
FireVox assistive technology (screen reader)
Internet Explorer from DOM APIuser agent
Opera 
Mozilla Firefox Test samples content
Dojo JavaScript Toolkitcontent - in Development
iCITA Firefox Accessibility Extension: Testing Toolaccessibility test tool
iCITA WAI-ARIA Example Widgetscontent
Mozilla Firefox WAI-ARIA to Accessibility API mappingUser Agent Accessibility API mapping
Bindows Object Oriented Platform for Ajax Developmentcontent - in Development
AccProbe (Part of Eclipse Accessibility Tools Framework Project) Test ToolTool - in Development
WAI Role Taxonomy Extension ToolTool - in Development

5. The Roadmap for Middleware - A look ahead at filling the Gaps in Emerging Declarative Application Middleware

Up to now , the roadmap has addressed current (X)HTML markup as supported by today's desktop browsers using WAI-ARIA. The markup in today's browsers, like accessibility, requires developers to do things manually through the use of JavaScript. While this is extremely flexible, it suffers from a number of problems:

Through the use of declarative markup and tight integration of accessibility into the application framework, we can produce more consistent cross-platform solutions which support accessibility and reduce the enablement efforts of the author. At this time there are four new standards forming new application middleware which incorporate key accessibility features needed for accessibility.

  1. XML Events [XML Events] allows the author to provide a purpose to event handlers allowing people with disabilities the ability to know what will happen if the action is performed, such as making a purchase.
  2. XForms [XForms] is a new forms specification that allows for semantic meta data to be stored directly in the form. For example, the WAI-ARIA required attribute was derived from the XForms data model property. By using the standard XForms data model, many accessibility properties, found in WAI-ARIA, can easily be extracted simply by following the XForms data model. XForms also provides for device independent events, declarative event handlers covering many of the use cases found in JavaScript from which accessibility information about actions that can be performed may be automatically derived. XForms also provides support for labeling elements, hints, and help information for form elements which may be provided to platform accessibility API.
  3. XHTML Access Module [XHTML-ACCESS] defines an element that, when used in conjunction with other XHTML modules, enables a more robust accessibility replacement to the HTML access key. The XHTML Access module allows the author to: have the user agent assign keyboard mappings, define whether an element is to receive focus or be activated; passing a description for the access key; and access key navigation sequencing using roles.
  4. XHTML2 [XHTML2] is being designing to build accessibility in from the ground floor. XHTML 2 incorporates the role attribute, document landmarks, XForms, XML Events, and a number of other accessibility features. It introduces an access element designed to address device independence, semantic navigation, and activation. It also benefits from the WAI-ARIA Roles which is a cross-cutting technology. The XHTML 2 specification is still in working draft form. A future list of the extensive accessibility features of XHTML 2 will be necessary. XHTML 2 is evolving, over time, as an application middleware layer which can be used to generate (X)HTML content for a variety of mobile devices and user agents.

The W3C WAI PF working group will provide greater details in the future by creating a W3C WAI-ARIA Primer for Middleware Applications based on XHTML 2.

5.1. External Deliverable Timeline

Editors Note: This timeline is under revision.

The following table is the anticipated delivery timeline for documents related to the WAI-ARIA work.

Timeline for Technologies Related to WAI-ARIA
Specification.Timeline
XHTML2 Specification [XHTML2]See XHTML2 Working group roadmap
XHTML Access Module [XHTML-ACCESS]See XHTML2 Working group roadmap
XML Events [XML-EVENTS] with handler descriptions (not critical for XHTML)See XHTML2 Working group roadmap
XForms 1.0 [XFORMS] See XForms Schedule of Deliverables

6. References

This section is normative.

6.1. Informative References

Resources referenced informatively provide useful information relevant to ARIA, but do not comprise a part of the ARIA requirements.

[ARIA]
Accessible Rich Internet Applications (WAI-ARIA) Version 1.0. L. Seeman, M. Cooper, R. Schwerdtfeger, L. Pappas, Editors, W3C Working Draft (work in progress), 15 December 2009. This version of WAI-ARIA is available at http://www.w3.org/TR/2009/WD-wai-aria-20091215/. Latest version of WAI-ARIA available at http://www.w3.org/TR/wai-aria/.
[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/.
[XFORMS]
XForms 1.1, J. Boyer, Editor, W3C Recommendation, 20 October 2009, http://www.w3.org/TR/2009/REC-xforms-20091020/. Latest version of XForms available at http://www.w3.org/TR/xforms/.
[XHTML2]
XHTML™ 2.0, M. Birbeck, J. Axelsson, S. Pemberton, B. Epperson, S. McCarron, M. Ishikawa, A. Navarro, M. Dubinko, Editors, W3C Working Draft (work in progress), 26 July 2006, http://www.w3.org/TR/2006/WD-xhtml2-20060726/. Latest version of XHTML 2.0 available at http://www.w3.org/TR/xhtml2/.
[XHTML-ACCESS]
XHTML Access Module, M. Birbeck, S. McCarron, S. Pemberton, T. V. Raman, R. Schwerdtfeger, Editors, W3C Working Draft (work in progress), 26 May 2008, http://www.w3.org/TR/2008/WD-xhtml-access-20080526/. Latest version of XHTML Access Module available at http://www.w3.org/TR/xhtml-access/.
[XHTML-ROLES]
XHTML Role Attribute Module, M. Birbeck, S. McCarron, S. Pemberton, T. V. Raman, R. Schwerdtfeger, Editors, W3C Working Draft (work in progress), 7 April 2008, http://www.w3.org/TR/2008/WD-xhtml-role-20080407/. Latest version of XML Role Attribute Module available at http://www.w3.org/TR/xhtml-role/.
[XML-EVENTS]
XML Events 2, M. Birbeck, S. McCarron, Editors, W3C Working Draft (work in progress), 16 February 2007, http://www.w3.org/TR/2007/WD-xml-events-20070216/. Latest version of XML Events available at http://www.w3.org/TR/xml-events/.

7. Acknowledgments

The following people contributed to the development of this document.

7.1. Participants in the PFWG at the time of publication

  1. Jim Allan (Invited Expert, Texas School for the Blind)
  2. David Bolter (Invited Expert, University of Toronto Adaptive Technology Resource Centre)
  3. Sally Cain (Royal National Institute of Blind People)
  4. Ben Caldwell (Invited Expert, Trace)
  5. Charles Chen (Google, Inc.)
  6. Michael Cooper (W3C/MIT)
  7. James Craig (Apple, Inc.)
  8. Dimitar Denev (Frauenhofer Gesellschaft)
  9. Steve Faulkner (Invited Expert, The Paciello Group)
  10. Geoff Freed (WGBH National Center for Accessible Media)
  11. Kentarou Fukuda (IBM Corporation)
  12. Andres Gonzalez (Adobe Systems Inc.)
  13. Georgios Grigoriadis (SAP AG)
  14. Jon Gunderson (Invited Expert, UIUC)
  15. Sean Hayes (Microsoft Corporation)
  16. John Hrvatin (Microsoft Corporation)
  17. Kenny Johar (Vision Australia)
  18. Masahiko Kaneko (Microsoft 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. Charles McCathieNevile (Opera Software)
  26. James Nurthen (Oracle Corporation)
  27. Joshue O'Connor (Invited Expert)
  28. Simon Pieters (Opera Software)
  29. David Poehlman (Invited Expert)
  30. T.V. Raman (Google, Inc.)
  31. Gregory Rosmaita (Invited Expert)
  32. Tony Ross (Microsoft Corporation)
  33. Janina Sajka (Invited Expert, The Linux Foundation)
  34. Martin Schaus (SAP AG)
  35. Joseph Scheuhammer (Invited Expert, University of Toronto Adaptive Technology Resource Centre)
  36. Stefan Schnabel (SAP AG)
  37. Richard Schwerdtfeger (IBM Corporation)
  38. Lisa Seeman (Invited Expert, Aqueous)
  39. Cynthia Shelly (Microsoft Corporation)
  40. Andi Snow-Weaver (IBM Corporation)
  41. Henny Swan (Opera Software)
  42. Gregg Vanderheiden (Invited Expert, Trace)
  43. Gottfried Zimmermann (Invited Expert, Access Technologies Group)

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

Simon Bates, Chris Blouch (AOL), Judy Brewer (W3C/MIT), Christian Cohrs, Donald Evans (AOL), 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), Marc Silbey (Microsoft Corporation), Henri Sivonen (Mozilla), Vitaly Sourikov, Mike Squillace (IBM), Ryan Williams (Oracle), Tom Wlodkowski.

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