Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap) /* Styles from old version */ caption { padding-top: 1em; font-weight: bold; font-size: 115%; } div.body img { padding: 1em; } div.body p.figure { text-align: center; font-weight: bold; } ol.tocline { margin: 0; padding: 0; list-style: none; padding-left: 1.25em; } code { FONT-FAMILY: monospace } div.constraint { MARGIN-LEFT: 2em } div.issue { MARGIN-LEFT: 2em } div.note { MARGIN-LEFT: 2em } div.notice { MARGIN-LEFT: 2em } dt { margin-bottom: 0; padding-bottom: 0; margin-top: .5em; } dd { margin-top: 0; padding-top: 0; } li p { MARGIN-TOP: 0.3em; MARGIN-BOTTOM: 0.3em } td, th { vertical-align: top; } div.exampleInner pre { MARGIN-TOP: 0em; MARGIN-BOTTOM: 0em; MARGIN-LEFT: 1em } div.exampleOuter { BORDER-RIGHT: gray 4px double; PADDING-RIGHT: 0em; BORDER-TOP: gray 4px double; PADDING-LEFT: 0em; PADDING-BOTTOM: 0em; MARGIN: 0em; BORDER-LEFT: gray 4px double; PADDING-TOP: 0em; BORDER-BOTTOM: gray 4px double } div.exampleInner { PADDING-RIGHT: 4px; BORDER-TOP: #d3d3d3 4px double; PADDING-LEFT: 4px; PADDING-BOTTOM: 4px; MARGIN: 0em; PADDING-TOP: 4px; BORDER-BOTTOM: #d3d3d3 4px double; BACKGROUND-COLOR: #d5dee3 } div.exampleWrapper { MARGIN: 4px } div.exampleHeader { FONT-WEIGHT: bold; MARGIN: 4px } .xmlverb-default { COLOR: #333333; FONT-FAMILY: monospace; BACKGROUND-COLOR: #ffffff } .xmlverb-element-name { COLOR: #990000 } .xmlverb-element-nsprefix { COLOR: #666600 } .xmlverb-attr-name { COLOR: #660000 } .xmlverb-attr-content { FONT-WEIGHT: bold; COLOR: #000099 } .xmlverb-ns-name { COLOR: #666600 } .xmlverb-ns-uri { COLOR: #330099 } .xmlverb-text { FONT-WEIGHT: bold; COLOR: #000000 } .xmlverb-comment { COLOR: #006600; FONT-STYLE: italic } .xmlverb-pi-name { COLOR: #006600; FONT-STYLE: italic } .xmlverb-pi-content { COLOR: #006666; FONT-STYLE: italic } div.exampleInner1 { PADDING-RIGHT: 4px; BORDER-TOP: #d3d3d3 4px double; PADDING-LEFT: 4px; PADDING-BOTTOM: 4px; MARGIN: 0em; PADDING-TOP: 4px; BORDER-BOTTOM: #d3d3d3 4px double; BACKGROUND-COLOR: #d5dee3 } Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap) W3C Working Draft 4 February 2008 This version: http://www.w3.org/TR/2008/WD-wai-aria-roadmap-20080204/ Latest version: http://www.w3.org/TR/wai-aria-roadmap/ Previous version: http://www.w3.org/TR/2007/WD-aria-roadmap-20071019/ Editors: Richard Schwerdtfeger, IBM < [email protected] Copyright W3C ® MIT ERCIM Keio liability trademark document use 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 This document is a Working Draft by the Protocols & Formats Working Group Web Accessibility Initiative WAI-ARIA Primer ARIA-PRIMER PFWG Charter The PFWG seeks feedback on the requirements, gap analysis, and plan set out in this document. In particular, the Working Group would like input about whether: The direction outlined in this plan captures what works to access GUI applications outside the Web; The plan paves a path to higher and better integration of interactive Web content, or distracts from technical progress. Please provide comments to assist the group in improving this document. Comments on this document may be sent to [email protected] Archive To assist you in your review, refer to the history of changes to WAI-ARIA Roadmap 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 public list of any patent disclosures Essential Claim(s) section 6 of the W3C Patent Policy The disclosure obligations of the Participants of this group are described in the charter 1 Introduction 2 The Problem 3 Executive Summary 4 The Roadmap for filling the Gaps in Desktop Browsers 4.1 Roadmap Deliverable Timeline 4.2 Implementations 5 The Roadmap for Middleware - A look ahead at filling the Gaps in Emerging Declarative Application Middleware 5.1 External Deliverable Timeline 6 References 7 Acknowledgments 7.1 Participants active in the PFWG at the time of publication 7.2 Other previously active PFWG participants and other contributors to the Accessible Rich Internet Applications specification 7.3 Enabling funders 1 According to the SecuritySpace Technology Penetration Report Unfortunately, HTML and other markup does not provide adequate markup to support accessible dynamic content. Until now, the W3C WAI Web Content Accessibility Guidelines (WCAG) 1.0 WCAG1 W3C WAI PF 2 Aspects of traditional HTML make accessible support of dynamic content difficult: Accessibility relies on abstracting semantics from both content and presentation information. Extracting semantic cues from current HTML content is typically unreliable. Today, semantics are limited to tag elements names. HTML allows content to be repurposed for presentation formatting without providing a way to convey semantic information. A common example of this is tables used to format content rather than style sheets. When combined with script and CSS, HTML can be repurposed to create dynamic custom components without providing a means to convey semantic information to native accessibility architectures designed to support dynamic GUI content. HTML lacks the ability to attach meaningful metadata about document structure. HTML elements commonly used for repurposing produce custom components that are not keyboard accessible. 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: 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 it can write to such that a solution could be mapped to the accessibility frameworks on the native platform by the user agent. Figure 1.0 DOM Figure 2.0 3 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 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 ARIA 4.1 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.0 WD 2.0 WD 3.0 LC CR Test Suites Implementation Report PR REC Accessible Rich Internet Applications (WAI-ARIA) Version 1.0 ARIA Q3 2006 Q4 2006 Q2 2007 Q3 2007 Q4 2007 Q4 2007 Q3 2007 Q1 2008 Q2 2007 XHTML Role Attribute Module XHTML-ROLES Q3 2006 Q3 2007 Q3 2007 Q4 2007 Q1 2008 Extensible WAI-ARIA TBD (X)HTML 5 support for WAI-ARIA TBD 4.2 The following table provides implementations of the new accessibility specifications for supporting dynamic accessible Web content. Implementations of Accessibility Specifications for ARIA Content Implementation Category 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 API user agent Opera Mozilla Firefox Test samples content Dojo JavaScript Toolkit content - in Development iCITA Firefox Accessibility Extension: Testing Tool accessibility test tool iCITA ARIA Example Widgets content Mozilla Firefox ARIA to Accessibility API mapping User Agent Accessibility API mapping Bindows Object Oriented Platform for Ajax Development content - in Development AccProbe (Part of Eclipse Accessibility Tools Framework Project) Test Tool Tool - in Development WAI Role Taxonomy Extension Tool Tool - in Development 5 Up to now , the roadmap has addressed current (X)HTML markup as supported by today's desktop browsers using 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: Although improvements have occurred, JavaScript does not behave the same on all browsers and platforms. Data models are inconsistent. Accessibility is bolted on, rather than being built in. Accessibility solutions remain more device-dependent than they should be. Heavy accessibility lifting is done by the author in line with the way JavaScript is used. 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. XML Events XML Events XForms XForms XHTML Access Module XHTML-ACCESS XHTML2 [XHTML2] ARIA 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 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 See XHTML2 Working group roadmap XForms 1.0 XFORMS See XForms Schedule of Deliverables 6 Accessible Rich Internet Applications (WAI-ARIA) Version 1.0 WAI ARIA Latest version of WAI ARIA WAI-ARIA Primer Latest version of WAI-ARIA Primer Web Content Accessibility Guidelines 1.0 Latest version of WCAG 1.0 XForms 1.0 (Third Edition) Latest version of XForms XHTML™ 2.0 Latest version of XHTML 2.0 XHTML Access Module Latest version of XHTML Access Module XHTML Role Attribute Module Latest version of XML Role Attribute Module XML Events 2 Latest version of XML Events 7 This section is informative The following contributed to the development of this document. 7.1 Chris Blouch (AOL) Charles Chen (Google) Michael Cooper (W3C/MIT) Dimitar Denev (FIT) Donald Evans (AOL) Kentarou Fukuda (IBM) Alfred S. Gilman (W3C Invited Expert) Jon Gunderson (UIUC) Kenny Johar (Vision Australia) Diego La Monica (IWA/HWG) Aaron Leventhal (IBM) Thomas Logan (Invited Expert, BayFirst Solutions) Matt May (Adobe) Charles McCathieNevile (Opera) Lisa Pappas (Invited Expert, SAS) Dave Pawson (RNIB) David Poehlman (Invited Expert, State of MD) Gregory Rosmaita (Invited Expert, The Linux Foundation) Janina Sajka (Invited Expert, The Linux Foundation) Stefan Schnabel (SAP) Richard Schwerdtfeger (IBM) Lisa Seeman (UB Access) Marc Silbey (Microsoft) Mike Squillace (IBM) Gottfried Zimmermann (Access Technologies Group) 7.2 Special thanks to Aaron Leventhal for effort and insight as he implemented a working prototype of accessibility API Jim Allan (TSBVI), Simon Bates, Judy Brewer (W3C/MIT), Christian Cohrs, Becky Gibson (IBM), Andres Gonzalez (Adobe), Georgios Grigoriadis (SAP AG), Jeff Grimes (Oracle), Barbara Hartel, Sean Hayes (Microsoft), John Hrvatin (Microsoft), Earl Johnson (Sun), Masahiko Kaneko (Microsoft), Jael Kurz, Alex Li (SAP AG), William Loughborough, Linda Mao (Microsoft), Anders Markussen (Opera), Dave Pawson (RNIB), T.V. Raman (Google), Vitaly Sourikov, Ryan Williams (Oracle), Tom Wlodkowski. 7.3 This publication has been funded in part with Federal funds from the U.S. Department of Education 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.