Glossary · Accessibility term
Accessibility API
An accessibility API is the channel an operating system provides so assistive technology can find out what is on screen. Your browser reads the page, builds an accessibility tree out of the markup, the CSS and any ARIA on top, and hands that tree to the platform. A screen reader asks the platform rather than reading your HTML, and ARIA calls that the preferred route while permitting software to read the markup out of the DOM instead. Every desktop and mobile platform has one, and the names differ. Windows has two in active use. UI Automation, and the older Microsoft Active Accessibility with its IAccessible2 extension, which is what JAWS and NVDA actually consume from Firefox and Chrome. On macOS it is the AX API, which a Mac developer meets under the name NSAccessibility. Android has its own, and Linux splits the job in two, between an interface applications implement and a desktop service that gathers it for the tools reading it.
In practice
Write a <button> element and the browser tells the platform there is a control here, its role is button, its name is the text inside it, and its state is enabled. None of that came from your HTML directly. It came from the accessibility tree the browser built out of your HTML, your CSS and any ARIA sitting on top, which is why the announcement can differ from what you typed.
This is why a <div> with a click handler does not work, however well it behaves with a mouse. The text inside is still exposed and still readable, so it is not invisible exactly. What is missing is the control semantics and the keyboard behavior, so the element is unreachable and unoperable while reading like ordinary content. That is worse than being absent, because nothing signals a problem.
Not everything makes it into the tree, and the rules differ in strength. An element hidden with display:none, visibility:hidden or the HTML hidden attribute must not appear in it. An element carrying aria-hidden="true" should not. That difference between must not and should not is where a lot of aria-hidden arguments end up, and it is worth checking before anybody insists.
Automated tools read nearby data rather than the same data. A browser-driven scanner reads the accessibility tree, or in some tools the rendered DOM, rather than the platform API a screen reader is consuming. Close enough that the two usually agree a name is missing. Never close enough for a tool to tell you whether the name is any good, because that is a judgement about your content rather than a fact about the tree.
Why it matters
It explains the shape of WCAG's Robust principle. The Level A rule there asks for a name, a role, and any states, properties and values a user can set, plus notification when any of those change. That is the vocabulary the platform carries, and the only thing assistive technology can be told about an element. The API carries more besides, including descriptions, relationships between elements and the actions available on one, so it is not a tidy list of three. What it is, is the reason "it works fine with a mouse" has never been an answer to anything.
Where the chain breaks
Markup, plus CSS, plus ARIA, becomes an accessibility tree, which becomes platform API data, which a screen reader reads. Every bug in what a screen reader announces is a break somewhere along that chain, and knowing which link failed is the difference between adding an ARIA attribute and fixing the element. Plenty of accessibility problems never touch it. Contrast, timing and plain confusing writing sit in what the page says rather than in how it is exposed.
Where this shows up on the site
Related terms
- Accessibility treeThe accessibility tree is a second structure the browser builds alongside the DOM, holding one object for every part of your page that has to be exposed to assistive technology.
- Name, Role, ValueName, role and value are the facts assistive technology needs about a control, and the shorthand quietly drops one.
- Screen readerA screen reader is software that reads the screen out loud, or sends it to a braille display, for people who cannot see it.
- RobustRobust is the fourth of WCAG's four principles, and it asks that content be built well enough for a wide variety of user agents, including assistive technology, to interpret it.
- Semantic HTMLSemantic HTML means using HTML elements for what they mean rather than for how they look.
Knowing the word is the easy part.
Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.