[contents]

W3C

WAI-ARIA 1.0 User Agent Implementation Guide 1.0

A user agent developer's guide to understanding and implementing Accessible Rich Internet Applications

Editor's Draft 19 October 2009

This version:
http://www.w3.org/WAI/PF/aria-implementation/
Latest public version:
http://www.w3.org/TR/wai-aria-implementation/
Editors:
Andi Snow-Weaver, IBM
Michael Cooper, W3C
Previous Editors:
Aaron Leventhal (until January 2009 while at IBM)

Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

This document describes how user agents should support keyboard navigation and respond to roles, states, and properties provided in Web content via WAI-ARIA [ARIA]. These features are used by authors creating accessible rich internet applications. Users often access the content using assistive technologies that rely on platform accessibility APIs to obtain and interact with information from the page. The WAI-ARIA User Agent Implementation Guide defines how implementations should expose content to accessibility APIs, helping to ensure that this information appears in a manner consistent with author intent. 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 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.

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 anything other than work in progress.

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

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

Table of Contents

  1. 1. Introduction
    1. 1.1. Accessibility APIs
    2. 1.2. Accessible tree vs. DOM tree - what's the relation?
    3. 1.3. Document conventions
  2. 2. Supporting Keyboard Navigation
    1. 2.1. Controlling focus with tabindex
    2. 2.2. Controlling focus with aria-activedescendent
    3. 2.3. Handling focus changes from the Assistive Technology
  3. 3. Mapping WAI-ARIA to Accessibility APIs
    1. 3.1. General rules for exposing WAI-ARIA semantics
    2. 3.2. Conflicts between native markup semantics and WAI-ARIA
    3. 3.3. Exposing attributes that don't directly map to accessibility API properties
    4. 3.4. Role mapping
    5. 3.5. State and Property Mapping
    6. 3.6. Special Processing Requiring Additional Computation
      1. 3.6.1. Name and Description
      2. 3.6.2. Widget Values
      3. 3.6.3. Relations
      4. 3.6.4. Group Position
    7. 3.7. Actions
    8. 3.8. Events
      1. 3.8.1. Action Events
      2. 3.8.2. State and Property Change Events
      3. 3.8.3. Changes to document content or node visibility
      4. 3.8.4. Selection
      5. 3.8.5. Menus in MSAA/IAccessible2/UIA
  4. 4. Special Document Handling Procedures
    1. 4.1. Documents, Handling frame and iframe elements
    2. 4.2. CSS Selectors
  5. 5. Error Handling
    1. 5.1.
    2. 5.2. Value type: IDREF and IDREFS
    3. 5.3. Value type: decimal
    4. 5.4. Value type: integer
    5. 5.5. UA Validation
    6. 5.6. Roles
    7. 5.7. States and Properties
    8. 5.8. Propagating errors to ATs
  6. 6. Appendices
    1. 6.1. Glossary
    2. 6.2. References
    3. 6.3. Acknowledgments
      1. 6.3.1. Participants in the PFWG at the time of publication
      2. 6.3.2. Other previously active PFWG participants and other contributors to the Accessible Rich Internet Applications specification
      3. 6.3.3. Enabling funders

1. Introduction

In traditional desktop graphical user interface (GUI) applications , elements of the user interface (UI) are displayed when needed and hidden when not needed based on user interactions. Accessibility application programming interfaces (APIs) are used to communicate semantic information about the user interface to assistive technology software used by people with disabilities. These APIs constitute a contract between applications and assistive technologies, such as screen readers, to enable them to access the appropriate semantics needed to produce a usable alternative to interactive applications. For example, screen reading software for blind users can determine whether a particular UI element is a menu, button, text field, list box, etc.

In traditional static Web pages, the HTML elements provided the necessary semantic information. Assistive technologies obtain the information from the Document Object Model (DOM) which does not change until a new page is loaded based on a user action. But JavaScript and CSS have enabled Web pages to behave more and more like interactive desktop GUI applications without the need to reload the page with each user interaction. Developers repurpose HTML elements into UI elements. For example, styles can be applied to a <div> element based on user interactions to make it look and behave like a popup menu. The <div> element, however, has no semantics so the screen reader doesn't understand that it is a menu.

WAI-ARIA enables rich Internet applications to have the same accessibility features as desktop GUI applications by adding metadata to markup technologies such as (X)HTML. Authors include WAI-ARIA in their markup and user agents translate the WAI-ARIA markup to the platform accessibility APIs.

The WAI-ARIA User Agent Implementation Guide is intended to provide readers with an understanding of how to implement WAI-ARIA in user agents. As explained in the WAI-ARIA Primer [ARIA-PRIMER], accessibility deficiencies in traditional markup render rich Internet applications unusable by people who use assistive technologies (AT) or who rely on keyboard navigation. The W3C Web Accessibility Initiative's (WAI) Protocols and Formats working group (PFWG) has addressed these deficiencies through several W3C standards efforts, with a focus on the WAI-ARIA specifications.

The WAI-ARIA User Agent Implementation Guide is part of a set of resources that support the WAI-ARIA specification. For an introduction to WAI-ARIA, see the Accessible Rich Internet Applications Suite (WAI-ARIA) Overview. The WAI-ARIA Primer [ARIA-PRIMER] provides a basic introduction to the concepts behind and reason for WAI-ARIA. The WAI-ARIA Best Practices Guide [ARIA-PRACTICES] describes recommended usage patterns for Web content developers. The User Agent Implementation Guide describes how WAI-ARIA roles, states, and properties should be supported in user agents using platform accessibility APIs. 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.

With the conceptual basis provided in the WAI-ARIA Primer [ARIA-PRIMER], you should have a good understanding of how WAI-ARIA provides for interoperability with assistive technologies and support for a more usable, accessible experience. This guide begins by providing a general overview of accessibility APIs and the accessible object hierarchy known as the accessible tree. The following sections give guidance on supporting keyboard navigation and mapping WAI-ARIA roles, states, and properties to accessibility APIs. Other sections give guidance on calculating text equivalents, mapping actions to events, event processing, special document handling procedures, and error handling.

This guide assumes that a user agent already exposes static content to ATs via the accessibility API on a given platform. Most of the additional work to enable WAI-ARIA can be divided into three parts:

  1. Making focus and tab navigation work on elements that previously were not focusable
  2. Mapping the WAI-ARIA roles and properties into the roles, states and other property getters in the accessibility API
  3. Computing text equivalents and managing states and events

In general, WAI-ARIA properties should only affect how content is mapped to platform accessibility APIs. They should not affect the visual rendering of content or the behavior of mainstream desktop browsers, except when style sheets are deliberately keyed off of WAI-ARIA attributes as recommended in the specification. This allows one of the primary principles of WAI-ARIA to be upheld—that content still renders and behaves the same for the majority of users in legacy browsers which do not support WAI-ARIA.

1.1. Accessibility APIs

The Document Object Model (DOM) is used to represent the structure and state of the elements in the document being rendered by the user agent. The elements of the document are organized into a hierarchy of nodes known as the DOM tree. Developers use APIs to manipulate the objects in the DOM tree enabling the concept of rich Internet applications.

For traditional Web pages, assistive technologies, such as screen readers, interact with user agents using the DOM. In order to make a Web application behave like a desktop application, the user agent needs to map accessibility information from the elements in the DOM tree to the Accessibility APIs of the underlying operating system or software platform. The screen reader or other assistive technology uses the semantic information exposed via the accessibility API to provide an altenative rendering of an application that is meaningful to a user. Originally, screen readers used heuristic techniques to determine the meaning of the user interface and built an alternative off screen model of the user interface. For example, a row of labels displayed horizontally near the top of an application window might be a menu. Labels with a border drawn around them might be buttons. Heuristic techniques are not always accurate, however, and require assistive technologies to be updated whenever the software application is updated.

A much better technique is for the software application to provide the necessary information for interoperability with assistive technology. To meet this need, platform owners have developed specialized interfaces, called accessibility APIs, which can be used to communicate accessibility information to assistive technologies. When developers use WAI-ARIA to provide the semantic role, state, and property information for elements in a rich Internet Application (RIA), the user agent must then map the information to the appropriate accessibility API for the platform.

Accessibility APIs covered by this document are:

If User Agent developers need to expose to other accessibility APIs, it is recommended that they work closely with assistive technology developers.

1.2. Accessible tree vs. DOM tree - what's the relation?

The accessible tree and the DOM tree are parallel structures. Roughly speaking the accessible tree is a subset of the DOM tree. It includes the user interface objects of the user agent and the objects of the document. Accessible objects are created in the accessible tree for every DOM element that should be exposed to an assistive technology, either because it may fire an accessible event or because it has a property, relationship or feature which needs to be exposed. Generally if something can be trimmed out it will be, for reasons of performance and simplicity. For example, a <span> with just a style change and no semantics may not get its own accessible object, but the style change will be exposed by other means.

1.3. Document conventions

Note: in the following sections,

2. Supporting Keyboard Navigation

Enabling keyboard navigation in web applications is a necessary step toward making accessible web applications possible. Usable keyboard navigation in a rich Internet application is different from the tabbing paradigm among interactive elements such as links and form controls in a static document. Rich internet applications behave more like desktop applications where the user tabs to significant complex widgets and uses the arrow keys to navigate within a complex widget, such as a menu or spreadsheet. The changes that WAI-ARIA introduces in keyboard navigation make this enhanced accessibility possible. In WAI-ARIA, any element can be keyboard focusable.

There are two mechanisms that allow for keyboard operation of accessible script widgets: tabindex and aria-activedescendant. Most other aspects of WAI-ARIA widget development depend on keyboard navigation functioning properly.

Assistive technologies often need to set the focus. For example, voice input software, onscreen keyboards and screen readers supply their own structured navigation modes, providing additional commands for moving to elements in a page. Both the user agent and web pages need to handle this gracefully. Script container widgets cannot expect that focus changes occur only from the keyboard or a mouse click. They need to listen for focus or aria-activedescendant changes and update their state when that occurs.

2.1. Controlling focus with tabindex

User agents that support WAI-ARIA expand the usage of tabindex, focus, and blur to allow them on all HTML elements. Authors may add any element such as a div, span or img to the default tab order by setting tabindex="0". In addition, any item with tabindex equal to a negative integer can be focused via script or a mouse click, but isn't part of the default tab order. This is not supported in the HTML 4 specification but is expected to be in compliance with HTML 5..

The tabindex system provides one way to develop custom widgets which are keyboard accessible, from simple widgets like a slider to container widgets like a menubar, tree view or spreadsheet.

The user agent implementation must to do the following to enable tabindex on all elements:

  1. Where tabindex equals a negative integer, the user agent must allow the element to be focused, but must not include the element in the sequential tab order.
  2. Where tabindex="0", the user agent must allow the element to be focused and must include the element in the sequential tab order.
  3. Where tabindex is greater than zero, the user agent must allow the element to be focused, and must include the element in the sequential tab order according to the value of the tabindex attribute and before any elements with tabindex either omitted or with a value of zero. See Sequential focus navigation for details.
  4. Every HTMLElement must expose the element.tabIndex property.
  5. The focus and blur methods must be added to the HTMLElement interface (available to script for every type of element).
  6. Any element that can receive focus must fire focus and blur events.
  7. Canceling a keydown event must also cancel the keypress event, for purposes of compatibility with other browsers.
  8. All elements which are focusable must be exposed in the accessible tree, so that when they receive focus, there is an object for which to fire an accessibility event.
  9. Expose the FOCUSED and FOCUSABLE accessibility API states, and FOCUS accessibility API event for any element in the accessible tree as described in State and Property Mapping.
  10. When the user triggers an element that is only focusable because of its tabindex attribute in a manner other than clicking it, such as by pressing Enter, and the element has no defined activation behavior, the user agent must fire a click event.
  11. When the user triggers an element with a defined activation behavior in a manner other than clicking it, such as by pressing Enter, the user agent must simulate a click on the element. The steps to simulate a click include:
    1. running pre-click activation steps
    2. firing a click event
    3. running post-click activation steps
    If the event is cancelled, the user agent must run cancelled activation steps on the element instead.

2.2. Controlling focus with aria-activedescendent

Editorial note: In current implementations as described below, user agents keep the desktop focus on the container but communicate focus events and states to the AT as if the active descendant has focus.

Alternatively, the actual desktop focus could move to the active descendant. This would be a less complex scenario for user agents to implement and would be a better scenario for users who have customized the appearance of their desktop keyboard focus. There is some concern that if the desktop focus is placed on the active descendant, some keyboard events might get dropped.

The User Agent Implementation task force seeks feedback from reviewers on this issue.

The aria-activedescendant property could also be used to enable keyboard accessibility on any type of WAI-ARIA element. It is often a more convenient way of creating container widget keyboard navigation (where the entire widget is in the tab order just once, but the user can use keystrokes to navigate to descendant items of the container).

Typically, the author will use tabindex="0" on the container element and aria-activedescendant to point to the ID of the currently active descendant. The author, not the user agent, is responsible for styling the currently active descendant to show it has keyboard focus (not via :focus since actual focus is on the container).

The user agent must do the following to implement aria-activedescendant:

  1. Implement the tabindex recommendations in Controlling focus with tabindex. Support for tabindex="0" on all elements is still necessary for authors to use the aria-activedescendant system, because the container widget must be in the tab order.
  2. For an element that has focus in the DOM, but also has aria-activedescendant which points to a valid ID, the user agent must not mark it as focused in the accessibility API.
  3. When the aria-activedescendant attribute changes on an element that currently has DOM focus, the user agent must fire an accessibility API FOCUS event on the new active descendant. If aria-activedescendant is cleared or doesn't point to an element in the current document, the user agent must fire a focus event for the container object that had the attribute change.
  4. For any element with an ID attribute, where the element is a descendant of an element with the aria-activedescendant attribute, the user agent must apply the following states to the target to ensure the object is accessible:
    1. FOCUSABLE, if the element also has a WAI-ARIA role—because the aria-activedescendant of the container can potentially point to it. It is not absolutely necessary to check this when there is no role, because real HTML elements that would be focused would already be focusable.
    2. ACTIVE, whenever the container element sets aria-activedescendant to match the ID of this descendant
    3. FOCUSED, if ACTIVE and the container widget with aria-activedescendant has true DOM focus
  5. If the AT sets focus to a descendant of a container with aria-activedescendant, the user agent must change the value of aria-activedescendant to point to that item.

2.3. Handling focus changes from the Assistive Technology

Alternative input software needs to be able to set focus to items that are focusable. Screen readers, voice input software and on-screen keyboards may set focus based on user commands implemented in that software. The following table describes the API used to set focus.

MSAAATKMAC Accessibility
accSelect(SELFLAG_TAKEFOCUS)AtkComponent::grab_focus 

3. Mapping WAI-ARIA to Accessibility APIs

3.1. General rules for exposing WAI-ARIA semantics

Where possible, WAI-ARIA semantics must be exposed through the standard mechanisms of the desktop accessibility API. For example, for WAI-ARIA widgets, compare how the widget is exposed in a similar desktop widget. In general most WAI-ARIA widget capabilities are exposed through the role, value, Boolean states and relations of the accessibility API.

In addition to what would normally be exposed in the accessible tree, user agents must expose elements that meet any of the following criteria:

Objects should be removed from the accessible tree when they are not exposed via the Accessibility API. When objects are removed from the accessible tree, the descendant objects should also be removed when they are not part of the end user interaction, such as graphics presenting the percentage complete of a progressbar. On the other hand, descendants should not be removed from the accessible tree when the elements do not take direct focus but are part of an end user interaction widget, such as the thumb and side buttons of a slider. Objects should be removed from the accessible tree as follows:

User agents must notify assistive technology of state changes. Conversely, assistive technology notification of property changes depends on the method by which an assistive technology communicates with the user agent. For example, the aria-multiline property is not something that changes frequently, whereas the aria-checked state changes frequently in response to user input.

3.2. Conflicts between native markup semantics and WAI-ARIA

WAI-ARIA It is generally used on elements that have no native semantics of their own with respect to user interface objects. At times, however, it is used on elements that have similar but not identical semantics to the intended object (for instance, nested list elements might be used to represent a tree structure). This is usually done as part of a fallback strategy, or because native presentation of the repurposed element reduces the amount of style and script the author must use. In these cases, the user agent MUST use the WAI-ARIA semantics to define how it exposes the element to accessibility APIs, not the native semantics.

When WAI-ARIA states and properties correspond to host language features that have the same implicit WAI-ARIA semantic, it can be particularly problematic to use the WAI-ARIA feature. If the WAI-ARIA feature and the host language feature are both provided but their values are not kept in sync, it is uncertain which one is correct. Therefore, user agents must ignore WAI-ARIA states and properties when a host language feature with the same implicit WAI-ARIA semantic is provided on the same object.

Although host languages can also have features that have implict WAI-ARIA semantics corresponding to roles, the above rule does not apply to roles. When a WAI-ARIA role is provided, user agents must use the semantic of the WAI-ARIA role for processing, not the native semantic. This is because values for roles do not conflict in the same way as values for states and properties, and because authors are expected to have good reason to provide a WAI-ARIA role even on elements that would not normally be repurposed.

3.3. Exposing attributes that don't directly map to accessibility API properties

Platform accessibility APIs may have features that are not in WAI-ARIA. Likewise, WAI-ARIA exposes new capabilities so there typically is not a one to one relationship between all WAI-ARIA attributes and platform accessibility APIs. When WAI-ARIA roles, states and properties don't directly map to an accessibility API, and there is a way in the API to expose a text string, user agents must expose the raw WAI-ARIA data as a text string. User agents may also expose the raw WAI-ARIA information through this API even when there is a direct mapping to an accessibility API.

IAccessible2 and ATK use object attributes to expose semantics that are not directly supported in the APIs. Object attributes are name-value pairs that are loosely specified, and very flexible for exposing things that an accessibility API does not have a specific interface for. For example, at this time, the aria-live attribute can be exposed via an object attribute because accessibility APIs have no such property available. Specific rules for exposing object attribute name-value pairs are described throughout this document, and rules for the general cases not covered are in State and Property Mapping.

For accessibility APIs that do not have "object attributes" per se, it is useful to find a similar mechanism or develop a new interface to expose name/value pairs. Under the Mac OS X Accessibility Protocol, all getters are already simply name-value pairs and it is possible to expose new semantics whenever necessary. Keep in mind, this also requires working with the assistive technology developers to gain support for the new semantics.

3.4. Role mapping

Platform accessibility APIs traditionally have had a finite set of predefined roles that are expected by assistive technologies on that platform and only one or two roles may be exposed. In contrast, WAI-ARIA allows multiple roles to be specified as an ordered set of space-separated valid role tokens. The additional roles may be fallback roles similar to the concept of specifying multiple fonts in case the first choice font type is not supported.

WAI-ARIA includes some roles, such as landmarks and advanced widgets, that are not traditionally part of accessibility APIs. Because landmarks do not generally have mappings in platform accessibility APIs, they may occur anywhere within the role string without affecting how the first widget role is exposed. In addition, future versions of WAI-ARIA may allow for author-defined roles to be used in the role string. In that case, it is expected that a fallback role may be provided after the custom role, in the role string.

The user agent must expose roles so that the standard role mechanism of the accessibility API provides the best-fit widget role, yet the entire role string is also available for parsing:

  1. The first role token with a known mapping to accessibility APIs must be used for the standard role mechanism of the accessibility API. Use the role mapping table below and apply any special case rules that are specified.
  2. Roles defined in the WAI-ARIA spec as "abstract" must not be mapped via the standard role mechanism of the accessibility API. The abstract roles are:
  3. If no mapping to a standard role in the platform accessibility API is found, the algorithm used to map to a platform accessibility API role must act as if no role attribute is present. In other words, the UA will fall back on normal processing of the base markup for the element with the role attribute. For example, for <table role="log"> use the tag name "table" to determine what platform accessibility API role to use. For <input type="text" role="search">, use the platform accessibility API for a text input.
  4. The entire role string should be exposed as a text string. This allows assistive technologies to do their own additional processing of roles.

Note: Changes to the role attribute are considered an error in the WAI-ARIA specification, and are discussed in Error Handling.

Table describing mapping of WAI-ARIA roles to accessibility APIs.
WAI-ARIA roleMSAA roleIAccessible2 role (if different from MSAA)UI Automation Control TypeATK roleMAC Accessibility Role
alertROLE_SYSTEM_ALERT TextATK_ROLE_ALERTAXGroup, AXRoleDescription: "alert"
alertdialogROLE_SYSTEM_ALERT WindowATK_ROLE_ALERTAXGroup, AXRoleDescription: "alert dialog"
applicationROLE_SYSTEM_APPLICATION PaneATK_ROLE_EMBEDDEDAXGroup, AXRoleDescription: "application"
articleROLE_SYSTEM_DOCUMENT + readonly  ATK_ROLE_DOCUMENT_FRAME + readonlyAXGroup, AXRoleDescription: "article"
banner    AXGroup, AXRoleDescription: "banner"
buttonROLE_SYSTEM_PUSHBUTTON. If a "button" has the state aria-haspopup="true" it should be exposed as a ROLE_SYSTEM_BUTTONMENUIf a "button" and aria-pressed is not undefined, it should be exposed in IA2 as IA2_ROLE_TOGGLE_BUTTONButtonATK_ROLE_PUSH_BUTTONAXButton
checkboxROLE_SYSTEM_CHECKBUTTON + object attribute checkable="true" CheckboxATK_ROLE_CHECK_BOX + object attribute checkable="true"AXCheckBox
columnheaderROLE_SYSTEM_COLUMNHEADER DataItemATK_ROLE_COLUMN_HEADERAXCell
comboboxROLE_SYSTEM_COMBOBOX + STATE_SYSTEM_HASPOPUP. If aria-expanded!= "true", expose STATE_SYSTEM_COLLAPSED ComboboxATK_ROLE_COMBO_BOX + ATK_STATE_EXPANDABLE + object attribute haspopup="true"AXComboBox???
complementary    AXGroup, AXRoleDescription: "complementary"
contentinfo    AXGroup, AXRoleDescription: "content"
definition     
dialogROLE_SYSTEM_DIALOG WindowATK_ROLE_DIALOGAXGroup, AXRoleDescription: ="dialog"
directoryROLE_SYSTEM_LIST List AXList???
documentROLE_SYSTEM_DOCUMENT DocumentATK_ROLE_DOCUMENT_FRAMEAXGroup, AXRoleDescription: "document"
gridROLE_SYSTEM_TABLEUse AccessibleTable interfaceDataGridATK_ROLE_TABLEAXTable???
gridcellROLE_SYSTEM_CELL DataItemATK_ROLE_TABLE_CELLAXCell
groupROLE_SYSTEM_GROUPING GroupATK_ROLE_PANELAXGroup
headingROLE_SYSTEM_TEXT or use xml-rolesIA2_ROLE_HEADINGTextATK_ROLE_HEADINGAXHeading
imgROLE_SYSTEM_GRAPHIC ImageATK_ROLE_IMAGEAXImage
linkROLE_SYSTEM_LINK. Also, apply special rule to expose STATE_LINKED to link and all its descendants. HyperLinkATK_ROLE_LINKAXLink
listROLE_SYSTEM_LIST + STATE_SYSTEM_READONLY ListATK_ROLE_LISTAXList???
listboxROLE_SYSTEM_LIST ListATK_ROLE_LIST. Special case: if a "listbox" has a parent or is owned by (via aria-owns) a "combobox", it should be exposed with ATK_ROLE_MENU.AXList
listitemROLE_SYSTEM_LISTITEM + STATE_SYSTEM_READONLY ListItemATK_ROLE_LISTITEMAXGroup
logROLE_SYSTEM_PANE Pane AXGroup, AXRoleDescription: "log"
main    AXGroup, AXRoleDescription: "main"
marqueeROLE_SYSTEM_ANIMATION or use xml-roles TextATK_ROLE_PANELAXGroup, AXRoleDescription: "marquee"
mathROLE_SYSTEM_EQUATION  ATK_ROLE_UNKNOWNAXGroup, AXRoleDescription: "math"
menuROLE_SYSTEM_MENUPOPUP MenuATK_ROLE_MENU. These objects should not be exposed for a submenu if there is a parent menu item spawning the submenu.AXMenu
menubarROLE_SYSTEM_MENUBAR MenuBarATK_ROLE_MENU_BARAXMenuBar
menuitemROLE_SYSTEM_MENUITEM MenuItemATK_ROLE_MENU_ITEM
  • If aria-checked is not undefined, support object attribute "checkable"="true"

If the option's parent has a group role, then role="menuitem" maps to NSAccessibilityMenuButtonRole

If the option's parent has a menu role, then role="menuitem" maps to NSAccessibilityMenuItemRole

AXMenuItem????

menuitemcheckboxROLE_SYSTEM_CHECKBUTTON or ROLE_SYSTEM_MENUITEM + object attribute checkable=trueIA2_ROLE_CHECK_MENU_ITEM + object attribute checkable="true"CheckboxATK_ROLE_CHECK_MENU_ITEM + object attribute checkable="true"AXMenuItemRole
menuitemradioROLE_SYSTEM_RADIOBUTTON or ROLE_SYSTEM_MENUITEM + object attribute checkable=trueIA2_ROLE_RADIO_MENU_ITEM + object attribute checkable="true"RadioButtonATK_ROLE_RADIO_MENU_ITEM + object attribute checkable="true"AXMenuItemRole
navigation    AXGroup, AXRoleDescription: "navigation"
note    AXGroup, AXRoleDescription: "note"
optionROLE_SYSTEM_LISTITEM + if aria-checked is not undefined, support object attribute "checkable"="true" ListItemATK_ROLE_LIST_ITEM
  • If aria-checked is not undefined, support object attribute "checkable"="true"
  • Special case: if an "option" has a parent that was exposed as an ATK_ROLE_MENU, the "option" should be exposed as an ATK_ROLE_MENU_ITEM

If the option's parent has a menu role, then role="option" maps to NSAccessibilityMenuItemRole

If the option's parent has a listbox role, then role="option" maps to NSAccessibilityStaticTextRole

AXStaticText???

presentationROLE_SYSTEM_PANE. Do not expose this object unless it is focusable PaneDo not expose this object unless it is focusableAXGroup, AXRoleDescription: "presentation"
progressbarROLE_SYSTEM_PROGRESSBAR + READONLY ProgressBarATK_ROLE_PROGRESS_BAR + READONLYAXProgressIndicator
radioROLE_SYSTEM_RADIOBUTTON RadioButtonATK_ROLE_RADIO_BUTTONAXRadioButton
radiogroupROLE_SYSTEM_GROUPING GroupATK_ROLE_PANELAXRadioGroup
regionROLE_SYSTEM_PANE PaneATK_ROLE_PANELAXGroup, AXRoleDescription: "region"
rowROLE_SYSTEM_ROW unless inside a "tree" or "treegrid", in which case ROLE_SYSTEM_OUTLINEITEM DataItemATK_ROLE_LIST_ITEMAXRow
rowheaderROLE_SYSTEM_ROWHEADER DataItemATK_ROLE_ROW_HEADERAXCell
search    AXGroup, AXRoleDescription: "search"
separatorROLE_SYSTEM_SEPARATOR SeparatorATK_ROLE_SEPARATORAXSplitter
sliderROLE_SYSTEM_SLIDER SliderATK_ROLE_SLIDERAXSlider
spinbuttonROLE_SYSTEM_SPINBUTTON SpinnerATK_ROLE_SPIN_BUTTONAXProgressIndicator
statusROLE_SYSTEM_STATUSBAR StatusBarATK_ROLE_STATUSBARAXGroup, AXRoleDescription: "status"
tabROLE_SYSTEM_PAGETAB. Expose SELECTED state if focus is inside tabpanel associated with aria-labelledby. TabItemATK_ROLE_PAGE_TAB. Expose SELECTED state if focus is inside tabpanel associated with aria-labelledby.AXRadioButton, AXRoleDescription: "tab"
tablistROLE_SYSTEM_PAGETABLIST TabATK_ROLE_PAGE_TAB_LISTAXTabGroup
tabpanelROLE_SYSTEM_PANE or ROLE_SYSTEM_PROPERTYPAGE PaneATK_ROLE_SCROLL_PANEAXTabGroup
textboxROLE_SYSTEM_TEXT + IA2_STATE_SINGLE_LINE if aria-multiline is not "true" DocumentATK_ROLE_ENTRY + ATK_STATE_SINGLE_LINE if aria-multiline is not "true"AXTextArea
timer    AXGroup, AXRoleDescription: "timer"
toolbarROLE_SYSTEM_TOOLBAR ToolBarATK_ROLE_TOOL_BARAXToolbar
tooltipROLE_SYSTEM_TOOLTIP ToolTipATK_ROLE_TOOL_TIPAXGroup, AXRoleDescription: "tooltip"
treeROLE_SYSTEM_OUTLINE TreeATK_ROLE_TREEAXOutline
treegridROLE_SYSTEM_OUTLINEUse AccessibleTable interfaceDataGridATK_ROLE_TREE_TABLEAXOutline
treeitemROLE_SYSTEM_OUTLINEITEM + if aria-checked is not undefined, support object attribute "checkable"="true" TreeItemATK_ROLE_LIST_ITEM + if aria-checked is not undefined, support object attribute "checkable"="true"AXRow, AXRoleDescription: "outline row"

UIA has AriaRole property which is directly corresponds to the ARIA attribute string when an element is exposed in the accessible tree. UIA AriaRole property can support secondary roles using space as a separator according to the W3C specification.

3.5. State and Property Mapping

This section describes how to expose states and object properties. Where possible, API standard states are used. When that is not possible, object attributes (or a similar mechanism) are required.

  1. Compute the managed states such as VISIBLE/INVISIBLE, SHOWING/OFFSCREEN, etc. This typically is done in the same way as for ordinary elements that do not have WAI-ARIA attributes present. The FOCUSABLE/FOCUSED states may be affected by aria-activedescendant. See the rules in Controlling focus with aria-activedescendant.
  2. Add in states and object attributes supported by the accessibility implementation for the base markup. Map states and properties that are supported in the API.
  3. User agents should add additional information to the description, object attribute, or other text string.
  4. Some roles require additional states to be exposed. Apply special case rules for the primary role as defined in the table in Role mapping.
  5. Compute states for the relevant WAI-ARIA properties. To determine the relevant WAI-ARIA properties, see the table below.
  6. For forward compatibility with new WAI-ARIA properties in future versions, user agents should expose all properties not in these tables with a text string, removing the "aria-" prefix from the name. For example, aria-foo="bar" would be exposed with a text string foo=bar, since aria-foo is not a currently known WAI-ARIA property.
  7. Compute states and properties which are not global only computed on elements with roles that support them.
WAI-ARIA state and property mapping rule table
WAI-ARIA State or PropertyMSAAIAccessible2 (if different from MSAA)UI AutomationATKMAC Accessibility
aria-activedescendant
  • Expose as described in aria-activedescendant, and set appropriately when the AT pushes focus changes in a container with this attribute not undefined as described in Handling focus changes from the AT.
  • In cases, however, the focus can be transparent in accessible tree as it may exposed as focus delegation from the container element to the child object that takes active focus. This is represented by an accessible object that comes with STATE_SYSTEM_FOCUSED state; When this happens standard focus event and event handling should apply.
 See MSAA processing. Use HasKeyboardFocus property. If AXFocused is true, post "NSAccessibilityFocusedUIElementChangedNotification" notification when aria-activedescendant value changes
aria-atomic="true"   
aria-atomic="false" (default)     
aria-autocomplete="inline", "list", or "both"
  • Expose the value in an object attribute called autocomplete and expose the SUPPORTS_AUTOCOMPLETION equivalent state
    
aria-autocomplete="none" (default)     
aria-busy="true" (state)
  • Clear the BUSY state
    
aria-busy="false" (state) (default)
  • Expose the BUSY state
    
aria-checked="true" (state)
  • Set the CHECKED state
  • Expose object attribute checkable="true"
 ToggleState in UIA Toggle Control Pattern represents the status. AXValue="1"
aria-checked="false" (state)
  • Clear the CHECKED state
  • Expose object attribute checkable="true"
 ToggleState in UIA Toggle Control Pattern represents the status. AXValue="0"
aria-checked=""mixed" (state)
  • Set the CHECKED state
  • Expose object attribute checkable="true"
 ToggleState in UIA Toggle Control Pattern represents the status.Expose ATK_STATE_INDETERMINATE/STATE_SYSTEM_MIXED, unless on a role of radio or menuitemradio (in those cases treat as "false")AXValue="0.5"
aria-checked is undefined (state)
  • The element does not support being checked
    
aria-controls Expose the relations as described in RelationsControllerFor property expose a reference to an accessible object corresponds to the ID specified by the aria-controls.Expose the relations as described in Relations 
aria-describedbyExpose via accDescriptionExpose the relations as described in Relations Expose the relations as described in RelationsSet AXDescription to text value of element found by property value
aria-disabled="true" (state)
  • Set STATE_SYSTEM_UNAVAILABLE
  • Expose SENSITIVE + ENABLED
  • Propagate to all FOCUSABLE descendants of the element
 Set IsEnabled to "true" Set AXEnabled to !aria-disabled
aria-disabled="false" (state) (default)Clear STATE_SYSTEM_UNAVAILABLE set IsEnabled to "true" Set AXEnabled to !aria-disabled
aria-dropeffect (state)
  • Expose as object attribute "dropeffect"
    
aria-dropeffect="none" (state) (default)
  • Expose as object attribute "dropeffect"
    
aria-expanded="true" (state)Set STATE_SYSTEM_EXPANDED ExpandCollapseState of ExpandCollapse Pattern represents the status Expose ATK_STATE_EXPANDABLE and ATK_STATE_EXPANDED
aria-expanded="false" (state)Set STATE_SYSTEM_COLLAPSED   Expose ATK_STATE_EXPANDABLE
aria-expanded is undefined (state) (default)
  • The object is neither expandable or collapsible.
    
aria-flowto Expose the relations as described in RelationsFlowsTo property expose a reference to an accessible object corresponds to the ID specified by the aria-flowto.Expose the relations as described in Relations 
aria-grabbed="true" or "false"To be defined    
aria-grabbed is undefined (default)To be defined    
aria-haspopup="true"Expose as STATE_SYSTEM_HASPOPUP. If on a push button, change the role to ROLE_SYSTEM_BUTTONMENU. Expose state of the pop-up activities in the ExpandCollapseState property in the ExpandCollapse Control Pattern.Expose as object attribute haspopup="true"expose AXShowMenu action
aria-haspopup="false" (default)
  • Clear the object attribute (both)
  • Clear the HASPOPUP state. If on a push button (HT, change the role to ROLE_SYSTEM_BUTTONMENU
    
aria-hidden="true" (state)

This is not used in mapping to platform accessibility APIs. Instead, use information from the layout system to determine if the element is hidden or not. Advisory: it is incorrect use of WAI-ARIA if an element with aria-hidden="true" is visible. The aria-hidden property is exposed only so that DOM-based assistive technologies can be informed of visibility changes. However, the layout will be able to provide the most complete set of all truly hidden nodes.

    
aria-hidden="false" (state) (default)

This is not used in mapping to platform accessibility APIs. Instead, use information from the layout system to determine if the element is hidden or not. Advisory: it is incorrect use of WAI-ARIA if an element with aria-hidden="true" is visible. The aria-hidden property is exposed only so that DOM-based assistive technologies can be informed of visibility changes. However, the layout will be able to provide the most complete set of all truly hidden nodes.

    
aria-invalid="true", "spelling", or "grammar" (state)Set INVALID_ENTRY. In addition, expose the value as a text attribute (not object attribute). Current possible values are are "true", "spelling" or "grammar". Expose the validation status in IsDataValidForForm property  
aria-invalid="false" (state) (default)
  • Clear INVALID_ENTRY or equivalent state.
    
aria-label     
aria-labelledby Expose the relations as described in Relations and compute the accessible name as described in Name ComputationLabeledBy property expose a reference to an accessible object corresponds to the ID specified by the aria-labelledby.Expose the relations as described in Relations and compute the accessible name as described in Name Computation 
aria-levelExpose the level by accValue property of an outline object.Expose value in"level" object attribute and in groupPosition. May affect RELATION_NODE_CHILD_OF when used on a tree item. See section Group Position.The tree hierarchy should be represented in the Automation Element structure.  
aria-live="polite" or "assertive"     
aria-live="off" (default)     
aria-multiline="true" Set the MULTI_LINE state and clear SINGLE_LINE  report "textbox" role as AXTextArea
aria-multiline="false" (default) Clear the MULTI_LINE state, and set SINGLE_LINE  report "textbox" role as AXTextArea
aria-multiselectable="trueSet the MULTISELECTABLE state. Expose STATE_SYSTEM_EXTSELECTABLE to exactly match MULTISELECTABLE.Expose the AccessibleSelection interface. See Selection.Set CanSelectMultiple property with the Selection Control Pattern.  
aria-multiselectable=false (default)Clear the MULTISELECTABLE state. Expose STATE_SYSTEM_EXTSELECTABLE to exactly match MULTISELECTABLE.Expose the AccessibleSelection interface. See Selection.   
aria-ownsthe structure should be reflected in the accessible tree as directed by aria-owns.Expose the relations as described in RelationsThe structure should be reflected in the accessible tree as directed by aria-owns.Expose the relations as described in Relations 
aria-posinsetthe structure should be reflected in the accessible tree as directed by aria-posinset.Expose value in "posinset" object attribute and in groupPositionThe structure should be reflected in the accessible tree as directed by aria-posinset.  
aria-pressed="true" (state)
  • Set the PRESSED state.
  • Expose object attribute checkable="true"
If on a button (WAI-ARIA/HTML/XUL), expose the role as IA2_ROLE_TOGGLE_BUTTON.aria-pressed is exposed as ToggleState property of Toggle Control PatternIf on a button (WAI-ARIA/HTML/XUL), expose the role as ATK_ROLE_TOGGLE_BUTTON. 
aria-pressed="mixed" (state)
  • Set the PRESSED state.
  • Expose object attribute checkable="true"
If on a button (WAI-ARIA/HTML/XUL), expose the role as IA2_ROLE_TOGGLE_BUTTON.aria-pressed is exposed as ToggleState property of Toggle Control PatternExpose ATK_STATE_INDETERMINATE/STATE_SYSTEM_MIXED. If on a button (WAI-ARIA/HTML/XUL), expose the role as ATK_ROLE_TOGGLE_BUTTON. 
aria-pressed="false" (state)
  • Clear the PRESSED state
  • Expose object attribute checkable="true"
If on a button (WAI-ARIA/HTML/XUL), expose the role as IA2_ROLE_TOGGLE_BUTTON.aria-pressed is exposed as ToggleState property of Toggle Control PatternIf on a button (WAI-ARIA/HTML/XUL), expose the role as ATK_ROLE_TOGGLE_BUTTON. 
aria-pressed is undefined (state) (default)     
aria-readonly="true"Expose as STATE_SYSTEM_READONLYIf on an element that is editable, e.g. an ENTRY or supports the IAccessibleEditableText interface, make sure that EDITABLE is set to the logical opposite of READONLY   
aria-readonly="false" (default)Expose as STATE_SYSTEM_READONLYIf on an element that is editable, e.g. an ENTRY or supports the IAccessibleEditableText interface, make sure that EDITABLE is set to the logical opposite of READONLY   
aria-relevant="additions", "removals", "text", or "all" Expose the value in an object attribute called "relevant". Expose a "container-relevant" object attribute with the value on all descendants as described in Changes to document content or node visibility.   
aria-relevant="additions text" (Default) Expose the value in an object attribute called "relevant". Expose a "container-relevant" object attribute with the value on all descendants as described in Changes to document content or node visibility.   
aria-required Expose as REQUIRED stateexpose as IsrequiredForForm property.  
aria-selected="true" (state)
  • Expose SELECTED
  • Expose SELECTABLE
  • If not DISABLED, toggle between "true" and "false" as appropriate when the Accessible Selection interface is used on an ancestor with aria-multiselectable as described in Selection.
 the IsSelected property (SelectionItem Control Pattern) represents the selection state. The availability of SelectionItem Control Pattern indicate the ability. set AXSelected attribute
aria-selected="false" (state)
  • Clear SELECTED
  • Expose SELECTABLE
  • If not DISABLED, toggle between "true" and "false" as appropriate when the Accessible Selection interface is used on an ancestor with aria-multiselectable as described in Selection.
   Set AXSelected attribute
aria-selected is undefined (state) (default)
  • The object is not selectable.
    
aria-setsize Expose value in "setsize" object attribute and in groupPosition   
aria-sort="ascending" or "descending" Expose value in "sort" object attribute   
aria-sort="none" (default) Expose value in "sort" object attribute   
aria-valuemax Expose via AccessibleValue interface.
See Widget values for additional information		Expose the Maximum property in RangeValue Control Pattern
See Widget values for additional information		 set AXMaxValue attribute
See Widget values for additional information
aria-valuemin Expose via AccessibleValue interface
See Widget values for additional information		Expose the Minimum property in RangeValue Control Pattern
See Widget values for additional information		 Set AXMinValue attribute
See Widget values for additional information
aria-valuenowIf aria-valuetext is not defined, expose via IAccessible::get_accValueExpose via AccessibleValue interface. If aria-valuetext is undefined, expose a string version of the aria-valuenow in the "valuetext" object attribute.
See Widget values for additional information		Expose Value property in RangeValue Control Pattern
See Widget values for additional information		 Set AXValue and post NSAccessibilityValueChangedNotification if necessary
See Widget values for additional information
aria-valuetextExpose via IAccessible::get_accValueExpose in "valuetext" object attribute
See Widget values for additional information		Expose Value property in Value Control Pattern which can co-exist with RangeValue Control Pattern.
See Widget values for additional information		 Set NSAccessibilityValueDescriptionAttribute to valuetext string.
See Widget values for additional information

From Masahiko: In UIA, the AriaProperties property directly corresponds to the ARIA states and properties when an element is exposed in the accessible tree. UIA AriaProperties is a string property formatted as a name and value pair. For example, "checked=true;disabled=false". Deliminators are the equal sign ("=") and the semicolon (";"). A backslash (\) is used as an escape when the deliminator character or a backslash appears in the value. Some states that take ID as context are not however supported by the UIA AriaProperties. Instead, UIA supports specific relations properties such as DescribedBy or LabeledBy. Full mapping from ARIA states to MSAA and UIA properties are available at MSDN UIA SDK Appendix.

3.6. Special Processing Requiring Additional Computation

3.6.1. Name and Description

3.6.1.1. Text Equivalent Computation

The text equivalent is reused in both the name and description computation, as described below. There are different rules provided for several different types of nodes and combinations of markup. Text equivalents are built up, when appropriate, from all the relevant content contained within an element. This is accomplished via rule 2C (which is recursive), using the full set of rules to retrieve text from its own children.

The text equivalent for a given node is computed as follows:

  1. Skip hidden elements unless the author specifies to use them via an aria-labelledby or aria-describedby being used in the current computation. By default, users of assistive technologies won't receive the hidden information, but an author should to be able to explicitly override that and include the hidden information.
  2. For any non-skipped elements:
    1. Elements may specify their text equivalent in DOM attributes, used in this order of preference:
      • The aria-labelledby attribute is used unless this computation is already occurring as the result of another aria-labelledby (in other words, aria-labelledby is not recursive, so it will not cause loops). The text equivalents for all the nodes pointed to will be concatenated, using this same set of rules.
      • The aria-label attribute, which is just a text string, is used next
      • Any native markup (such as an img element's alt attribute in HTML), or the subtree for a label pointing to this element (such as label element's for attribute in HTML) contributes according to rules defined by the appropriate specification for that markup.
    2. In addition to any text from rule A, a form control contributes its user-entered value to the final computed name, if it is in a position that provides meaningful information in the context of a larger label. The user-entered data should be appended after any other labeling markup used for that form control. For example, an WAI-ARIA slider element's user-entered value would be the aria-valuetext or string equivalent of the aria-valuenow. For text fields, the user-entered data would be the text in the field.
    3. Otherwise, if the DOM attributes checked in rules A and B didn't provide results, text is collected from descendant content if the current element's role allows "Name From: contents." The text equivalents for child nodes will be concatenated, using this same set of rules. This same rule may apply to a child, which means the computation becomes recursive and can result in text being collected in all the nodes in this subtree, no matter how deep they are. However, any given descendant subtree may instead collect their part of the text equivalent from the preferred markup described in A and B above. These author-specified attributes are assumed to provide the correct text equivalent for the entire subtree. All in all, the node rules are applied consistently as text equivalents are collected from descendants, and each containing element in those descendants may or may not allow their contents to be used.
    4. The last resort is to use text from a tooltip attribute (such as the title attribute in HTML). This is used only if nothing else, including subtree content, has provided results.
  3. Text nodes are often visited because they are children of an element that uses rule 2C to collect text from its children. For text nodes, rendered text is used rather than DOM text contents. This helps remove superfluous whitespace from the original source, and to include CSS-generated text such as list item bullets.

Note: The purpose of the flat text equivalent string is to create something readable in alternative presentations. An implementation should insert whitespace characters when visually separate elements would be "jammed" together in the same string. For example, a space character may be inserted between the text of two paragraphs used one after the other in a description.

3.6.1.2. Name Computation

If aria-label is not present but aria-labelledby is present, the user agent must compute the name by concatenating the text equivalent of each element referenced by the IDs in the aria-labelledby attribute, in sequential order, with a space delimeter between each text equivalent.

Otherwise, aria-labelledby will not be used, and the accessible name must be computed using the text equivalent computation on the current element.

If the element is an <img> and the text equivalent is empty, then check for the presence of role presentation or any labeling attribute, specifically aria-label, aria-labelledby, alt or title. The presence of any of these indicates the author's intention to indicate that the <img> is decorative or redundant. In this case, the user agent must set the name to an empty string. If none of these attributes are present, this indicates the author simply did not provide an accessible label for the image, and the implementation must return an accessible name of NULL instead of an empty string if the API supports it. This hints to the AT to do its own heuristic processing to repair the missing accessible name.

3.6.1.3. Description Computation

To compute the accessible description for an element, start with an empty string:

If aria-describedby is present, collect the description from the elements pointed to by aria-describedby. Process the IDs in aria-describedby in the order they occur. Ignore IDs that are not specified on an element in the document. For each ID use the text equivalent computation.

3.6.2. Widget Values

Widgets that have a particular value within a range of values, such as progressbar, spinbutton, and slider, use aria-valuemin and aria-valuemax to specify the range of valid values, aria-valuenow to specify the current value, and optionally aria-valuetext to specify a text string equivalent for the current value.

If the value is not set on a control that requires value, then current value should return an error.

When the user sets the value on an object that is not readonly or disabled, the user agent should set aria-valuenow to reflect the new value. The implementation should reject values which are less than the aria-valuemin or greater than the aria-valuemax. In the case of an invalid aria-valuenow attribute, an error may be reported to the debugging console but should not be reported through the API. If the value cannot be set because the object is readonly or disabled or the new value would be out of bounds, the user agent should throw an exception rather than set the value.

3.6.3. Relations

In UIA, the relations are exposed as references to the corresponding accessible object in ControllerFor, DescribedBy, FlowsTo, and LabeledBy properties. The aria-owns property is expected to be reflected in the accessible tree of MSAA and UIA.

IAccessible2 and ATK have specific implementation designs for relations, which relate to WAI-ARIA properties such as aria-controls and aria-describedby as explained in the following section.

Often in a GUI, there are relationships between the widgets that must be exposed programmatically to assistive technology. WAI-ARIA provides several properties for defining both forward and reverse relationships. A forward relation exists when an element has properties that refer to the ID of another element. Forward relations map directly to an accessibility API in most cases. A reverse relation exists when an element's ID is referenced by a property in another element. In order to determine the reverse relations, the user agent must determine if there are any elements that reference the current element's ID.

All relations are globally applicable to any element, so it is not important to check the role before computing them. Relationship attributes use an ID list (space separated list of IDs). A relationship ID matches the element having that ID, that is returned by getElementById with the ID as an argument.

Exposing forward relations:

Computing reverse relations:

  • Check for other elements using WAI-ARIA relations that point to the current element's ID, in order to expose the reverse relations
  • If aria-controls points to the element: expose RELATION_CONTROLLED_BY
  • If aria-describedby points to the element: expose RELATION_DESCRIPTION_FOR
  • If aria-flowto points to the element: expose RELATION_FLOW_FROM
  • If aria-labelledby points to the element: expose RELATION_LABEL_FOR
  • If aria-owns points to the element: expose RELATION_NODE_CHILD_OF

If both aria-labelledby and HTML <label for=> are used, the WAI-ARIA relation wins and the HTML label relation is ignored.

Computing RELATION_NODE_CHILD_OF for role="treeitem", when aria-owns is not used:

  • If the current treeitem uses aria-level, then walk backwards in the tree until a treeitem is found with a lower aria-level, and point to that. If the top of the tree is reached, then point to the tree itself.
  • If the parent of the treeitem is role="group", then walk backwards from the group until a treeitem is found and point to that. This is the case where role="group" is used to organize levels in the tree.

Computing RELATION_MEMBER_OF from aria-atomic:

  • Check the chain of ancestor elements for aria-atomic="true". All accessible descendants of that element should use the RELATION_MEMBER_OF relation to point to the ancestor that sets aria-atomic="true".

3.6.4. Group Position

The aria-level and aria-posinset properties are expected to be reflected in the accessible tree of MSAA and UIA.

IAccessible2 and ATK have specific implementation designs for group positioning as follows. The object attributes "posinset", "setsize" and "level" should be exposed when the equivalent WAI-ARIA properties are supported by a role used on the element. In addition, on IAccessible2 the same information must be exposed via IAccessible2::groupPosition.

Computing the level if not provided:

  • For role="treeitem", if aria-level is not provided by the author, it must be computed by following the explicit or computed RELATION_NODE_CHILD_OF as described in Relations.

When computing posinset and setsize if not provided:

  • for role="treeitem", walk the tree backward and forward until the explicit or computed level becomes less than the current item's level. Count items only if they are at the same level as the current item.
  • Otherwise, walk backward and forward within the DOM parent, counting items that have the same role.
  • The posinset includes the current item and items before it in the group. The setsize adds to that the number of items in the same group after the current item.

These properties are all 1-based. When the object property is not present or holds a value of "0", it indicates the property is not computed or not supported.

Because these values are 1-based, the current item must be included in the computation. For posinset, add items only if they are before the current item in the DOM. For setsize, also add items after the current item in the DOM.

3.7. Actions

Actions are exposed by the following rules

In MSAA, an action can be mapped to the DoDefaultAction and DefaultAction properties unless it is already supported by the baseline mapping (e.g., "jump" action for the hyperlink element).

In UIA, an action can be mapped to the Invoke pattern, unless it is already supported by the baseline mapping.

In IAccessible2, an action can be exposed by the AccessibleAction interface.

Table of WAI-ARIA Roles that have actions associated with them
WAI-ARIA RoleDefault actionEvent
buttonclick 
checkboxcheck/uncheck 
comboboxopen/close 
linkjump 
listitemselect/unselect if parent role is listbox 
menuitemclick 
menuitemcheckboxclick 
menuitemradioclick 
optionselect/unselect 
radioselect 
tabswitch 
textboxactivate 
treeitemactivate + expand/collapse 
Table of WAI-ARIA States and Properties that cause elements to have actions associated with them
WAI-ARIA State or PropertyActionsEventsNotes
aria-activedescendantclick, activate, invoke (UIA)focus, blurAdd focused and focusable API states
aria-dropeffectShift-F10, right clickfocus, blurpopup collection of actions the user can perform
focusable
Should have a navigation dialog for all hit targets and landmarks
Should have style sheet to highlight all targets
aria-expandedclick, arrow keyexpansion eventsEditorial note: interested in exploring expand/collapse
aria-grabbedif grabbable, expose grab action
if grabbed, targets become focusable		 focusable, selectable
if aria-grabbed="true", change to focused, collection of drop targets will become focusable
aria-haspopupdisplay popup menu  
aria-live update 
aria-relevant  live region, what's relevant to listen for?
what events the API should be supporting
aria-selected selection 
aria-sortclick  

3.8. Events

User agents must fire events for user actions, WAI-ARIA state and property changes, changes to document content or node visibility, changes in selection, and operation of menus.

3.8.1. Action Events

Table of events to be fired in each API for each action
ActionMSAA eventIAccessible2 event (if different from MSAA)UIA eventATK eventNSAccessibility Event
      

3.8.2. State and Property Change Events

For dynamic WAI-ARIA state and property changes, user agents must expose an event, such as state change, to indicate the change occurred. For simplicity and performance the user agent may trim out change events for state or property changes that assistive technologies typically ignore. An event must be fired for changes in:

  • aria-disabled: this will affect ENABLED and SENSITIVE states
  • aria-checked or aria-pressed: this will affect the CHECKED state. A state change for MIXED/INDETERMINATE should also be fired when the value changes to or from "mixed".
  • aria-invalid: this will affect the INVALID_ENTRY state. Note that this is different from the INVALID state in some APIs which means no valid state.
  • aria-expanded, aria-readonly, aria-required: these will affect the states of similar names in the accessibility APIs

Other types of changes:

Table of events to be fired in each API for changes in WAI-ARIA states and properties
State or PropertyMSAA eventIAccessible2 event (if different from MSAA)UIA eventATK eventNSAccessibility Event
aria-busy     
aria-checked     
aria-disabled     
aria-grabbed     
aria-invalid     
aria-expanded     
aria-readonly     
aria-required     
aria-valuenow     

3.8.3. Changes to document content or node visibility

Processing document changes is important regardless of WAI-ARIA. We document how to do it here, however, because it is so crucial to enable the AJAX and other use cases that often go along with WAI-ARIA markup.

In UIA, TextChangedEvent, TextSelectionChangedEvent, or PropertyChanged event for corresponding property (e.g., Value property of Value Pattern where Document accessible element supports Value Control Pattern for the inner text).

Table of document change scenarios and events to be fired in each API
ScenarioMSAA eventIAccessible2 event (if different from MSAA)UIA eventATK eventNSAccessibility Event
When text is removed IA2_EVENT_TEXT_REMOVED text_changed:delete 
When text is inserted IA2_EVENT_TEXT_INSERTED text_changed:insert 
When text is changedfire a removal event followed by an insertion eventfire a removal event followed by an insertion eventfire a removal event followed by an insertion eventfire a removal event followed by an insertion eventfire a removal event followed by an insertion event

Fire these events for node changes where the node in question is an element and has an accessible object:

Table of document change scenarios and events to be fired in each API
ScenarioMSAA eventIAccessible2 event (if different from MSAA)UIA eventATK eventNSAccessibility Event
When a subtree is removed or hidden

Depends on aria-relevant?		EVENT_OBJECT_HIDE
The MSAA event called EVENT_OBJECT_DESTROY is not used because this has a history of stability issues and ATs avoid it. In any case, from the user's point of view, there is no difference between something that is hidden or destroyed. 		  children_changed:remove 
When a subtree is inserted or shownEVENT_OBJECT_SHOW  children_changed:add 
When a subtree is movedtreat it as a removal from one place and insertion in another and
fire EVENT_OBJECT_REORDER on the parent		 treat it as a removal from one place and insertion in anothertreat it as a removal from one place and insertion in anothertreat it as a removal from one place and insertion in another
When a subtree is changed (e.g. replaceNode)treat it as a removal and insertion and
fire EVENT_OBJECT_REORDER on the parent		 treat it as a removal and insertiontreat it as a removal and insertiontreat it as a removal and insertion

For node changes where the node is not an element or has no accessible object:

  • This will likely affect the text output by the AccessibleText interface. Compute and fire relevant text change events as described above.
  • There may be accessible descendants. The appropriate show/hide/children_changed events must be fired for the first-line descendants with accessible objects.

When firing any of the above-mentioned change events, it is very useful to provide information about whether the change was caused by user input (as opposed to a timeout initiated from the page load, etc.). This allows the AT to have different rules for presenting changes from the real world as opposed to from user action. Mouse hovers are not considered explicit user input because they can occur from accidental bumps of the mouse.

To expose whether a change occurred from user input:

  • In ATK this can be provided by appending the string ":system" to the event name when the user did not cause the change.
  • In IAccessible2, which screen readers typically access in process on the same thread, the best practice is to expose the object attribute "event-from-user-input=true" on the accessible object for the event, if the user caused the change.

Exposing additional useful information about the context of the change:

  • The RELATION_MEMBER_OF relation on the accessible event object should point to any ancestor with aria-atomic="true" (if any).
  • The container-live, container-relevant, container-busy, container-atomic object attributes should be exposed on the accessible event object, providing the computed value for the related WAI-ARIA properties. The computed value is the value of the closest ancestor. It is recommended to not expose the object attribute if the default value is used.

Additional MSAA events may be necessary:

  • If something changes in an ancestor with a mapped MSAA role of ROLE_SYSTEM_ALERT, then an EVENT_SYSTEM_ALERT event should be fired for the alert. The alert role has an implied value of "assertive" for the aria-live property.
  • Menu events may need to be fired. See Menus in MSAA/IAccessible2.

3.8.4. Selection

There are two cases for selection:

  • Single selection
  • Multiple selection

In the single selection case, it is not always necessary to manage selection events and states separate from focus, since selection mirrors focus. One exception is for tab lists. In the case of a tab, if either the tab or its associated tabpanel has focus, then the tab is considered to be SELECTED. To implement this, the user agent can walk up the parent chain from the focus until it finds a tabpanel, then traverse the aria-labelledby relation from the tabpanel to the related tab, and mark the found tab as focused.

The multiple selection case occurs when aria-multiselectable="true" on an element with a role that supports that property. There are several important aspects:

  1. Expose the correct states on the container: MULTISELECTABLE and, in MSAA, it is also EXTSELECTABLE
  2. In UIA, the Selection and SelectionItem Control Patterns exposes the selection availability, state, and methods.
  3. In IAccessible2, support the AccessibleSelection interface on the container with aria-multiselectable. The selection interface can be used by an AT to actually set the selection on a descendant. This should fail for the specified descendant if aria-selected is undefined, which indicates the element is not SELECTABLE. It should also fail if the specified descendant is DISABLED or READONLY for any reason. When clearing selection on an item, set aria-selected="false" but do not remove the attribute, so that it is still SELECTABLE.
  4. Fire the correct events when aria-selected changes on a descendant, as follows:
ScenarioMSAA/IA2UI AutomationATK/AT-SPI
Toggle aria-selectedEVENT_OBJECT_SELECTIONADD/EVENT_OBJECT_SELECTIONREMOVE on the current container + EVENT_OBJECT_STATECHANGE on the itemSelectionItem Control Pattern; ElementSelected, ElementRemovedFromSlection, ElementAddedToSelectionobject::selection_changed + atk_object_notify_state_change on the item
Selection follows focusEVENT_OBJECT_SELECTION then state change event on newly focused item, but arrange events so state change doesn't occur on focused item, to avoid extra selection change announcementsFocusChangedEvent should fired but individual selection event may not happen, to avoid redundancy.object:selection_changed + atk_object_notify_state_change, but arrange events so state change doesn't occur on focused item, to avoid extra selection change announcements
Select or deselect many items at once:EVENT_OBJECT_SELECTIONWITHIN is all that is necessary. The state change events may be trimmed out for performance.Selection Control Pattern Invalidated event can be used when the container has bulk of changes or when an exact selection is not clear.object:selection_changed. The state change events may be trimmed out for performance

3.8.5. Menus in MSAA/IAccessible2/UIA

When using MSAA and UIA, special events are required whenever a menu is opened or closed. Because screen readers on Windows typically ignore focus events while menus are open, these events must be nested and symmetrical. Because menus can be made visible or hidden using a variety of techniques, it is advisable that an implementation keep track of the menu events fired and ensure that they are symmetrical.

ScenarioMSAA/IA2UI Automation
Open menu in menubar
  • Triggered when focus goes to menuitem and menu "mode" is not currently active.
  • ???Menubar must be in the natural parent chain or in the one caused by aria-owns (use RELATION_NODE_CHILD_OF)????
EVENT_SYSTEM_MENUSTART, then set menu "mode"MenuModeStartEvent
Menu popup made visible
  • Should only be fired once until the menu is closed and opened again.
  • ???Care should be taken to check descendents for role="menu" when any subtree is made visible. The menu role might not be on the root node of the change.???
  • If not in menu "mode", EVENT_SYSTEM_MENUSTART, then set menu "mode"
  • EVENT_SYSTEM_MENUPOPUPSTART, then a focus event on a menuitem
MenuOpenedEvent, then a focus event on a menuitem
Menu popup hiddenEVENT_SYSTEMMENUPOPUPEND once only for accessible menu object and only if EVENT_SYSTEM_MENUPOPUPSTART was fired for it.MenuClosedEvent
When in menu "mode" and all menus closedEVENT_SYSTEM_MENUEND, clear menu "mode"MenuModeEndEvent
Focus moved out of menuEVENT_SYSTEM_MENUPOPUPEND, then EVENT_SYSTEM_MENUEND and clear menu "mode"MenuClosedEvent, then MenuModeEndEvent
  • A single EVENT_SYSTEM_MENUSTART (see later for UIA equivalents) when a menu in a menubar is opened. This is triggered when focus goes to a menuitem and menu mode is not currently active, but it must be fired before any EVENT_SYSTEM_MENUPOPUPSTART events. The menubar must be either in the natural parent chain or or in the one caused by aria-owns (use RELATION_NODE_CHILD_OF impl to go to aria-owns ancestor) or reflected in the accessible tree.
  • One or more EVENT_SYSTEM_MENUPOPUPSTART when a menu popup is made visible. This is triggered when a menu is made visible, but should only be fired once until the menu is closed and reopened again. Care should be taken to check descendants for role="menu" when any subtree is made visible. The menu role might not be on the root node of the change.
  • A focus event on a menuitem. This must occur after the EVENT_SYSTEM_MENUPOPUPSTART.
  • One or more EVENT_SYSTEM_MENUPOPUPEND when a menu popup is hidden. This should only be fired for an accessible menu object when an EVENT_SYSTEM_MENUPOPUPSTART was fired for it, and it should only be fired once in that case. Care should be taken to check descendants for role="menu" when a subtree is hidden.
  • A final EVENT_SYSTEM_MENUEND when in menubar mode (an EVENT_SYSTEM_MENUSTART was fired) and either all menus in a menubar are closed or focus goes somewhere other than a menuitem (such as a control in a dialog).

The equivalents of menu events in UIA is MenuModeStartEvent, MenuModeEndEvent, MenuOpenedEvent, and MenuClosedEvent for MSAA EVENT_SYSTEM_MENUSTART, EVENT_SYSTEM_MENUEND, EVENT_SYSTEM_MENUPOPUPSTART, EVENT_SYSTEM_MENUPOPUPEND.

4. Special Document Handling Procedures

4.1. Documents, Handling frame and iframe elements

Computing the accessible name for an outer document accessible:

Computing the accessible name for an inner document accessible:

  1. If a sub-document, do a depth-first name computation using aria-labelledby from the <frame> or <iframe>. If the name is still empty, use the title attribute from the <frame> or <iframe>.
  2. If the name is still empty, use a depth-first name computation from aria-labelledby on the document's root WAI-ARIA node. If it is still empty use the title attribute on the root WAI-ARIA node.
  3. If the name is still empty, and the <title> element or some other means exists of getting the accessible name, use that.

Computing the accessible description for an inner document accessible:

  1. If a sub-document, do a depth-first description computation using aria-describedby from the <frame> or <iframe>.
  2. If the description is still empty, use a depth-first name computation from aria-describedby on the document's root WAI-ARIA node.

Computing container-foo on any node in a sub document: For container-live, container-atomic, container-relevant, and container-busy, inner nodes override outer nodes from within the same document, because the inner subtree is the more relevant context. However, outer documents override inner documents, because the outer document author may be different and may wish to define the context for a live iframe. Therefore:

  1. Walk the entire parent chain including that from outer documents, collecting the properties from aria-live, aria-atomic, aria-relevant, and aria-busy into the container-[property] object attribute
  2. If a node sets a given object attribute, set a state that doesn't allow that value to change that object attribute again within the document
  3. When entering a parent document, refresh the state to again allow override of each of these object properties

Computing other properties for an inner document accessible:

  1. For user-controlled properties (aria-selected, aria-valuenow, aria-valuetext, aria-activedescendant), use the WAI-ARIA markup on the root WAI-ARIA node only
  2. The WAI-ARIA properties on the outer document accessible take precedence, on a property-by-property basis
  3. If the outer document accessible does not set a property, the root WAI-ARIA node for the inner document is used
  4. Relations are not concatenative. If the outer document accessible sets a relation, that is used instead of anything set on the inner document's root WAI-ARIA node.

4.2. CSS Selectors

Support for attribute selectors must include WAI-ARIA attributes. For example, .fooMenuItem['aria-haspop=true'] whould select all elements with class "fooMenuItem", and WAI-ARIA attribute "aria-haspopup" with value true. The presentation must be updated for dynamic changes to WAI-ARIA attributes. This allows authors to match styling with WAI-ARIA semantics.

5. Error Handling

Editorial note: Section 5 Error Handling does not have significant changes since the July 6, 2009 Editor's Draft.

5.2. Value type: IDREF and IDREFS

Q: What happens if an invalid ID is specified for a WAI-ARIA property?
A: The UA will ignore the ID.

Q: What if the WAI-ARIA property contains a mixture of valid and invalid IDs?
A: The UA will return only the objects corresponding to the valid IDs.

Q: What if there is more than one element with the same ID?
A: The first element found with the given ID will be what is used. The behavior will be the same as getElementById, and it is the web author’s responsibility to ensure uniqueness of IDs.

Q: What if the same element is specified multiple times in a single WAI-ARIA relation of type IDREFS?
A: [Might need to reword this, I am assuming the return is an array of pointers to accessible objects] The UA will return multiple pointers to the same object.

Q: What happens if more than one ID is specified (space-separated list) for a property that is a single IDREF?
A: The UA will use the whole string (without splitting on spaces) and try to look up an element that has that ID. For instancearia-activedescendant="foo bar" would match id="foo bar".

[IE-specific] Q: What if the author is using the “name” attribute instead of “id”, since they were interchangeable in IE7?
A: IE will only match on the “id” attribute, regardless of the version of the document. We believe that matching only on the “id” attribute is the correct behavior.

5.3. Value type: decimal

Q: What if a non-numeric value is specified for a decimal type?
A: If asking for the string version of the property, the UA will simply return the string specified by the author. However, if a decimal is specifically requested, the UA will fail to convert the string to a decimal and return a default value of 0.0.

5.4. Value type: integer

Q: What if a non-numeric value is specified for an integer type?
A: If asking for the string version of the property, the UA will simply return the string specified by the author. However, if an integer is specifically requested, the UA will fail to convert the string to a decimal and return a default value of 0.

5.5. UA Validation

In general, UAs do not do much validation of WAI-ARIA properties. Some minor validation may occur on request, such as making sure valid IDs are specified for WAI-ARIA relations, and enforcing things like aria-posinset being within 1 and aria-setsize, inclusive. UAs are not responsible for logical validation, such as the following:

  1. Circular references created by relations, such as specifying that two elements own each other.
  2. Correct usage with regard to DOM tree structure, such as an aria-activedescendant being a DOM-descendant of the element with the relation.
  3. Elements with WAI-ARIA roles correctly implement the specified role. For example, UAs do not verify that an element with role=”checkbox” actually behaves like a checkbox.

5.6. Roles

Q. What happens if the author uses an abstract role, or a role that does not map to a standard role for the platform accessibility API?
A: See WAI-ARIA 8.1.3 Step-by-step. If a given role in the role attribute is abstract or has no mapping, skip that role. If no known role is found in the role attribute, process it the same as if the role attribute is absent except expose the role attribute value in the xml-roles object attribute.

Q. What happens if the author changes the role of an element dynamically?
A. This is considered incorrect practice by the WAI-ARIA specification, can cause changes in what accessible interfaces need to be supported by an object, and is unexpected by ATs. Therefore, the least expensive way to handle dynamic role changes is used: fire the appropriate invalidation events for object with the role change, so that the AT will update its cache or virtual buffer. The relevant invalidation events are:

Q. What should user agents do when required child / parent role relationships not observed?
A. ??? See ISSUE-98

Q. What should user agents do when roles appear elsewhere than in their required parent?
A. ??? See ISSUE-99

5.7. States and Properties

Q. Some WAI-ARIA properties are not global, and are only supported on certain roles. What should be mapped when a dependent WAI-ARIA property is used where it is not supported?
A. The user agent should act as if the WAI-ARIA property is absent, and not not map the given WAI-ARIA property through the platform accessibility API. For example, aria-checked should not be exposed as CHECKED on <div role="grid">

Q. What should be exposed to platform accessibility APIs when a WAI-ARIA property contains an unknown or disallowed value?
A.1 When exposing as an object attribute, expose the unknown value—do not vet it against possible values.
A.2 When exposing as a platform API Boolean state, treat "", "undefined" or no attribute present as false. Treat any other value as true.
A.3 Otherwise, ignore the value and treat the property as not present A.4 In UIA, UA can leave corresponding property set to "unsupported."

Q. What should be exposed to platform accessibility APIs when an unknown WAI-ARIA property is used?
A. Expose an object attribute with the same name, with the "aria-" prefix removed. The object attribute's value should be equal to the WAI-ARIA property's value. This will help with forward compatibility with new WAI-ARIA properties in future versions.

Q. What if aria-hidden does not match the reality of whether a node is visible or not?
A. This error condition does not even need to be checked for, because aria-hidden is not necessary when a layout API provides more complete information. Advisory: it is incorrect use of WAI-ARIA if an element with aria-hidden="true" is visible. The aria-hidden property is exposed only so that DOM-based assistive technologies can be informed of visibility changes. Since layout APIs will be able to provide the most complete set of all truly hidden nodes, they should be used instead of the aria-hidden attribute.

Q. If an AT uses a platform accessibility APIs setter to change aria-valuenow, should the user agent ensure that the new value is within the bounds set by aria-valuemin and aria-valuemax?
A. Yes. Do not set the value if it is out of bounds. Note, however, that it is still the final responsibility of the web application to ensure the validity of user data.

Q. If an AT uses a platform accessibility API getter to get aria-valuenow, should the user agent ensure that it is within the bounds set by aria-valuemin and aria-valuemax?
A. No, simply expose the aria-valuenow whether it is out of bounds or not.

Q. What if an element has the aria-valuetext property set, but not aria-valuenow?
A. Expose the valuetext as defined in this guide, but return an error for any value getter that only returns a numeric type

Q. If an AT uses a platform accessibility API setter to change aria-valuenow, should the user agent ensure that the current element is not disabled or readonly?
A. Yes. Do not set the value if the current element is disabled or readonly

Q. If an AT uses the platform accessibility API to change whether an element is selected, should the user agent ensure that the element is not disabled?
A. Yes. Do not set or clear the selection if the current element is disabled (although it is okay to change the selection for readonly elements)

Q. Should the user agent check whether aria-activedescendant actually points to a descendant or not?
A. No

Q. What if aria-level, aria-setsize or aria-posinset are 0 or negative?
A. Return 1

Q. What if aria-posinset is larger than aria-setsize?
A. Return aria-setsize in place of aria-posinset

Q. What if a required aria property (i.e. required for a given role) is missing for a given widget?
A.

WAI-ARIA roleRequired State/PropertyDefault value
checkboxaria-pressedundefined
comboboxaria-expandedundefined
slideraria-valuemax0
slideraria-valuemin0
slideraria-valuenow?
spinbuttonaria-valuemax0. See ISSUE-86
spinbuttonaria-valuemin0. See ISSUE-87
spinbuttonaria-valuenowSee ISSUE-86

5.8. Propagating errors to ATs

Most errors that occur due to WAI-ARIA are not propagated to callers. For example, finding an invalid ID in a list of IDREFS is not a reason to return an error code to the caller. Errors that can propagate are specific to certain WAI-ARIA properties.

  1. ChildID and aria-owns: aria-owns appends a list of children to an element. Specifying a child ID outside of the new valid range still returns an error, the same that would occur before when specifying an invalid child ID.

6. Appendices

This section is informative.

6.1. Glossary

accessible object

TBD

activation behavior

The action taken when an event, typically initiated by users through an input device, causes an element to fulfill a defined role. The role may be defined for that element by the host language, or by author-defined variables, or both. The role for any given element may be a generic action, or may be unique to that element. For example, the activation behavior of an HTML or SVG <a> element shall be to cause the user agent to traverse the link specified in the href attribute, with the further optional parameter of specifying the browsing context for the traversal (such as the current window or tab, a named window, or a new window); the activation behavior of an HTML <input> element with the type attribute value submit shall be to send the values of the form elements to an author-defined IRI by the author-defined HTTP method.

current node

The DOM node currently traversed in order to compute the text equivalent.

current total text

When computing the text equivalent, the text equivalent that has been computed up until arrival at the current DOM node.

Inner document accessible

the accessible object representing the root WAI-ARIA node for the spawned document. It is a child of the outer document accessible.

Outer document accessible

the accessible object representing the <frame>/<iframe>

Root WAI-ARIA node

the <body> or <frameset> in HTML, or the document element in all other languages.

Sub-document

any document created from a <frame>, <iframe> or similar mechanism. A sub-document may contain a document, an application or any widget such as a calendar pulled in from another server. In the accessible tree there are two accessible objects for this situation—one represents the <frame>/<iframe> element in the parent document, which parents a single accessible object child representing the spawned document contents.

Target Element

An element specified in a WAI-ARIA relation. For example, in aria-controls=”elem1”, “elem1” is the target element.

Valid ID

A specified ID for a WAI-ARIA property that satisfies the following condition:
It refers to a target element that exists in the same document as the element specifying the relation.

6.2. References

This section is informative.

[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), 4 February 2008. This version of WAI-ARIA is available at http://www.w3.org/TR/2008/WD-wai-aria-20080204/. Latest version of WAI-ARIA available at http://www.w3.org/TR/wai-aria/.
[ARIA-PRACTICES]
WAI-ARIA Best Practices. L. Pappas, R. Schwerdtfeger, M. Cooper, Editors, W3C Working Draft (work in progress), 4 February 2008. This version of WAI-ARIA Best Practices is available at http://www.w3.org/TR/2008/WD-wai-aria-practices-20080204/. Latest version of WAI-ARIA Best Practices available at http://www.w3.org/TR/wai-aria-practices/.
[ARIA-PRIMER]
WAI-ARIA Primer. L. Pappas, R. Schwerdtfeger, M. Cooper, Editors, W3C Working Draft (work in progress), 4 February 2008. This version of WAI-ARIA Primer is available at http://www.w3.org/TR/2008/WD-wai-aria-primer-20080204/. Latest version of WAI-ARIA Primer available at http://www.w3.org/TR/wai-aria-primer/.
[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/.
[RFC2119]
Key words for use in RFCs to indicate requirement levels, RFC 2119, S. Bradner, March 1997. Available at: http://www.rfc-editor.org/rfc/rfc2119.txt.

6.3. Acknowledgments

This section is informative.

The following people contributed to the development of this document.

6.3.1. Participants in the PFWG at the time of publication

  • Jim Allan (Invited Expert, Texas School for the Blind)
  • David Bolter (Invited Expert, University of Toronto Adaptive Technology Resource Centre)
  • Sally Cain (Royal National Institute of Blind People)
  • Ben Caldwell (Invited Expert, Trace)
  • Charles Chen (Google, Inc.)
  • Michael Cooper (W3C/MIT)
  • James Craig (Apple, Inc.)
  • Dimitar Denev (Frauenhofer Gesellschaft)
  • Steve Faulkner (Invited Expert, The Paciello Group)
  • Kentarou Fukuda (IBM Corporation)
  • Andres Gonzalez (Adobe Systems Inc.)
  • Georgios Grigoriadis (SAP AG)
  • Jon Gunderson (Invited Expert, UIUC)
  • Sean Hayes (Microsoft Corporation)
  • John Hrvatin (Microsoft Corporation)
  • Kenny Johar (Vision Australia)
  • Masahiko Kaneko (Microsoft Corporation)
  • Diego La Monica (International Webmasters Association / HTML Writers Guild (IWA-HWG))
  • William Loughborough (Invited Expert)
  • Anders Markussen (Opera Software)
  • Matthew May (Adobe Systems Inc.)
  • Charles McCathieNevile (Opera Software)
  • James Nurthen (Oracle Corporation)
  • Joshue O'Connor (Invited Expert)
  • Lisa Pappas (Society for Technical Communication (STC))
  • Simon Pieters (Opera Software)
  • David Poehlman (Invited Expert)
  • T.V. Raman (Google, Inc.)
  • Gregory Rosmaita (Invited Expert)
  • Tony Ross (Microsoft Corporation)
  • Janina Sajka (Invited Expert, The Linux Foundation)
  • Martin Schaus (SAP AG)
  • Joseph Scheuhammer (Invited Expert, University of Toronto Adaptive Technology Resource Centre)
  • Stefan Schnabel (SAP AG)
  • Richard Schwerdtfeger (IBM Corporation)
  • Lisa Seeman (Invited Expert, Aqueous)
  • Cynthia Shelly (Microsoft Corporation)
  • Marc Silbey (Microsoft Corporation)
  • Andi Snow-Weaver (IBM Corporation)
  • Henny Swan (Opera Software)
  • Gottfried Zimmermann (Invited Expert, Access Technologies Group)

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

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), Dave Pawson (RNIB), Henri Sivonen (Mozilla), Vitaly Sourikov, Mike Squillace (IBM), Ryan Williams (Oracle), Tom Wlodkowski.

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