User agents (browsers but also any other software that retrieves, renders, and facilitates end user interaction with (web) content) must translate web content and it’s semantic elements to assistive technologies. This is a job for accessibility API.
As with any other Application Programming Interface (API), it’s mission is to provide a communication channel – this one is used to expose names, roles, states, events and other properties to assistive technologies. In practice we can simplify it as a communication channel between browser and screen-reader, based on the DOM tree and some other rules too (some CSS is also needed, for example visibility and display properties that can be inline or not).
We will not go into details of past practices, but let’s just mention that assistive technologies originally used some strange techniques to define the meaning of UI and it’s elements. For example – seeing a list with links at the top of the page was interpreted as a navigation menu.
This has obvious not been the most correct assumption for every scenario, therefore a common, more standard way had to be defined. And here comes the role of Accessibility API – as a much better way for the software communication. The downside is that platform (OS or browser) owners developed specialized interfaces for their APIs independently. Therefore the APIs can have different interpretations for same definitions, found in the DOM.
But nonetheless their main task is to include the accessibility tree and expose it to assistive technologies. To do so efficiently they have to provide the following:
- All properties that are descriptive (name, value, role, description, …),
- Important states (button pressed, checkbox checked, element focusable, …),
- Event states (button was clicked, checkbox was checked, …),
- Hierarchy and relationships (element controls another, grandparent / parent / child, ….).
So Accessibility API is actually generating the Accessibility tree but not just in it’s static form – it also makes care that user interaction is reflected in the needed properties. Therefore we can see it as a two-way channel that enables assistive technologies to get the latest state of the user agent view with all the interactions and changes.
As mentioned before – there are different Accessibility APIs for different vendors and they can work differently. So in many cases there is no simple way to check their support or how do they expose accessibility tree to user agents.
This is crucial for our developer and testing efforts, and explains also why some assistive technologies work (better) with specific Operating Systems and User Agents. The solution is therefore to investigate and test with different technologies.
More information on Accessibility API from the core team (opens in new window).
