If you’re a developer, it’s a good idea to be familiar with platform accessibility APIs, and the mechanics of accessibility in the browser. You won’t learn about platform accessibility APIs in school, and few articles on the web discuss them, yet platform accessibility APIs are crucial to the way Assistive Technologies (AT) work.
If you watch this video of a screen reader focusing on a link (using the tab key), you’ll hear it announce “tink.uk, link”. If a speech recognition user wanted to activate the link, they could say “Click tink.uk“.
But how does the AT know it’s a link? Perhaps surprisingly, the answer lies in the browser, rather than the AT itself.
Let’s use the link from the video as an example:
<a href=”https://tink.uk“>tink.uk</a>
When the browser parses the HTML, it creates the Document Object Model (DOM). It’s a tree structure representing the elements and content of the HTML document. If an AT is running, the browser also creates an accessibility tree. It’s a parallel structure to the DOM that contains accessibility information about the elements and content in the HTML document.
The information in the accessibility tree for the link would be:
- Role: link
- Name: tink.uk
- State: focusable, unvisited
The AT then queries the accessibility tree for information using a platform accessibility API, and then makes that information available to the user. For example, it is the role that causes the screen reader to say “link”, and the name (the contents of the anchor element) that is used to identify the link itself.
Most HTML elements have a role. These roles are documented in a W3C specification called the HTML Accessibility API Mappings (AAM). For example, the ul element has a role of “list”, the button element has a role of “button”, the main element has a role of “main”, and so on.
When you look up an HTML element in the HTML AAM, you’ll notice there are several different platform accessibility APIs. This is because each platform (Windows, MacOS, and Linux) has its own accessibility API.
- Windows has MSAA + IAccessible2, and UIA
- MacOS has NSAccessibility Protocol (AX)
- Linux has ATK/ASPI
Although not currently documented in the HTML AAM, there are also platform accessibility APIs available on iOS (UI Accessibility Protocol), and Android (Accessibility Framework).
The AT uses the accessibility API for the platform, or in the case of Windows where there is a choice of accessibility API, the AT uses the one supported by the browser (Edge uses UIA, whereas Chrome and Firefox use MSAA + IAccessible 2).
There are two important things to be aware of with regard to the platform accessibility APIs:
- For an HTML element to work with an AT, it must be supported in the browser. You can find out more about this in What does accessibility supported mean?
- Platform accessibility APIs cannot be used by developers (using JavaScript). They are only available to ATs.
So to recap: the AT uses a platform accessibility API to ask the browser for accessibility information about the HTML element and/or content. If you are interested in knowing more about what happened before platform accessibility APIs were available, and the rise of the platform accessibility APIs themselves, you can find out in Accessibility APIs: a key to web accessibility.
