|In a nutshell
As part of the rendering process, the browser builds the accessibility tree, a simplified version of the Document Object Model (DOM) tree. The accessibility tree contains only elements that need to be exposed to assistive technologies like screen readers.
When triggered, assistive technologies use the browser's accessibility APIs to retrieve information from the accessibility tree and present it to users.
The structure of the tree
Each node in the tree is an accessible object. It can represent one of the following:
an actionable element, like a link or button;
an element that provides information about the page content and structure, like a navbar or a heading.
Any div element with purely decorative or container role will be ignored.
Find the accessibility tree with Dev Tools
Video: Debugging accessibility with Chrome DevTools
This is a great video on using Chrome's Dev Tools to look up the accessibility tree. The process is very similar in Edge.
Please note that the video starts with an introduction to Google's Lighthouse. The part about the accessibility tree starts at minute 6:00.
DOM vs. Accessibility tree
Here we take the navbar component of this website and compare its representation in the DOM and the accessibility trees.
// DOM tree<nav><ul><li><a>Home</a></li><li><a>Blog</a></li>// other list items</ul></nav>// Accessibility treenavigationlistlistitemlink "Home" focusable: true focused: trueStaticText "Home"listitemlink "Blog" focusable: trueStaticText "Blog"// other list itemsWhile the DOM tree is structured by HTML tags/elements, the accessibility tree is structured by roles. For each object in the accessibility tree, its role matches the function of its corresponding HTML element.
Examples of HTML tags and the roles they map to in the accessibility tree:
<nav>to navigation<ul>to list<a>to link<header>to banner<aside>to complementary
But how does the browser know which role to assign to an element?
Some roles are implicit and assigned by default, based on the HTML tag used to create the element. As developers, we can also explicitly assign a role to an element using a set of special roles and attributes called Accessible Rich Internet Applications, often referred to by the acronym ARIA.
Implicit roles
Each role in the example above is implicit. It's built in the definition of the semantic HTML tag used to create the element. When the browser builds the accessibility tree, it assigns the role, and all related properties and states, to the corresponding accessible object.
Zooming in on an accessible object
Let's look at the first link object to understand why using semantic HTML helps accessibility.
Details available:
- ✔
name: Home
- ✔
role: link
- ✔
property: focusable
- ✔
state: focused
We have a link with the name "Home". It's a focusable (i.e. actionable) element. For a keyboard user, this means that they can navigate to it by pressing the Tab key, and activate it by pressing Enter.
At the time of this snapshot, the link was in focus, i.e. selected and ready to be activated.
Assistive tech behavior
Each assistive technology will use the information from the accessibility tree to present the object to the user in the most appropriate way.
A screen reader will announce it as "Home link".
A speech recognition software will recognize it as "Home" and allow the user to activate it with the command "click Home".
Isn't semantic HTML cool? By relying on the semantic <a> tag we get all the functionality expected from a link for free. With only HTML.
Explicit roles
We can also explicitly assign a role to an HTML element using ARIA roles and attributes. These are added to HTML tags in order to modify or improve the default behavior of an element and make it accessible.
Example: create a button from a <div>
But really, do not do this at home. Just pay attention to the extra steps needed to make this button accessible
<div role="button" type="button">Close</div>Let's assume we took a div, a non-semantic element, and attached a click event to it. It will work for a sighted user with a mouse, but a screen reader user will not know it's a button. For that reason, we added the ARIA attribute of role.
Is this button accessible yet? Absolutely not!
The button will not be fully functional until we add other attributes and events:
the tabindex attribute to make it focusable, otherwise keyboard users won't be able to reach it: tabindex="0"
event handlers to allow the button to be activated with the Enter or Space keys. This functionality is important for keyboard users, and it's available by default when using the <button> tag.
Take a look at this CodePen for the complete code required to make a div element behave like a button.
Don't jump to ARIA right away!
The first rule of ARIA is: do NOT use ARIA. If you want to implement a certain functionality and the HTML tag for it exists, use it.
Throughout this website, we will discuss scenarios where ARIA attributes could be used to improve accessibility, but also consider their drawbacks especially when HTML alternatives are available.
For right now, it's important to remember that assistive technologies have a better relationship with semantic HTML than with ARIA, and using ARIA can sometimes lead to unexpected behavior.
What next?
Notice how each link in our accessibility tree example has a name? It's called the accessible name, and assistive technologies use it to announce each link to the user. For speech recognition software, the name will be used to activate the each link. Let's have a look at how the browser computes the accessible name.
Read next: The acessibille name