This document describes how user agents should expose semantics of web content languages to accessibility APIs. This helps users with disabilities to obtain and interact with information using assistive technologies. Documenting these mappings promotes interoperable exposure of
roles, states, properties, and events implemented by accessibility APIs and helps to ensure that this information appears in a manner consistent with author intent.
This Core Accessibility API Mappings specification defines support that applies across multiple content technologies, including general keyboard navigation support and mapping of
general-purpose roles, states, and properties provided in Web content via
WAI-ARIA
[WAI-ARIA-1.2]. Other Accessibility API Mappings specifications depend on and extend this Core specification for specific technologies, including native technology features and WAI-ARIA
extensions. This document updates and will eventually supersede the guidance in the Core Accessibility API Mappings 1.1 [CORE-AAM-1.1] W3C
Recommendation. It 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. A list of current W3C
publications and the latest revision of this technical report can be found
in the W3C technical reports index at
https://www.w3.org/TR/.
Publication as an Editor's Draft does not
imply endorsement by W3C and its Members.
This is a draft document and may be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to cite this document as other
than work in progress.
This document was produced by a group
operating under the
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 Core Accessibility API Mappings specifies how WAI-ARIA roles, states, and
properties are expected to be exposed by user agents via platform accessibility APIs. It is part of a set of resources that
define and support the WAI-ARIA specification which includes the following documents:
WAI-ARIA Authoring Practices Guide
[WAI-ARIA-PRACTICES-1.2], describes how web content developers can develop accessible rich internet applications using WAI-ARIA.
It provides detailed advice and examples directed primarily to web application developers, yet also useful to user agent and developers of assistive technologies.
Accessibility APIs make it possible to communicate accessibility information about user interfaces to assistive
technologies. This information includes:
If user agent developers need to expose information using 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 Comparing Accessibility APIs
For various technological and historical reasons, accessibility APIs do not all work in the same way. In many cases, there is no simple one-to-one relationship between how each of them names
or exposes roles, states, and properties to assistive technologies. The following subsections describe a few of the distinguishing characteristics of some of the APIs.
1.2.1 ATK/AT-SPI
MSAA, IAccessible2, UIA, and AX API each define an API that is shared by both the software application exposing information about its content and interactive components, and the assistive
technology consuming that information. Conversely, Linux/GNOME separates that shared interface into its two aspects, each represented by a different accessibility API: ATK or AT-SPI.
ATK defines an interface that is implemented by software in order to expose accessibility information, whereas AT-SPI is a desktop service that gathers accessibility information from
active applications and relays it to other interested applications, usually assistive technologies.
For example, the GNOME GUI toolkit [GTK], implements the relevant aspects of ATK for each widget (menu, combobox, checkbox, etc.) in order that GTK widgets expose accessibility information
about themselves. AT-SPI then acquires the information from applications built with GTK and makes it available to interested parties.
ATK is most relevant to implementors, whereas AT-SPI is relevant to consumers. In the context of mapping WAI-ARIA roles, states and properties, user agents are implementors and use ATK.
Assistive Technologies are consumers, and use AT-SPI.
1.2.2 UIA (UI Automation)
UI Automation expresses every element of the application user interface as an automation element. Automation elements form the nodes of the application accessibility tree, that can be
queried, traversed and interacted with by automation clients.
There are several concepts central to UI Automation:
Automation element - controls and some application content are presented as automation elements.
Element properties - Automation elements have several common properties describing native framework element characteristics in an agnostic way that all automation clients can understand.
There are several ways to access element property values, described below.
Control Patterns - Some common interactivity in different frameworks is expressed as control patterns in UIA, allowing different automation clients to interact with controls using common
programmatic interfaces.
Events - Similar to other accessibility APIs, automation elements support various events that allow automation providers to notify clients on important state changes.
All automation elements inherit from the IUIAutomationElement interface and all properties that are not specific to a particular control pattern can be queried through that
interface. There are several ways to access UI Automation element properties:
Direct property accessors to the current values - Current{PropertyName}, e.g. IUIAutomationElement::CurrentName for the Name property
Cached property accessors - Cached{PropertyName}, e.g. IUIAutomationElement::CachedName for the Name property. Using cached values is preferred
when providers and clients are used in remote environments.
GetCurrentPropertyValue and passing the UIA Property ID enumeration value corresponding to that property to get the current value, e.g.
IUIAutomationElement::GetCurrentPropertyValue(UIA_NamePropertyId) for the Name property.
GetCachedPropertyValue and passing the UIA Property ID enumeration value corresponding to that property to get the cached value, e.g.
IUIAutomationElement::GetCachedPropertyValue(UIA_NamePropertyId) for the Name property.
Properties for specific UIA control patterns are queried the same way using relevant control pattern interfaces. Taking Toggle Pattern as an example, to query the ToggleState property
clients can use IUIAutomationTogglePattern::CurrentToggleState or IUIAutomationTogglePattern::GetCurrentPropertyValue(UIA_ToggleToggleStatePropertyId) to get the current value.
The property mappings in this specification provide the {PropertyName} and do not specify all specific ways to access the property value. Automation clients can access current
or cached values using conventions described above, depending on specific needs and coding style conventions.
For instance, in MSAA, all accessible objects support the accName property, which stores the object's
accessible name. Where the object also supports having an
accessible description, MSAA stores this property in the object's accDescription property.
Software using ATK can read and write to an object's accessible-name and accessible-description properties. In turn, AT-SPI can query the values of those
properties through its atspi_accessible_get_name and atspi_accessible_get_description functions.
Automation elements in the UIA accessibility tree have a Name property. Where the object also supports having an
accessible description, UIA stores this property in the object's FullDescription property.
The approach to accessible names and
accessible descriptions in AX API is somewhat different to the other platform
APIs. Accessible names are exposed using the AXTitle property when the name is visually rendered, while the
AXDescription property is used when the object's name is not rendered visually. An object's
accessible description, where provided by
aria-description or aria-describedby, should be exposed in the accessibilityCustomContent API. Otherwise, it should be exposed as AXHelp.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, SHOULD, and SHOULD NOT in this document
are to be interpreted as described in
BCP 14
[RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
2.1 RFC-2119 Keywords
RFC-2119 keywords are formatted in uppercase and contained in a strong element with class="rfc2119". When the keywords shown above are used, but do not share this
format, they do not convey formal information in the RFC 2119 sense, and are merely explanatory, i.e., informative. As much as possible, such usages are avoided in this specification.
2.2 Normative and Informative Sections
The indication whether a section is normative or non-normative (informative) applies to the entire section including sub-sections.
Informative sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow such
recommendations in order to conform to this specification.
2.3 Features Deprecated in WAI-ARIA
The WAI-ARIA specification lists some features as deprecated. Although this means authors are encouraged not to use such features, it is expected
that the features could still be used in legacy content. Therefore, it is important that user agents continue to map these features to accessibility APIs, and doing so is part of conformance
to this specification. When future versions of the WAI-ARIA specification change such features from deprecated to removed, they will be removed from the mappings as well and user agents will
no longer be asked to continue support for those features.
3. Important Terms
This section is non-normative.
While some terms are defined in place, the following definitions are used throughout this document.
Accessibility Subtree
An accessible object in the accessibility tree and its descendants in that tree. It does not include objects which have relationships other than parent-child in that tree. For
example, it does not include objects linked via aria-flowto unless those objects are also descendants in the accessibility tree.
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.
4. Mapping WAI-ARIA to Accessibility APIs
4.1 General rules for exposing WAI-ARIA semantics
Where supported by the platform Accessibility API, user agents expose WAI-ARIA
semantics 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.
With respect to WAI-ARIA 1.0 and 1.1, accessibility APIs operate in one
direction only. User agents publish WAI-ARIA information (roles, states, and properties) via an accessibility
API, and an AT can acquire that information using the same
API. However, the other direction is not supported. WAI-ARIA 1.0 and 1.1 do
not define mechanisms for assistive technologies to directly modify WAI-ARIA information.
4.2 Conflicts between native markup semantics and WAI-ARIA
WAI-ARIA roles, states, and properties are intended to add semantic information when native host language
elements with these semantics are not available, and are generally used on elements that have no native semantics of their own. They can also be used on elements that
have similar but not identical semantics to the intended object (for instance, a nested list could be used to represent a tree structure). This method can be part of a fallback strategy for
older browsers that have no WAI-ARIA implementation, or because native presentation of the repurposed element reduces the amount of
style and/or script needed. Except for the cases outlined below, user agentsMUST always use the WAI-ARIA semantics to define
how it exposes the element to accessibility APIs, rather than using the host language semantics.
Host languages can have features that have implicit WAI-ARIA semantics corresponding to roles. When a
WAI-ARIA role is provided that has a corresponding role in the accessibility
API, user agents MUST use the semantic of the WAI-ARIA role for processing,
not the native semantic, unless the role requires WAI-ARIA states and properties whose attributes are explicitly forbidden on the
native element by the host language. Values for roles do not conflict in the same way as values for states and properties, and because authors are expected to have a valid reason to provide
a WAI-ARIA role even on elements that would not normally be repurposed. For example, spin buttons are typically constructed from
text fields (<input type="text">) in order to get most of the default keyboard support. But, the native role, "text field", is not correct because it
does not properly communicate the additional features of a spin button. The author adds the WAI-ARIA role of
spinbutton (<input type="text" role="spinbutton" ...>) so that the control is properly mapped in the accessibility
API. When a WAI-ARIA role is provided that does not have a corresponding role
in the accessibility API, user agents MAY expose the native semantic in addition to the
WAI-ARIA role. If the host language element is overridden by a
WAI-ARIA role whose semantics or structure is not equivalent to the native host language semantics or to a subclass of those
semantics, then treat any child elements having roles specified as Allowed Accessibility Child Roles as having presentation or
none.
Note
The above text differs slightly from the WAI-ARIA specification. The requirement for user agents to expose the
WAI-ARIA role instead of the native role was intended to only apply in cases where there is a direct mapping from the
WAI-ARIA role to a corresponding role in the accessibility API. The wording
of the requirement is not clear in the WAI-ARIA specification, however, and has been interpreted differently by implementers. The
requirement has been clarified here and an additional statement added to indicate that user agents may expose native semantics if there is not a direct mapping to a role in the accessibility
API. Because there are differing implementations, authors will be advised against adding such
WAI-ARIA roles to native elements that have their own semantics in the
WAI-ARIA Authoring Practices Guide.
When WAI-ARIA states and properties correspond to host language features that have the same implicit
WAI-ARIA semantic, it can be problematic if the values become out of sync. For example, the
HTML checked attribute and the aria-checked attribute could have conflicting values. Therefore to prevent providing
conflicting states and properties to assistive technologies, host languages will explicitly declare where the use of
WAI-ARIA attributes on a host language element conflict with native attributes for that element. When a host language declares a
WAI-ARIA attribute to be in direct semantic conflict with a native attribute for a given element, user
agents MUST ignore the WAI-ARIA attribute and instead use the host language attribute with the same implicit semantic.
Host languages might also document features that cannot be overridden with WAI-ARIA (these are called "strong native
semantics"). These can be features that have implicit WAI-ARIA semantics as well as features where the processing would be
uncertain if the semantics were changed with WAI-ARIA. While conformance checkers might signal an error or warning when a
WAI-ARIA role is used on elements with strong native semantics, user agents MUST still use the value of the semantic of the
WAI-ARIA role when exposing the element to accessibility APIs.
4.3 Exposing attributes that do not directly map to accessibility API properties
Platform accessibility APIs might 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 mechanism in the API to expose the
WAI-ARIA role, states, and properties and their values, user agentsMUST expose the
WAI-ARIA data using that mechanism as follows:
In IAccessible2 and ATK/AT-SPI, 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 where there is no specific interface in an accessibility API. 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 are in State and Property Mapping.
In Microsoft UIA, use the AriaRole and AriaProperties properties to expose semantics that are not directly
supported in the control type.
Note
MSAA does not provide a mechanism for exposing attributes that do not map directly to the API and among implementers, there is no
agreement on how to do it.
User agents MUST also expose the entire role string through this mechanism and MAY also expose WAI-ARIA attributes and values
through this mechanism even when there is a direct mapping to an accessibility API.
Browser implementers are advised to publicly document their API methods for exposing any relevant information, so that
assistive technology developers can use the API to support user features.
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.
4.4.1 General rules
User agents MUST expose the WAI-ARIA role string if the API supports a
mechanism to do so. This allows assistive technologies to do their own additional processing of roles.
MSAA:
not supported. User agents SHOULD NOT expose a custom role in
MSAA's accRole property.
IAccessible2: expose as an object attribute pair (xml-roles:"string")
UIA: expose as AriaRole property. The AriaRole property can also support secondary roles using a space as a
separator.
ATK/AT-SPI: expose as an object attribute pair
(xml-roles:"string")
4.4.2 Computed Role
The computedrole of an element is a string that represents the role of the element as computed by the browser engine. The computedrole is used primarily for the purposes of developer
tools and specification comformance and interoperability testing.
When an element has a role but is not contained in the required context (for example, an orphaned listitem without the required accessible parent of role list), User Agents MUST ignore
the role token, and return the computedrole as if the ignored role token had not been included.
When host language elements do not have an exact or equivalent mapping to a valid, non-abstract role, the related Accessibilty API Mapping extension specification MAY specify a unique
computedrole string as the return value for interoperability testing purposes, such as <video> -> "html-video" in [HTML-AAM]. However, authors MUST NOT use any
host-language-prefixed computedrole string in the role attribute (such as html-video), unless the token also matches valid, defined role (such as dpub-chapter). User Agents MUST
ignore any abstract or invalid role token.
AXRole: AXGroup AXSubrole: AXDeleteStyleGroup AXAttributedStringForTextMarkerRange: contains AXIsSuggestedDeletion = 1; for all text contained in a deletion
Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents MUST return
false for all Selection methods that provide a means to modify the selection.
AXRole: AXTable AXSubrole: <nil> AXColumnHeaderUIElements: a list of pointers to the columnheader elements AXHeader: a pointer to the row or group containing those columnheader elements AXRowHeaderUIElements: a list of pointers to the rowheader elements
Control Type: DataItem Localized Control Type: item Control Pattern: SelectionItem Control Pattern: GridItem Control Pattern: TableItem SelectionItem.SelectionContainer: the containing grid
AXRole: AXGroup AXSubrole: AXInsertStyleGroup AXAttributedStringForTextMarkerRange: contains AXIsSuggestedInsertion = 1; for all text contained in a insertion
Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents MUST return
false for all Selection methods that provide a means to modify the selection.
Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents MUST return
false for all Selection methods that provide a means to modify the selection.
Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents MUST return
false for all Selection methods that provide a means to modify the selection.
Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents MUST return
false for all Selection methods that provide a means to modify the selection.
For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the
accessibility tree, expose it as IA2_ROLE_TEXT_FRAME. user agentsSHOULD prune empty descendants from the
accessibility tree.
UIA
For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the
accessibility tree, expose it using the text pattern. user agentsSHOULD prune empty descendants from the
accessibility tree.
ATK/AT-SPI
For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the
accessibility tree, expose it as ROLE_SECTION. user agentsSHOULD prune empty descendants from the
accessibility tree.
For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the
accessibility tree, expose it as AXGroup. user agentsSHOULD prune empty descendants from the accessibility tree.
For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the
accessibility tree, expose it as IA2_ROLE_TEXT_FRAME. user agentsSHOULD prune empty descendants from the
accessibility tree.
UIA
For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the
accessibility tree, expose it using the text pattern. user agentsSHOULD prune empty descendants from the
accessibility tree.
ATK/AT-SPI
For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the
accessibility tree, expose it as ROLE_SECTION. user agentsSHOULD prune empty descendants from the
accessibility tree.
For objects that have specified allowed accessibility children (e.g., a grid with gridcell children, a list with listitem children), and the descendant is in the
accessibility tree, expose it as AXGroup. user agentsSHOULD prune empty descendants from the accessibility tree.
Control Type: ProgressBar Control Pattern: RangeValue if aria-valuenow, aria-valuemax, or aria-valuemin is present
ATK/AT-SPI
Role: ROLE_PROGRESS_BAR Interface: Value
Because WAI-ARIA does not support modifying the value via the accessibility API, user agents MUST return
false for all Value methods that provide a means to modify the value.
Control Type: ScrollBar Control Pattern: RangeValue
ATK/AT-SPI
Role: ROLE_SCROLL_BAR Interface: Value
Because WAI-ARIA does not support modifying the value via the accessibility API, user agents MUST return
false for all Value methods that provide a means to modify the value.
Because WAI-ARIA does not support modifying the value via the accessibility API, user agents MUST return
false for all Value methods that provide a means to modify the value.
Because WAI-ARIA does not support modifying the value via the accessibility API, user agents MUST return
false for all Value methods that provide a means to modify the value.
Because WAI-ARIA does not support modifying the value via the accessibility API, user agents MUST return
false for all Value methods that provide a means to modify the value.
Role: ROLE_SYSTEM_CHECKBUTTON Role: IA2_ROLE_TOGGLE_BUTTON Object Attribute: xml-roles:switch See also: aria-checked in the State and Property Mapping Tables
UIA
Control Type: Button Localized Control Type: toggleswitch Control Pattern: Toggle See also: aria-checked in the State and Property Mapping Tables
AXRole: AXTable AXSubrole: <nil> AXColumnHeaderUIElements: a list of pointers to the columnheader elements AXHeader: a pointer to the row or group containing those columnheader elements AXRowHeaderUIElements: a list of pointers to the rowheader elements
Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents MUST return
false for all Selection methods that provide a means to modify the selection.
Control Type: Text Localized Control Type: time Note: create a separate UIA Control of type Text. This is different from most UIA text mappings, which only create ranges in the page text pattern.
Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents MUST return
false for all Selection methods that provide a means to modify the selection.
Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents MUST return
false for all Selection methods that provide a means to modify the selection.
[Note 1]
User agent should return a user-presentable, localized string value for the AXRoleDescription.
Note
[Note 2] This specification does not currently contain guidance for when user agents should fire system alert events. Some guidance may be added to the specification at a
later date but it will be a recommendation (SHOULD), not a requirement (MUST).
4.5 State and Property Mapping
This section describes how to expose WAI-ARIA states and properties.
4.5.1 General rules
User agentsMUST compute managed statesVISIBLE/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.
User agents MUST continue to expose native semantics in addition to WAI-ARIA state and property semantics except where an
explicit WAI-ARIA override is allowed by the host language. For example, an HTML checkbox may have an
aria-labelledby attribute but the native HTML semantics must still
be exposed.
User agents MUST expose additional states for certain roles as defined in the Role Mapping Tables.
User agents MUST compute states for the relevant WAI-ARIA attributes and map to the
accessibility API as specified in the State and Property Mapping Tables. To determine the relevant
WAI-ARIA attributes, refer to the
Definition of Roles [WAI-ARIA-1.2]]. Where the author has not provided values for required attributes, user agents SHOULD
process as if the default value was provided.
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 NOT map the given
WAI-ARIA property to the platform accessibility API. For example, if
aria-checked="true" is specified on <div role="grid">, it should not be exposed in
MSAA implementations as STATE_SYSTEM_CHECKED.
There are a number of occurrences in the table where a given state or property is declared "Not mapped". In some cases, this occurs for the default value of the state/property, and is
equivalent to its absence. User agents might find it quicker to map the value than check to see if it is the default. For computational efficiency, user agents MAY expose the state or
property value if doing so is equivalent to not mapping it. These cases are marked with an asterisk.
In other cases, it is mandatory that the state/property not be mapped, since exposing it implies a related affordance. An example is
aria-grabbed. Its absence not only indicates that the accessible object is not grabbed, but further defines it as not grab-able. These cases are marked as "Not mapped" without an asterisk.
Object Attribute: atomic:true Object Attribute: container-atomic:true Object Attribute: container-atomic:true on all descendants Relation: IA2_RELATION_MEMBER_OF pointing to this element (the atomic root) See also: Changes to document content or node visibility
Object Attribute: atomic:true Object Attribute: container-atomic:true Object Attribute: container-atomic:true on all descendants Relation: RELATION_MEMBER_OF pointing to this element (the atomic root) See also: Changes to document content or node visibility
Not mapped*, but if mapped: Object Attribute: atomic:false Object Attribute: container-atomic:false Object Attribute: container-atomic:false on all descendants Relation: IA2_RELATION_MEMBER_OF pointing to this element (the atomic root) See also: Changes to document content or node visibility
Not mapped*, but if mapped: Object Attribute: atomic:false Object Attribute: container-atomic:false Object Attribute: container-atomic:false on all descendants Relation: RELATION_MEMBER_OF pointing to this element (the atomic root) See also: Changes to document content or node visibility
Object Attribute: colindex:<value> Method: IAccessible2::groupPosition(): positionInGroup=<value> on cells and headers
UIA
Property: GridItem.Column: <value> (zero-based)
ATK/AT-SPI
Object Attribute: colindex should contain the author-provided value. Method: atk_table_cell_get_position() should return the actual (zero-based) column index.
Relation: IA2_RELATION_CONTROLLER_FOR points to accessible nodes matching IDREFs Reverse Relation: IA2_RELATION_CONTROLLED_BY points to element See also: Mapping Additional Relations
UIA
Property: ControllerFor: pointers to accessible nodes matching IDREFs
ATK/AT-SPI
Relation: RELATION_CONTROLLER_FOR points to accessible nodes matching IDREFs Reverse Relation: RELATION_CONTROLLED_BY points to element See also: Mapping Additional Relations
AX API
Property: AXLinkedUIElements: pointers to accessible nodes matching IDREFs
4.5.2.21 aria-current with non-false allowed value
Property: accDescription: <value> Relation: IA2_RELATION_DESCRIBED_BY points to accessible nodes matching IDREFs, if the referenced objects are in the accessibility tree Reverse Relation: IA2_RELATION_DESCRIPTION_FOR points to element See also: Name Computation and Mapping Additional Relations
Property: Description: <value> Relation: RELATION_DESCRIBED_BY points to accessible nodes matching IDREFs, if the referenced objects are in the accessibility tree Reverse Relation: RELATION_DESCRIPTION_FOR points to element See also: Name Computation and Mapping Additional Relations
AX API
In the accessibilityCustomContent API, expose as an AXCustomContent object with { label: "description" } and `value` set to the description
string.
- See also: Name Computation
In the accessibilityCustomContent API, expose as an AXCustomContent object with { label: "description" } and `value` set to the description
string. See also: Name Computation
Relation: IA2_RELATION_DETAILS points to accessible nodes matching IDREFs, if the referenced objects are in the accessibility tree Reverse Relation: IA2_RELATION_DETAILS_FOR points to element See also: Mapping Additional Relations
UIA
Property: DescribedBy: points to accessible nodes matching IDREFs, if the referenced objects are in the accessibility tree
ATK/AT-SPI
Relation: RELATION_DETAILS points to accessible nodes matching IDREFs, if the referenced objects are in the accessibility tree Reverse Relation: RELATION_DETAILS_FOR points to element See also: Mapping Additional Relations
Relation: IA2_RELATION_ERROR points to accessible nodes matching IDREFs, if the referenced objects are in the accessibility tree Reverse Relation: IA2_RELATION_ERROR_FOR points to element See also: Mapping Additional Relations
UIA
Property: ControllerFor: pointer to the target accessible object
ATK/AT-SPI
Relation: RELATION_ERROR_MESSAGE points to accessible nodes matching IDREFs, if the referenced objects are in the accessibility tree Reverse Relation: RELATION_ERROR_FOR points to element See also: Mapping Additional Relations
AX API
Property: AXErrorMessageElements: pointers to accessible nodes matching IDREFs
Relation: IA2_RELATION_FLOW_TO points to accessible nodes matching IDREFs Reverse Relation: IA2_RELATION_FLOW_FROM points to element See also: Mapping Additional Relations
UIA
Property: FlowsTo: pointers to accessible nodes matching IDREFs
ATK/AT-SPI
Relation: RELATION_FLOWS_TO points to accessible nodes matching IDREFs Reverse Relation: RELATION_FLOWS_FROM points to element See also: Mapping Additional Relations
AX API
Property: AXLinkedUIElements: pointers to accessible nodes matching IDREFs
Property: accName: <value> Relation: IA2_RELATION_LABELLED_BY points to accessible nodes matching IDREFs, if the referenced objects are in the accessibility tree Reverse Relation: IA2_RELATION_LABEL_FOR points to element See also: Name Computation and Mapping Additional Relations
UIA
Property: Name: <value> Property: LabeledBy: points to accessible nodes matching IDREFs, if the referenced objects are in the accessibility tree See also: Name Computation
ATK/AT-SPI
Property: Name: <value> Relation: RELATION_LABELLED_BY points to accessible nodes matching IDREFs, if the referenced objects are in the accessibility tree Reverse Relation: RELATION_LABEL_FOR points to element See also: Name Computation and Mapping Additional Relations
AX API
Property: AXDescription: <value> if the value is not exposed visually Property: AXTitle: <value> if the value is exposed visually Property: AXTitleUIElement points to accessible node matching IDREF, if there is a single referenced element that is in the accessibility tree See also: Name Computation
Object Attribute: level:<value> Method: IAccessible2::groupPosition(): groupLevel=<value> on roles that support aria-posinset and aria-setsize See also: groupPosition()
UIA
Property: AriaProperties.level: <value>
ATK/AT-SPI
Object Attribute: level:<value>
AX API
Property: AXDisclosureLevel: <value> (zero-based), when used on an outline row (like a
treeitem or group)
Object Attribute: live:assertive Object Attribute: container-live:assertive Object Attribute: container-live:assertive on all descendants See also: Changes to document content or node visibility
Object Attribute: live:assertive Object Attribute: container-live:assertive Object Attribute: container-live:assertive on all descendants See also: Changes to document content or node visibility
Object Attribute: live:polite Object Attribute: container-live:polite Object Attribute: container-live:polite on all descendants See also: Changes to document content or node visibility
Object Attribute: live:polite Object Attribute: container-live:polite Object Attribute: container-live:polite on all descendants See also: Changes to document content or node visibility
Prune the accessibility tree such that the background content is no longer exposed. No specific property is set on the accessible object that corresponds to
the element with aria-modal="true". Only the tree whose root is that modal accessible object is exposed.
Grow the accessibility tree such that the background content is exposed. No specific property is set on the accessible object that corresponds to the
element with aria-modal="false".
User agents MAY expose the elements that are referenced by this property as children of the current element. In which case, if multiple
aria-owns relationships are found, use only the first one. If the accessibility tree is not modified, expose as:
Relation: IA2_RELATION_NODE_PARENT_OF points to accessible nodes matching IDREFs, if the referenced objects are in the accessibility tree Reverse Relation: IA2_RELATION_NODE_CHILD_OF points to element See also: Mapping Additional Relations
UIA
Expose the elements that are referenced by this property as children of the current element. If multiple
aria-owns relationships are found, use only the first one.
ATK/AT-SPI
User agents MAY expose the elements that are referenced by this property as children of the current element. In which case, if multiple
aria-owns relationships are found, use only the first one. If the accessibility tree is not modified, expose as:
Relation: RELATION_NODE_PARENT_OF points to accessible nodes matching IDREFs, if the referenced objects are in the accessibility tree Reverse Relation: RELATION_NODE_CHILD_OF points to element See also: Mapping Additional Relations
AX API
Property: AXOwns: pointers to accessible nodes matching IDREFs
Property: Value.IsReadOnly: true, if the element implements
IValueProvider. Property: RangeValue.IsReadOnly: true, if the element implements
IRangeValueProvider. Property: AriaProperties.readonly: true
ATK/AT-SPI
State: STATE_READ_ONLY State: STATE_EDITABLE not exposed on text input roles State: STATE_CHECKABLE not exposed on roles supporting aria-checked State: STATE_CHECKABLE not exposed on radio descendants when used on a radiogroup
AX API
Method: AXUIElementIsAttributeSettable(AXValue): NO
State: STATE_SYSTEM_READONLY not exposed State: IA2_STATE_EDITABLE
UIA
Property: Value.IsReadOnly: false, if the element implements
IValueProvider. Property: RangeValue.IsReadOnly: false, if the element implements
IRangeValueProvider. Property: AriaProperties.readonly: false
The gridcellMUST inherit any author-provided value for aria-readonly from the containing grid or treegrid. Expose the inherited
value on the gridcell as described for aria-readonly="true" and
aria-readonly="false".
UIA
The gridcellMUST inherit any author-provided value for aria-readonly from the containing grid or treegrid. Expose the inherited
value on the gridcell as described for aria-readonly="true" and
aria-readonly="false".
ATK/AT-SPI
The gridcellMUST inherit any author-provided value for aria-readonly from the containing grid or treegrid. Expose the inherited
value on the gridcell as described for aria-readonly="true" and
aria-readonly="false".
AX API
The gridcellMUST inherit any author-provided value for aria-readonly from the containing grid or treegrid. Expose the inherited
value on the gridcell as described for aria-readonly="true" and
aria-readonly="false".
Object Attribute: relevant:<value> Object Attribute: container-relevant:<value> Object Attribute: container-relevant:<value> on all descendants See also: Changes to document content or node visibility
Object Attribute: relevant:<value> Object Attribute: container-relevant:<value> Object Attribute: container-relevant:<value> on all descendants See also: Changes to document content or node visibility
Localized Control Type is defined as that specified for the role of the element: based on the explicit role if the role attribute is provided; otherwise, based on the implicit
role for the host language.
AXRoleDescription is defined as that specified for the role of the element: based on the explicit role if the role attribute is provided; otherwise, based on the implicit role for
the host language.
Object Attribute: rowindex:<value> Method: IAccessible2::groupPosition(): positionInGroup=<value> on rows
UIA
Property: GridItem.Row: <value> (zero-based)
ATK/AT-SPI
Object Attribute: rowindex should contain the author-provided value. Method: atk_table_cell_get_position() should return the actual (zero-based) row index.
A reverse relation exists when an element's ID is referenced by a property in another element. For
APIs that support reverse relations, user agentsMUST use the mapping defined in the
State and Property Mapping Tables when an element's ID is referenced by a relation property of another element and the referenced element is
in the accessibility tree. All WAI-ARIA references must point to an element that is exposed as an accessible object in the accessibility tree. When the referenced object is not exposed
in the accessibility tree (e.g. because it is hidden), the reference is null. aria-labelledby and aria-describedby have an additional feature, which
allows them to pull a flattened string from the referenced element to populate the name or description fields of the accessibility API. This feature is described in the
Name and Description section.
Special case: If both aria-labelledby and HTML
<label for= … > are used, the user agent MUST use the WAI-ARIA relation and MUST ignore the
HTML label relation.
Note that aria-describedby may reference structured or interactive information where users would want to be able
to navigate to different sections of content. User agents MAY provide a way for the user to navigate to structured information referenced by
aria-describedby and assistive technologySHOULD provide such a method.
4.6.2.2 Implied reverse relations
In addition to the explicit relations defined by WAI-ARIA properties, reverse relations are implied in two other
situations: elements with role="treeitem" where the ancestor does not have an
aria-owns property and descendants of elements with
aria-atomic property.
In the case of role="treeitem", when aria-owns is
not used, user agentsSHOULD do the following where reverse relations are supported by the API:
If the current treeitem uses aria-level, then walk backwards in the tree until a treeitem is found with a lower
aria-level, then set RELATION_NODE_CHILD_OF to that element. If the top of the tree is reached, then set RELATION_NODE_CHILD_OF to the tree element itself.
If the parent of the treeitem has a role of
group, then walk backwards from the group until an element with a role of
treeitem is found, then set RELATION_NODE_CHILD_OF to that element.
In the case of aria-atomic, where reverse relations are supported by the API:
User agents SHOULD check the chain of ancestor elements for aria-atomic="true". If found, user agents SHOULD set the RELATION_MEMBER_OF relation to point to the ancestor that sets
aria-atomic="true".
4.6.3 Group Position
aria-level, aria-posinset, and aria-setsize are all 1-based. When the property is not present or is "0", it indicates the
property is not computed or not supported. If any of these properties are specified by the author as either "0" or a negative number, user agentsSHOULD use "1"
instead.
If aria-level is not provided or inherited for an element of roletreeitem or comment, user agents implementing IAccessible2 or ATK/AT-SPI MUST compute it by
following the explicit or computed RELATION_NODE_CHILD_OF relations.
for role="treeitem" and role="comment", 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, if the role supports aria-posinset and
aria-setsize, process the parent (DOM parent or parent defined by aria-owns), counting items that have the same role.
Because these value are 1-based, include the current item in the computation. For aria-posinset, include the current item and other group items if they are before the current item in the DOM. For aria-setsize, add to that the number of items in the same group after the current item in the DOM.
If the author provides one or more of aria-setsize and aria-posinset, it is the author's responsibility to supply them for all elements in the set. User agent
correction of missing values in this case is not defined.
MSAA/IAccessible2 API mappings involve an additional function, groupPosition() [IAccessible2], when
aria-level, aria-posinset, and/or aria-setsize are present on an element, or are computed by the user agent. When this occurs:
aria-level is exposed in the groupLevel parameter of groupPosition(),
aria-setsize is exposed in the similarItemsInGroup parameter, and
aria-posinset is exposed in the positionInGroup parameter.
4.7 Actions
As part of mapping roles to accessible objects as defined in Role Mapping, users agents expose a default action on the object.
MSAA: If an AT calls DoDefaultAction on an accessible object, the user agent SHOULD simulate a click on the
DOM element which is mapped to that accessible object.
IAccessible2: If an AT calls the IAccessibleAction on an accessible object, the user agent SHOULD simulate a click on the
DOM element which is mapped to that accessible object.
UIA Automation: If an AT calls any UIA pattern method on an accessible object, the user agent
SHOULD simulate a click on the DOM element which is mapped to that accessible object.
ATK/AT-SPI: If an AT calls an
action on an accessible object, the user agent SHOULD simulate a click on the DOM element which is mapped to that accessible object.
AX API: If an AT triggers an AXPress action on an accessible object, the user agent
SHOULD simulate a click on the DOM element which is mapped to that accessible object.
Note
Authors will need to create handlers for those click events that update WAI-ARIA states and properties in the
DOM accordingly, so that those updated states can be populated by the user agent in the Accessibility
API.
4.8 Events
User agents fire events for user actions, WAI-ARIA state changes, changes to
document content or node visibility, changes in selection and operation of menus as defined in the following sections.
4.8.1 State and Property Change Events
User agentsMUST notify assistive technology of state changes as defined in the table below, SHOULD notify assistive technology of
property changes if the accessibility API defines a change event for the property, and SHOULD NOT notify assistive technology of
property changes if the accessibility API does not define a change event for the property. For example, IAccessible2 defines an event
to be used when aria-activedescendant changes.
WAI-ARIA properties that are expected to change include
aria-activedescendant, aria-valuenow, and aria-valuetext.
Note
In some APIs, AT will only be notified of events to which it has subscribed.
For simplicity and performance the user agent MAY trim out change events for state or property changes that assistive technologies typically ignore, such as events
that are happening in a window that does not currently have focus.
Note
Translators: For label text associated with the following table and its toggle buttons, see the mappingTableLabels object in the <head> section of this
document.
4.8.2 Changes to document content or node visibility
Processing document changes is important regardless of WAI-ARIA. The events described in the table below are used by user agents
to inform AT of changes to the DOM via the accessibility tree. For the purposes of conformance with
this standard, user agentsMUST implement the behavior described in this section whenever WAI-ARIA attributes are applied to
dynamic content on a Web page.
Table of document change scenarios and events to be fired in each
API
Scenario
MSAA + IAccessible2 event
UIA event
ATK/AT-SPI event
AX API Notification
When text is removed
IA2_EVENT_TEXT_REMOVED
EVENT_OBJECT_LIVEREGIONCHANGED
text_changed::delete
If in a live region, AXLiveRegionChanged. If in aria-errormessage, AXValidationErrorChanged.
When text is inserted
IA2_EVENT_TEXT_INSERTED
EVENT_OBJECT_LIVEREGIONCHANGED
text_changed::insert
If in a live region, AXLiveRegionChanged. If in aria-errormessage, AXValidationErrorChanged.
When text is changed
IA2_EVENT_TEXT_REMOVE and IA2_EVENT_TEXT_INSERTED
EVENT_OBJECT_LIVEREGIONCHANGED
text_changed::delete and text_changed::insert
If in a live region, AXLiveRegionChanged. If in aria-errormessage, AXValidationErrorChanged.
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
EVENT_OBJECT_HIDE
The MSAA event called EVENT_OBJECT_DESTROY is not used because this has a history of stability issues and assistive
technology avoids it. In any case, from the user's point of view, there is no difference between something that is hidden or destroyed.
AutomationElement..::.StructureChangedEvent
children_changed::remove
AXUIElementDestroyed
If in a live region, AXLiveRegionChanged
When an accessibility subtree is removed
EVENT_OBJECT_REORDER
The MSAA event called EVENT_OBJECT_DESTROY is not used because this has a history of stability issues and assistive
technology avoids it. In any case, from the user's point of view, there is no difference between something that is hidden or destroyed.
AutomationElement..::.StructureChangedEvent
children_changed::remove
AXUIElementDestroyed
If in a live region, AXLiveRegionChanged
When an accessibility subtree is shown
EVENT_OBJECT_SHOW
children_changed::add
AXUIElementCreated
If in a live region, AXLiveRegionChanged
When an accessibility subtree is inserted
EVENT_OBJECT_REORDER
children_changed::add
AXUIElementCreated
If in a live region, AXLiveRegionChanged
When an accessibility subtree is moved
Treat it as a removal from one place and insertion in another
Treat it as a removal from one place and insertion in another
Treat it as a removal from one place and insertion in another
AXUIElementDestroyed/ AXUIElementCreated
If in a live region, AXLiveRegionChanged
When an accessibility subtree is changed (e.g. replaceNode)
Treat it as a removal and insertion
Treat it as a removal and insertion
Treat it as a removal and insertion
AXUIElementDestroyed/ AXUIElementCreated
If in a live region, AXLiveRegionChanged
In some cases, node changes may occur where the node is not an element or has no accessible object. For example, a numbered list bullet ("12.") may have a node in the accessibility tree
but not in the DOM tree. For text within a paragraph marked in HTML as
<strong>, the <strong> element has a node in the DOM tree but may not have one in the accessibility tree.
The text itself will of course be in the accessibility tree along with the identification of the range of text that is formatted as strong. If any of the changes described in the table
above occur on such a node, user agents SHOULD compute and fire relevant text change events as described above.
User agents SHOULD ensure that an assistive technology, running in process can receive notification of a node being removed prior to removal. This allows an assistive technology, such as a
screen reader, to refer back to the corresponding DOM node being deleted. This is important for live regions where
removals are important. For example, a screen reader would want to notify a user that another user has left a chat room. The event in
MSAA would be EVENT_OBJECT_HIDE. For ATK/AT-SPI
this would be children_changed::remove. And in macOS, the event is AXLiveRegionChanged. This also requires the user agent to provide a unique ID in the
accessibility API notification identifying the unique node being removed.
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 assistive technology 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/AT-SPI 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:
In ATK/AT-SPI and IAccessible2, the
RELATION_MEMBER_OF relation on the accessible event's target accessible object SHOULD point to any ancestor with
aria-atomic="true" (if any).
In ATK/AT-SPI and IAccessible2, 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.
Current state reflected in IUIAutomationElement::CurrentIsKeyboardFocusable, can be retrieved with IUIAutomationElement::GetCurrentPropertyValue method using
UIA_IsKeyboardFocusablePropertyId property identifier.
STATE_FOCUSABLE
boolean AXFocused: the AXUIElementIsAttributeSettable method returns YES.
Focused state
STATE_SYSTEM_FOCUSED
Current state reflected in IUIAutomationElement::CurrentHasKeyboardFocus, can be retrieved with IUIAutomationElement::GetCurrentPropertyValue method using
UIA_HasKeyboardFocusPropertyId property identifier.
STATE_FOCUSED
boolean AXFocused
Focus event
EVENT_OBJECT_FOCUS
Clients can subscribe with IUIAutomation::AddFocusChangedEventHandler using callback interface is IUIAutomationFocusChangedEventHandler
In the single selection case, selection follows focus (see the section "Focus States and Events Table" for information about focus events). User
agents MUST fire the following events when aria-selected changes:
Single selection events
Scenario
MSAA
Microsoft UIA
ATK/AT-SPI
AX API
Focus change
EVENT_OBJECT_SELECTION and EVENT_OBJECT_STATECHANGE on newly focused item.
UIA_SelectionItem_ElementSelectedEventId on the newly focused element.
If on a gridcell, row, option, or tab, fire UIA_SelectionItem_ElementSelectedEventId.
object:selection-changed on the current container,
object:state-changed:selected on the descendant accessible object whose selection has changed:
detail1 = 1 for the descendant which just became selected.
detail1 = 0 for the descendant which just became unselected.
AXSelectedChildrenChanged
The multiple selection case occurs when aria-multiselectable="true" on an element with a role that supports that property. User agents MUST fire the following events
when aria-selected changes on a descendant, as follows:
The multiple selection case occurs when aria-multiselectable="true" on an element with a role that supports that property. There are several important aspects:
In Microsoft UIA, the Selection and SelectionItem Control Patterns expose the selection availability, state, and
methods.
User agents MUST fire the following events when aria-selected changes on a descendant, as follows:
User agent MAY fire an EVENT_OBJECT_SELECTIONWITHIN. If this event is fired the other events noted above MAY be trimmed out for performance.
For each element selected or deselected, fire SelectionItem Control Pattern: UIA_SelectionItem_ElementAddedToSelectionEventId or
UIA_SelectionItem_ElementRemovedFromSelectionEventId on the current container. User agents MAY choose to fire the Selection Control Pattern Invalidated event, which
indicates that the selection in a container has changed significantly and requires sending more addition and removal events than the InvalidateLimit constant permits.
the user agent MAY fire a single object:selection-changed event on the container, vs. multiple events, for performance,
object:state-changed:selected on any descendant accessible object whose selection has changed:
Some APIs, provide special events whenever a menu is opened or closed. User agentsSHOULD provide the
events as described in the table below. If provided, because menus can be made visible or hidden using a variety of techniques, a user agentMUST ensure that the events are
nested and symmetrical.
Frequently, a menubar is used to organize a hierarchy of menus. In those cases, the menubar MUST be a
DOM parent of the associated menuitems, or one defined by aria-owns. In other cases, no menubar is involved; for example, when the menu is associated with a toolbar button, or is a context menu.
Nonetheless the relevant menu events are provided as described in the following table.
Menu events
Scenario
MSAA
Microsoft UIA
AX API
Menubar is currently not active, and user moves focus to the menubar from elsewhere thereby activating it. As a result, a menuitem in the menubar is focused.
Activate the menubar and fire EVENT_SYSTEM_MENUSTART on the accessible object for the menubar.
MenuModeStartEvent on the accessible object for the menu.
AXMenuOpenedNotification
Focus a menuitem while menubar is activated, or focus a menuitem in a menu.
EVENT_OBJECT_FOCUS
AutomationFocusChangedEvent
AXMenuItemSelectedNotification
Menu popup made visible (menu is opened).
Should only be fired once until the menu is closed and opened again.
EVENT_SYSTEM_MENUPOPUPSTART
MenuOpenedEvent, then a focus event on a menuitem.
AXMenuOpenedNotification
Menu popup hidden (menu is closed).
EVENT_SYSTEM_MENUPOPUPEND once only for accessible menu object and only if EVENT_SYSTEM_MENUPOPUPSTART was fired for it.
MenuClosedEvent
AXMenuClosedNotification
Any open menus are closed including sub-menus, and user moves focus away from the menubar; menubar is deactivated.
EVENT_SYSTEM_MENUEND on the menubar and deactivate the menubar.
MenuClosedEvent, then MenuModeEndEvent
AXMenuClosedNotification
5. Privacy considerations
In accordance with Web Platform Design Principles, this specification provides no programmatic
interface to determine if information is being used by Assistive Technologies. However, this specification does allow an author to present different information to users of Assistive
Technologies from the information available to users who do not use Assistive Technologies. This is possible using many features of the ARIA and CORE-AAM specifications, just as this is
possible using many other parts of the web technology stack. This content disparity could be abused to perform
active fingerprinting of users of Assistive Technologies.
6. Security considerations
This specification introduces no new security considerations.
B.1 Participants active in the ARIA WG at the time of publication
Irfan Ali (Educational Testing Service)
CB Averitt (Deque Systems, Inc)
Sina Bahram (Invited Expert)
Shirisha Balusani (Invited Expert)
Amelia Bellamy-Royds (Invited Expert)
Curt Bellew (Oracle Corporation)
Alex Bernier (Association BrailleNet)
Zoë Bijl (Invited Expert)
Jorge Blazquez Alonso (IBM Corporation)
Alice Boxhall (Google LLC)
Matthew Brennan (Facebook)
Kim Bunge (TPGi)
Shari Butler (Pearson plc)
Tammy Campoverde (UnitedHealth Group)
David Caro (Wikimedia Foundation)
Timothy Cole (University of Illinois at Urbana-Champaign)
Dominic Cooney (Facebook)
Michael Cooper (W3C Staff)
James Craig (Apple Inc.)
Jory Cunningham (Salesforce)
Jes Daigle (Bocoup)
Joanmarie Diggs (Igalia)
Jason Duan (IBM Corporation)
Isaac Durazo (Bocoup)
Howard Edwards (Bocoup)
Steve Faulkner (TPGi)
Reinaldo Ferraz (NIC.br)
Alexander Flenniken (Bocoup)
Bryan Garaventa (Level Access)
Matt Garrish (DAISY Consortium)
Jaunita George (Navy Federal Credit Union)
Raghavendra Giriyappa (IBM Corporation)
Michael Goddard (Bocoup)
Glen Gordon (TPGi)
Jon Gunderson (University of Illinois at Urbana-Champaign)
Markku Hakkinen (Educational Testing Service)
Sarah Higley (Microsoft Corporation)
Hans Hillen (TPGi)
Isabel Holdsworth (TPGi)
Stanley Hon (Microsoft Corporation)
Nicholas Hoyt (University of Illinois at Urbana-Champaign)
Shilpi Kapoor (BarrierBreak Technologies)
Matthew King (Facebook)
Greta Krafsig (The Washington Post)
Peter Krautzberger (Invited Expert)
JaEun Jemma Ku (University of Illinois at Urbana-Champaign)
Lori Lane (University of Illinois at Urbana-Champaign)
Charles LaPierre (Benetech)
Gez Lemon (TPGi)
Aaron Leventhal (Google LLC)
Brian Liu Xu (Microsoft Corporation)
David MacDonald (Invited Expert)
Carolyn MacLeod (IBM Corporation)
Daniel Marques (WIRIS Science)
Dominic Mazzoni (Google LLC)
Mark McCarthy (University of Illinois at Urbana-Champaign)
Jan McSorley (Pearson plc)
Erika Miguel (Bocoup)
Sheila Moussavi (Bocoup)
Rich Noah (Bocoup)
James Nurthen (Adobe)
Scott O'Hara (Microsoft Corporation)
Achraf Othman (MADA Center)
Vijaya Gowri Perumal (Newgen Knowledgeworks)
Christos Petrou (Centre for Inclusive Design)
Simon Pieters (Bocoup)
Ian Pouncey (TetraLogical Services Ltd)
Ruoxi Ran (W3C Staff)
Adrian Roselli (TPGi)
Janina Sajka (Invited Expert, The Linux Foundation)
Stefan Schnabel (SAP SE)
Harris Schneiderman (Deque Systems, Inc.)
Lisa Seeman-Kestenbaum (Invited Expert)
Boaz Sender (Bocoup)
Cynthia Shelly (Google LLC)
Tzviya Siegman (Wiley)
Sharon Snider (IBM Corporation)
Neil Soiffer (Invited Expert)
Volker Sorge (Invited Expert)
Francis Storr (Intel Corporation)
Melanie Sumner (Invited Expert)
Alexander Surkov (Igalia)
William Tennis (Navy Federal Credit Union)
Seth Thompson (Bocoup)
Scott Vinkle (Shopify)
Can Wang (Zhejiang University)
Wei Wang (Zhejiang University)
Léonie Watson (TetraLogical Services Ltd)
Jason White (Educational Testing Service)
Jan Williams (TPGi)
Evan Yamanishi (W. W. Norton)
Benjamin Young (Wiley)
Valerie Young (Bocoup)
Marco Zehe (Mozilla Foundation)
B.2 Enabling funders
This publication has been funded in part with U.S. Federal funds from the Department of Education, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067, then under contract number HHSP23301500054C, and now under HHS75P00120P00168. 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.