What should we know about the accessibility tree?
Why is digital accessibility important?
We, as a society, have to create a more accessible web using existing means or creating new ones, thereby making our society more friendly and comfortable for all its members. However, an ethical driver is often not enough to achieve this goal.
Therefore, the following three drivers for business are highlighted:
What is an accessibility tree?
The term Document Object Model (DOM) is clear and familiar to everyone, but have you ever wondered how a screen reader gets the information it needs from the DOM? In this article, I would like to discuss the topic of the accessibility tree and what role it plays for screen readers. I hope you’ll enjoy it, let’s start! 👉
If you don’t go too far into the details, you can imagine the accessibility tree as a subset of the DOM. The DOM tree is translated, in parallel, into the primary, visual representation of the page, and the a11y tree. The main difference between DOM and the a11y tree is that the second contains accessible objects that represent the user interface’s structure(UI). Each node in the accessibility tree represents an element in the UI as exposed through the accessibility API. Accessible objects for HTML elements are created when at least one of the triggers is present:
- it may fire an accessibility event;
- it has a property, relationship, or feature which needs to be exposed to assistive technology.
For example, <div> that is only a container, has no semantics, and only changes the color of a block, will be omitted in the a11y tree structure, but the style change will be exposed in another way.
An a11y tree is created simultaneously with the DOM. Browsers trigger the a11y tree to give assistive technologies something to hook into. When we use ARIA attributes, we give auxiliary instructions to the browser about how to render an a11y tree.
An accessible object is a node in the accessibility tree. Accessible objects expose states, properties, and events for use by assistive technologies.
But there are a number of peculiarities regarding the a11y tree:
- most browsers create a11y trees differently;
- screen readers don’t read the accessibility API in the same way, so they interpret accessibility trees differently.
Preparation
For testing, we create a simple form template without semantics (Angular is used just for convenience) and we’re going to use Chrome Browser and NVDA assistive technology.
How do you think these tags will make it to the accessibility tree, and what will the screen reader user hear and will figure out about this form?
The script that the screen reader user hears:
<Logging page (Page title) — Sign in — Login — Edit — Password — Edit — Checkbox — Not checked — Remember me — Button “Submit>
This is what the form looks like in the browser for comparison:
From this, it becomes obvious that the a11y tree doesn’t have enough knowledge about the elements that should be included. So let’s correct the situation and provide a little more information for properly forming accessible objects.
The appearance of the form will be identical, but the script that the screen reader user hears will be different:
<Logging page (Page title) — Grouping — Sign in — Login — Edit — Required — Invalid entry — Password — Edit — Required — Invalid entry — Checkbox — Checked — Remember me — Button “Submit”>
With this simple test, we can see exactly what goes into the a11y tree:
Conclusion
Sometimes it can be tricky to cover digital accessibility subjects in the project. However, I believe that understanding the structure of the a11y tree will provide the necessary clues to create more accessible solutions.
