Category: Assistive Technologies

Accessibility API

Also known as: Accessibility Application Programming Interface, Platform Accessibility API

Simply put

An Accessibility API is a set of software connections that lets assistive technologies, such as screen readers, understand and interact with the content on a screen. It acts as a bridge between an application or web page and the tools people with disabilities use to navigate and operate their devices. Operating systems and platforms like Apple's and Google's Android provide their own accessibility APIs for developers to support.

Formal definition

An Accessibility API is a platform-provided programming interface through which user agents and applications expose the roles, states, properties, and relationships of user interface elements to assistive technologies. Per the W3C Core Accessibility API Mappings (Core-AAM), WAI-ARIA roles, states, and properties are expected to be mapped by user agents onto the accessibility API of the underlying platform, enabling assistive technologies to programmatically determine and interact with interface elements. Platform implementations vary; for example, Apple provides an Accessibility framework API, and Google's Android exposes an AccessibilityService API, each with its own capabilities, constraints, and usage policies (for instance, Google restricts certain autonomous uses of its Accessibility API).

Why it matters

Accessibility APIs are the foundation that makes assistive technology possible on modern platforms. Without a programmatic interface exposing the roles, states, properties, and relationships of interface elements, a screen reader or other assistive tool would have no reliable way to determine what is on the screen or how a user can interact with it. When an application communicates properly through the platform's accessibility API, tools like screen readers can announce buttons, form fields, and content in a meaningful order; when it does not, those same elements may be invisible or unusable to people who rely on assistive technology.

For developers and organizations working toward WCAG conformance, the accessibility API is where much of the underlying mapping happens. The W3C Core Accessibility API Mappings (Core-AAM) describes how WAI-ARIA roles, states, and properties are expected to be exposed by user agents onto the platform's accessibility API. This is why correct use of semantic markup and ARIA matters: it determines what assistive technologies can actually perceive. It is worth noting, however, that conformance with technical guidelines and correct API exposure does not by itself guarantee a fully usable experience or immunity from legal claims; manual testing with actual assistive technologies remains necessary.

Platform differences also carry practical and policy consequences. Implementations vary across operating systems, and platforms may restrict how their accessibility APIs are used. For example, Google's policy states that any use of the Accessibility API enabling an app to autonomously initiate, plan, and execute actions or decisions is strictly prohibited. Developers must therefore account not only for technical capability but also for each platform's usage policies, which can limit how these interfaces are employed.

Who it's relevant to

Accessibility Engineers and Developers

Developers rely on accessibility APIs to ensure that assistive technologies can perceive and operate their interfaces. Understanding how native semantics and WAI-ARIA are mapped to a platform's accessibility API, per the W3C Core-AAM, helps engineers build interfaces that expose accurate roles, states, and properties, and account for platform-specific capabilities and restrictions.

UX and UI Designers

Designers who understand how interface elements are exposed through accessibility APIs can specify components and interaction patterns that translate meaningfully to assistive technology users. This awareness supports designs that carry accurate structure and semantics through to the assistive technology layer.

Assistive Technology Users

People who use screen readers and other assistive technologies depend on accessibility APIs as the bridge between an application and their tools. When applications correctly expose their elements through these interfaces, users can navigate and operate content that would otherwise be inaccessible.

Compliance Officers and Accessibility Program Leads

Those responsible for accessibility programs should understand that proper accessibility API exposure underpins WCAG conformance efforts, but that correct exposure alone does not guarantee a fully usable experience or legal safety. Manual and assistive technology testing remain necessary, and this guidance is not legal advice; consult qualified counsel and current agency guidance for specific obligations.

Inside Accessibility API

Accessibility Tree

A structured representation that an accessibility API exposes to assistive technologies, derived from the underlying application or document (such as the DOM in web contexts). It conveys the elements, their roles, states, and relationships in a form that assistive technology can consume.

Roles

Information about what an element is or does, such as button, link, heading, or checkbox. Roles help assistive technologies communicate an element's purpose to the user.

Names and Descriptions (Accessible Name and Description)

The human-readable label and supplementary detail associated with an element, which assistive technologies present to users to identify and explain controls and content.

States and Properties

Dynamic and static attributes such as checked, expanded, disabled, or required, which communicate the current condition and characteristics of an element to assistive technologies.

Events and Notifications

Mechanisms by which the API informs assistive technologies of changes, such as focus movement or content updates, so users are kept aware of what is happening in the interface.

Platform-Specific Implementations

Accessibility APIs are generally provided by operating systems and platforms (for example, on Windows, macOS, iOS, Android, and within web browsers), each with its own interfaces that applications and assistive technologies use to exchange accessibility information.

Common questions

Answers to the questions practitioners most commonly ask about Accessibility API.

Does using an accessibility API automatically make an application accessible?

No. An accessibility API is the mechanism that exposes information about user interface elements to assistive technologies, but it does not by itself guarantee an accessible experience. Developers must correctly expose roles, names, states, and properties, and even fully populated accessibility information does not ensure usability for all users. Manual testing with assistive technologies and evaluation against relevant WCAG success criteria are generally needed, since automated checks and API exposure alone detect only a portion of accessibility issues.

Is an accessibility API the same thing as an assistive technology like a screen reader?

No. They are distinct but related components. An accessibility API is a platform- or framework-provided interface that describes UI elements in a structured way. Assistive technologies, such as screen readers or magnifiers, consume the information provided through that API and present it to the user. The accessibility API acts as the bridge between the application and the assistive technology, rather than being the assistive technology itself.

Which accessibility APIs are commonly encountered across different platforms?

Different platforms expose their own accessibility APIs. Examples commonly referenced include platform-specific interfaces on major desktop and mobile operating systems, as well as web-oriented mechanisms. On the web, ARIA (Accessible Rich Internet Applications) attributes are commonly used to supplement native semantics so that information can be mapped to the underlying platform accessibility API. The specific API involved generally depends on the operating system, browser, or framework in use.

How does an accessibility API relate to ARIA and native HTML semantics?

Native HTML elements often expose accessibility information to the platform accessibility API automatically through their built-in semantics. ARIA can be used to supply or override roles, states, and properties where native semantics are insufficient, such as with custom widgets. A commonly cited practice is to prefer native semantics first and use ARIA to fill gaps, because incorrect ARIA can convey inaccurate information through the accessibility API.

What information does an accessibility API typically expose about an interface element?

An accessibility API generally exposes attributes such as an element's role (what type of control it is), its accessible name and description, its state (for example checked, expanded, or disabled), its value, and its relationships to other elements. Assistive technologies use this exposed information to communicate the interface to the user and to enable interaction.

How can teams verify that information is being correctly exposed through an accessibility API?

Teams commonly use accessibility inspection tools that display the accessibility tree or the properties exposed to the platform API, alongside testing with actual assistive technologies. Because automated tooling detects only a portion of issues, manual testing with screen readers and other assistive technologies is generally recommended to confirm that roles, names, and states are conveyed as intended in real usage.

Common misconceptions

Exposing content through an accessibility API is the same thing as meeting WCAG conformance.

An accessibility API is a technical channel for communicating information to assistive technology. Proper use of it can support meeting certain WCAG success criteria, but conformance depends on how correctly and completely roles, names, states, and relationships are conveyed, and WCAG addresses many concerns beyond what an API alone handles. Meeting a standard also does not by itself guarantee a usable experience or legal compliance.

If an application uses an accessibility API, it is automatically accessible to all users.

The API only carries the information the application provides. Incorrect roles, missing accessible names, or unannounced state changes still produce a poor experience. Automated checks detect only a portion of issues, so manual testing and testing with actual assistive technologies remain necessary.

There is a single, universal accessibility API used across all platforms.

Accessibility APIs are generally platform- and browser-specific. Developers and testers should account for differences across operating systems, browsers, and the assistive technologies that consume these APIs rather than assuming uniform behavior.

Best practices

Use native platform controls and semantic elements where possible, so accurate roles, names, and states are exposed to the accessibility API by default rather than being reconstructed manually.

When building custom components, ensure roles, accessible names, descriptions, states, and properties are set correctly and kept in sync with the visual interface as it changes.

Communicate dynamic changes, such as focus movement, content updates, and state transitions, through the appropriate API events or notifications so assistive technology users are not left unaware.

Test with real assistive technologies across the relevant platforms and browsers, since accessibility API implementations vary and automated tools capture only a portion of potential issues.

Combine automated checks with manual review, recognizing that passing automated tests does not confirm a fully accessible experience or guarantee legal compliance.

Treat this guidance as a technical starting point rather than legal advice; consult qualified legal counsel and current agency rulemaking for questions about specific compliance obligations.