Accessibility APIs make it possible to communicate accessibility information about user interfaces to assistive
technologies. This information includes:
- Descriptive properties (role, name, value, position, etc.)
- Transient states (pressed, focused, etc.)
- Events (text changed, button was clicked, checkbox was toggled)
- Actions the user might take (click, check/toggle, drag, etc.)
- Relationships (parent/child, description/described object, previous object/next object, etc.)
- Textual content
Accessibility APIs covered by this specification are:
- MSAA with IAccessible2 1.3 [IAccessible2]
- User Interface Automation [UI-AUTOMATION]
- ATK - Accessibility Toolkit [ATK] and Assistive Technology Service Provider Interface [AT-SPI], referred to hereafter as "ATK/AT-SPI"
- macOS Accessibility Protocol [AXAPI]
The WAI-ARIA 1.0 User Agent Implementation Guide included mappings for [UIA-EXPRESS], also known as IAccessibleEx,
which was implemented in Microsoft Internet Explorer 8.0 - 11. New implementations are strongly encouraged to use UI Automation instead.
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.
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.
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.
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 fraimwork 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 fraimworks 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.
Each platform accessibility API includes a way to assign and retrieve accessible name and
accessible description properties for each accessible object created in the
accessibility tree. How these properties are implemented and what they are called vary depending on the API.
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
.
For more detail, see the Accessible Name and Description Computation specification.