Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
The 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 ARIA Overview.
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.
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 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 ARIA, and the WAI-ARIA Best 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.
Aspects of traditional Hypertext Markup Language (HTML) make accessible support of dynamic content difficult:
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:
DIV
as a pop-up menu 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.
Any solution to facilitate the creation of accessible rich Internet applications (RIAs) must:
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.
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.
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 W3C 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 [WAI-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 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 ARIA.
Role attribute - The role attribute, borrowed from the, XHTML Role Attribute Module [XHTML-ROLES], 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. 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 XHTML Role Attribute Module [XHTML-ROLES] 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 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
ortreegrid
. 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 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.
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.
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], Apple Accessibility for COCOA [AAC], and the Gnome Accessibility Toolkit (ATK) [ATK], or UI Automation for Longhorn [UIAUTOMATION] (called content type in UI Automation). The W3C 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 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" "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>
WAI used RDF/OWL to model our taxonomy for 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.
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" http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > <body> <div role="menu" aria-haspopup="true"> File </div> </body> </html>
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.
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.
tabindex attribute | Focusable with mouse or JavaScript via element.focus() | Tab navigable |
---|---|---|
not present | Follows default behavior of element (yes for form controls, links, etc.) | Follows default behavior of element |
Negative, e.g. tabindex="-1" | Yes | No, author must focus it with element.focus() as a
result of arrow or other key press |
Zero, e.g. tabindex="0" | Yes | In tab order relative to element's position in document |
Positive, e.g. tabindex="33" | Yes | Tabindex 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" http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > <body> <div role="menu" aria-haspopup="true" tabindex=-1> File </div> </body> </html>
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 ARIA (including those specified by the XHTML Role attribute module) to be specified without a namespace prefix. Additionally, ARIA states and properties shall be represented as aria- followed by the concatenated ARIA state or property.
Example: Browser supported HTML technique for the tabindex example in section 5.1.3
<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>
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.
In addition to the common roles which will reside in ARIA Roles, both XHTML 2.0, and the XHTML Role attribute module ([XHTML-ROLES], 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"> <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:
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 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 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 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.
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.
Accessible role and state meta data from the 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.
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:
<span
role="role:nonliteral" aria:hasAlternate="no">
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.
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
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.
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 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.
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 ARIA, which ,when supplied to a screen reader, may say "link folder Year." There is no information to indicate that the folder is closed (
). There is no information to indicate its depth (aria-expanded
= "false"
), 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 ARIA version might say "Closed Folder Year, Closed Folder one of two, Depth two, unchecked." Furthermore, the 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.aria-level
="2"
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:
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) [WCAG], the Authoring Tool Accessibility Guidelines (ATAG) [ATAG], 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.
Required Components | Who does what today? (X)HTML | Technique to fill the gaps for HTML 4.01, and XHTML 1.X |
---|---|---|
Events: | ||
FocusChange | DOM 2 UI Events ([EVENTS], Section 1.6.1) | DOM 2 UI Events ([EVENTS], Section 1.6.1) |
Activation | DOM Level 2 Device Independent UI Events ([EVENTS], Section 1.6.1, UIEvent) | |
Caret Change | User 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 Change | User Agent API | User Agent API |
Mutation | DOM Events | DOM Events mapping |
Accessible Actions: | ||
* Event Handler functional information and descriptive shortcuts | ||
* Access to the available event handlers for enumerating the actions | DOM 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/child | Limited 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 format | User Agents final format styling using CSS2 APIs or platform accessibility APIs |
* Description/Help: | limited to HTML 4.0 - Alt Text, title text | The describedby property as defined in the WAI-ARIA Roles, States, and Properties specification WAI-ARIA] |
* Accessible value: | limited to form elements | The 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 Changes | partial (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 elements | TABINDEX=-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.
For graphics that need longer descriptions, see the following items.
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:
Through the Contract with the AT:
Attributes of the contract include:
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).
This section is informative.
This section is informative.
The following contributed to the development of this document.
Special thanks to Aaron Leventhal for effort and insight as he implemented a working prototype of accessibility API bindings.
Simon Bates, Judy Brewer (W3C/MIT), Christian Cohrs, Becky Gibson (IBM), Andres Gonzalez (Adobe), Jeff Grimes (Oracle), Barbara Hartel, Earl Johnson (Sun), Jael Kurz, Linda Mao (Microsoft), Shane McCarron (ApTest), Dave Pawson (RNIB), Henri Sivonen (Mozilla), Vitaly Sourikov, Mike Squillace (IBM), Ryan Williams (Oracle), Tom Wlodkowski.
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.