WAI-ARIA User Agent Implementation Guide 1.0

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 throughout the lifecycle of the application. The screen reader or other assistive technology uses the semantic information exposed via the accessibility API to provide an alternative 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:

• Microsoft Active Accessibility (MSAA)
• IAccessible2
• User Interface Automation (UIA)
• Linux Accessibility Toolkit (ATK) and Assistive Technology - Service Provider Interface (AT-SPI)
• Mac OS X Accessibility Protocol

If User Agent developers need to expose to other accessibility APIs, it is recommended that they work closely with the developer of the platform where the API runs, and assistive technology developers on that platform.

1.2. The Accessible Tree and the DOM Tree

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.

3.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 is not 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 HTML Element that supports the tabindex attribute 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 events 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.

Note: Over time, user agents have provided differing implementations and levels of support for the tabindex attribute. Examples include: the Gecko documentation on Key-navigable custom DHTML widgets; the documentation for Internet Explorer's's tabindex behavior in MSDN: tabindex Property, and Opera simple testcases. The HTML 5 spec documents what the extended behavior of tabindex should be ([HTML5]) and user agent implementations.

3.2. Controlling focus with aria-activedescendant

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

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

• If the would-be-focused element can take real DOM focus, the user agent MUST set the DOM focus to it.
• Otherwise, if the current element has an ID and an ancestor with the aria-activedescendant attribute present, the user agent MUST set DOM focus to that ancestor. If successful, then set aria-activedescendant on the ancestor to the ID of the current element.

4.1. General rules for exposing WAI-ARIA semantics

Where supported by the platform Accessibility API, 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.

User agents MUST provide an accessible object corresponding to DOM elements that meet any of the following criteria in the accessible tree:

• is a text element
• may fire an accessible event
• has a WAI-ARIA property, relationship or feature which needs to be exposed
• is focusable, or has an ID attribute and an ancestor with the aria-activedescendant attribute that matches the implicit or explicit semantics of the required context role. In either case it may receive focus and need to fire a focus event.
• has a role attribute but does not contain the presentation role before any other mappable role (see Role Mapping below). If the presentation role is used, the element must still be exposed if it is focusable, so that focus events can be fired (focus must never be lost).
• has one of the WAI-ARIA global states and properties but does not have the aria-hidden property set to "true". Hidden elements are not exposed to assistive technology.
• has an ID which is referenced by another element via a WAI-ARIA relation (aria-controls, aria-describedby, aria-flowto, aria-labelledby or aria-owns) and does not have a role of presentation directly or inherited from an owner element.
• has a role attribute but does not inherit a role of presentation from an owning element. If the presentation role is computed, the element must still be exposed if it is focusable, so that focus events can be fired (focus must never be lost).

The following elements are not exposed via the accessibility API and user agents SHOULD NOT include them in the accessible tree:

• elements with role="presentation". In the case of structural container elements that have "presentation", such as HTML tables or lists, child elements that are required owned elements of the container inherit the presentation role and SHOULD NOT be included in the accessible tree unless they meet one of the above criteria. Note that the contents of presentational tables are DOM text elements, not child structural elements and MUST always be included in the accessible tree.
• children of the following objects, which have the characteristic "Children Presentational: True":
  • button
  • img
  • math
  • progressbar
  • separator
  • slider

User agents MUST notify assistive technology of state changes but SHOULD only notify assistive technology of property changes if the accessibility API defines a change event for the property. For example, IAccessible2 defines an event to be used when aria-activedescendant changes.

4.2. Conflicts between native markup semantics and WAI-ARIA

WAI-ARIA is generally used on elements that have no native semantics of their own with respect to user interface objects. WAI-ARIA is meant to extend the semantics of native host language elements when the desired element is modified to create a new UI object but has insufficient semantics to meet the intent of the author. At times, WAI-ARIA 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 re-purposed 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. To achieve this the following rules MUST be followed:

• 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 re-purposed.

It should be noted that while the user agent overrides the native semantics with the WAI-ARIA semantics, host languages may define some combinations of WAI-ARIA and native semantics as invalid, and validators for those languages may flag such uses as coding errors or warnings.

4.3. Exposing attributes that do not directly map to accessibility API properties

Platform accessibility APIs may have features that are not in WAI-ARIA. Likewise, WAI-ARIA exposes capabilities that are not supported by accessibility APIs at the time of publication. 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 do not 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.

In UIA, use the AriaRole and AriaProperties properties.

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.

4.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 are 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 MUST also be available for parsing:

1. The first token in the sequence of tokens in the role attribute value which matches, on case-sensitive comparison, the name of any non-abstract WAI-ARIA role 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. When a matching role is found, user agents MUST use it to override any implicit role inferred from the host language markup in performing this mapping. Note that this overriding does not result in any changes in the DOM, only in the accessibility API representation of the document.

   The following steps will correctly identify the applicable WAI-ARIA role:

   1. Use the rules of the host language to detect that an element has an attribute with attribute name of role and to identify the attribute value string for that attribute.
   2. Separate the attribute value string for that attribute into a sequence of whitespace-free substrings by separating on whitespace.
   3. Do a case-sensitive comparison of the substrings to all the names of the non-abstract WAI-ARIA roles.
   4. Use the first such substring in textual order that matches the name of a non-abstract WAI-ARIA role for the API role mapping.
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:
   • composite
   • input
   • landmark
   • range
   • roletype
   • section
   • sectionhead
   • select
   • widget
   • structure
   • widget
   • window
3. If the element does not have a role attribute, or if the role attribute contains no tokens matching the name of a non-abstract WAI-ARIA role, the user agent MUST 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 MUST be exposed as a text string if the API supports it. This allows assistive technologies to do their own additional processing of roles.
   • Microsoft Active Accessibility:
   • IAccessible2: expose as an object attribute pair (role=string)
   • User Interface Automation: expose as AriaRole property. The AriaRole property can also support secondary roles using a space as a separator.
   • Accessibility Toolkit: expose as an object attribute pair (role=string)
   • Apple:
5. Platform accessibility APIs typically do not provide a vehicle to notify assistive technologies that a role has changed. Due to this and document caching, assistive technologies are unlikely to process a change in role attribute value. Authors who wish to change a role are advised by the WAI-ARIA specification to delete the associated element and its children and replace it with a new element having the appropriate role. If a role is changed, however, user agents SHOULD update the mapping in order to reflect the content in the DOM. Since assistive technologies will not know that the role has changed, a user agents MAY address this error condition by treating it as removing a subtree item and inserting a new one as described in Changes to document content or node visibility.

4.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 states that are managed by the user agent 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. Some WAI-ARIA properties are not global, and are only supported on certain roles. If a non-global WAI-ARIA state or property is used where it is not supported, user agents SHOULD act as if the WAI-ARIA state or property is absent, and not not map the given WAI-ARIA property to the platform accessibility API. For example, aria-checked should not be exposed as CHECKED on <div role="grid">
8. 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.

4.6. Special Processing Requiring Additional Computation

4.7. Actions

Actions are exposed by the following rules

• the element is focusable
• the element has registered a click event handler
• the element is xlink
• the element has a WAI-ARIA role allowing action (see the following table)
• the element has a WAI-ARIA state or property that enables additional actions

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.

4.8. Events

User agents must fire events for user actions, WAI-ARIA, state changes, changes to document content or node visibility, changes in selection and operation of menus. User agents SHOULD not fire events for property changes unless the accessibility API defines an event for the particular property change.

5.1. Documents, Handling frame and iframe elements

Computing the accessible name for an outer document accessible:

• Accessibility properties for the outer document accessible are exposed as they normally are for an element.

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 does not 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 concatenated. If the outer document accessible sets a relation, that is used instead of anything set on the inner document's root WAI-ARIA node.

5.2. CSS Selectors

Support for attribute selectors MUST include WAI-ARIA attributes. For example, .fooMenuItem['aria-haspop=true'] would 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.3. Author Errors

In general, user agents 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. User agents 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, user agents do not verify that an element with a role of checkbox actually behaves like a checkbox.
4. Elements that do not correctly observe required child / parent role relationships or that appear elsewhere than in their required parent.
5. Determining whether aria-activedescendant actually points to a descendant or not.

If the author specifies a non-numeric value for a decimal or integer value type, the user agent SHOULD do the following:

• When asked for the string version of the property, return the string if specified by the author.
• When asked for the decimal version, return a default value of 0.0 for decimal value types and 0 for integer value types.

If a WAI-ARIA property contains an unknown or disallowed value, expose to platform accessibility APIs as follows:

• When exposing as an object attribute, expose the unknown value—do not vet it against possible values.
• When exposing as a platform API Boolean state, treat "", "undefined" or no attribute present as false. Treat any other value as true.
• Otherwise, ignore the value and treat the property as not present
• In UIA, the user agent MAY leave the corresponding property set to "unsupported."

If a required aria property for a given role is missing, supply a default value as follows:

Most errors that occur due to WAI-ARIA are not propagated to callers. For example, finding an invalid ID in an ID reference List 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.1. Glossary

This section is normative.

Accessibility API

Operating systems and other platforms provide a set of interfaces that expose information about objects and events to assistive technologies. Assistive technologies use these interfaces to get information about and interact with those widgets.

Accessible object

An visible user interface object whose basic accessibility is exposed to assistive technology.

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.

Assistive Technologies

Hardware and/or software that acts as a user agent, or along with a mainstream user agent, to meet the interface requirements of users with disabilities beyond those offered by the mainstream user agents.

Services provided by assistive technologies include alternative presentations (e.g., synthesized speech or magnified content), alternative input methods (e.g., speech recognition), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible).

Assistive technologies often communicate with mainstream user agents by using and monitoring accessibility APIs.

The distinction between mainstream user agents and assistive technologies is not absolute. Many mainstream user agents provide some features to assist individuals with disabilities. The basic difference is that mainstream user agents target broad and diverse audiences that usually include people with and without disabilities, assistive technologies target users with specific disabilities. The assistance provided by assistive technologies is more specific and appropriate to the needs of its target users.

Examples of assistive technologies that is important in the context of this document include the following:

• screen magnifiers, which are used to to enlarge and improve the visual readability of rendered text and images;
• screen readers, which are most-often used to convey information through synthesized speech, sound iconography, or Braille;
• text-to-speech software, which is used to convert text into synthetic speech;
• speech recognition software, which is used to allow spoken control and dictation;
• alternate keyboards (including head pointers, single switches, and sip/puff devices), which are used to simulate the keyboard;
• alternate pointing devices, which are used to simulate mouse pointing and clicking.

Attribute

In this specification, attribute is used as it is in markup languages. Attributes are structural features added to elements to provide information about the states and properties of the object represented by the element.

Class

An abstract type of object.

Current node

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

Current total text

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

Element

In this specification, element is used as it is in markup languages. Elements are the structural elements in markup language that contains the data profile for objects.

Event

A programmatic message used to communicate discrete changes in the state of an object to other objects in a computational system. User input to a web page is commonly mediated through abstract events that describe the interaction and can provide notice of changes to the state of a document object. In some programming languages, events are more commonly known as notifications.

Hidden

Indicates that the element is not visible or perceivable to any user.

Informative

Content provided for information purposes and not required for conformance. Content required for conformance is referred to as normative.

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.

Normative

Required for conformance. By contrast, content identified as informative or "non-normative" is not required for conformance.

Object

A "thing" in the perceptual user experience, instantiated in markup languages by one or more elements, and converted into the object-oriented pattern by user agents. Objects are instances of classes, which define the general characteristics of object instances. A single DOM object may or may not correspond with a single object in an accessibility API. An object in an accessibility API may encapsulate one or more DOM objects.

Outer document accessible

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

Perceivable

Presentable to users in ways they can sense. References in this document relate to WCAG 2 Principle 1; content must be perceivable [WCAG20].

Property

Attributes that are essential to the nature of a given object. As such, they are less likely to change than states; a change of a property may significantly impact the meaning or presentation of an object. Properties mainly provide limitations on objects from the most general case implied by roles without properties applied.

Role

An indicator of type. The object's role is the class of objects of which it is a member. This semantic association allows tools to present and support interaction with the object in a manner that is consistent with user expectations about other objects of that type.

Root WAI-ARIA node

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

Semantics

The meaning of something as understood by a human, defined in a way that computers can process a representation of an object, such as elements and attributes, and reliably represent the object in a way that various humans will achieve a mutually consistent understanding of the object.

State

A state is a dynamic property expressing characteristics of an object that may change in response to user action or automated processes. States do not affect the essential nature of the object, but represent data associated with the object or user interaction possibilities.

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.

User Agent

Any software that retrieves and renders web content for users, such as web browsers, media players, plug-ins, and other programs including assistive technologies.

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.

Widget

Discrete user interface object with which the user can interact. Widgets range from simple objects that have one value or operation (e.g., check boxes and menu items), to complex objects that contain many managed sub-objects (e.g., trees and grids).

[ARIA]

Accessible Rich Internet Applications (WAI-ARIA) Version 1.0. L. Seeman, M. Cooper, R. Schwerdtfeger, L. Pappas, Editors, W3C Working Draft (work in progress), 15 December 2009. This version of WAI-ARIA is available at http://www.w3.org/TR/2009/WD-wai-aria-20091215/. Latest version of WAI-ARIA available at http://www.w3.org/TR/wai-aria/.

[ARIA-PRACTICES]

WAI-ARIA Authoring Practices. L. Pappas, R. Schwerdtfeger, M. Cooper, Editors, W3C Working Draft (work in progress), 15 December 2009. This version of WAI-ARIA Authoring Practices is available at http://www.w3.org/TR/2009/WD-wai-aria-practices-20091215/. 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/.

[HTML5]

HTML 5, I. Hickson, D. Hyatt, Editors, W3C Working Draft (work in progress), 25 August 2009, http://www.w3.org/TR/2009/WD-html5-20090825/. Latest version of HTML 5 available at http://www.w3.org/TR/html5/.

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

[WCAG20]

Web Content Accessibility Guidelines 2.0, B. Caldwell, G. Vanderheiden, L. Guarino Reid, M. Cooper, Editors, W3C Working Draft (work in progress), 11 December 2007, http://www.w3.org/TR/2007/WD-WCAG20-20071211/. Latest version of WCAG 2.0 available at http://www.w3.org/TR/WCAG20/.

6.3. Acknowledgments

The following people contributed to the development of this document.