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 standards and drafts index.
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 a 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 that 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, 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 IUIAutomationElement::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.
1.2.3 Android Accessibility API
Android accessibility services and applications both express user interface elements as a tree of AccessibilityNodeInfo objects. Accessibility services receive events,
traverse the AccessibilityNodeInfo tree, retrieve properties, and perform actions on a node. Conversely, Android applications build the AccessibilityNodeInfo tree
indirectly by constructing views or composables, or directly via an AccessibilityNodeProvider. They then subsequently fire events, and handle actions.
For WAI-ARIA implementers, of particular interest is the mapping into properties, actions, and events on AccessibilityNodeInfo and AccessibilityEvent.
Note: Many ARIA roles in this specification are mapped to android.view.View as a default or fallback mapping. This often reflects a baseline level of support where a more
specific Android widget class is not available or has not been defined yet. These mappings are subject to change as the Android accessibility ecosystem evolves and more specific mappings
are identified. In cases where no specific role mapping is available, Android's
setRoleDescription
can be used to convey the specific ARIA role semantics to assistive technologies.
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.
In Android, accessible names map to a number of properties defined on AccessibilityNodeInfo such as content description, supplemental description, and text.
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.
Normative sections provide requirements that user agents and assistive technologies MUST follow for an implementation to conform to this specification.
Non-normative (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.1 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. Mapping WAI-ARIA to Accessibility APIs
3.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.
3.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.
3.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.
3.4 Role mapping
Platform accessibility APIs traditionally have had a finite set of predefined roles that are expected by
assistive technologies on that platform and only one or two roles may be exposed. In contrast,
WAI-ARIA allows multiple roles to be specified as an ordered set of space-separated valid role tokens. The additional roles are
fallback roles similar to the concept of specifying multiple fonts in case the first choice font type is not supported.
3.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")
3.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 conformance 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), this is an authoring
error, but the user agent behavior is not specified as a single rule. For most roles, user agents can either recover the error by ignoring the role, or respect the author's intended role
in scenarios deemed by the implementation to be harmless. Please note that this permissiveness in how engines treat author role errors might be overridden in a language-specific mapping
document such as [HTML-AAM].
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.
android.widget.ProgressBar Method: AccessibilityNodeInfo.getRangeInfo returns an AccessibilityNodeInfo.RangeInfo object if it represents a numeric range without
aria-valuetext.
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.
android.view.View Note: Exposed with CollectionItemInfo.
Note
[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).
3.5 State and Property Mapping
This section describes how to expose WAI-ARIA states and properties.
3.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
Android
TBD
3.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
AX API
Property: AXDetailsElements: pointers to accessible nodes matching IDREFs
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: AXTitle: <value> 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
You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.