An accessibility tree is part of a website’s Document Object Model (DOM), which is a programming interface that represents the structure and content of a web page. The DOM allows software to change the style and content of a document to present that document more effectively to the user.
The accessibility tree provides information from the DOM in a format that can be understood by assistive technologies (AT) such as screen readers, eye-tracking systems, and speech input software.
By understanding the function of the accessibility tree, you may gain some perspective on how AT works — and resolve accessibility barriers that could impact the experiences of your users.
How Accessibility Trees Benefit Users with Disabilities
Assistive tech needs to have semantic information about an element’s characteristics in order to function predictably. In simple terms, “semantics" answers the question, “what is this thing?”
For example, let’s say that your website has a checkbox. People who perceive content visually can view the content around the checkbox and determine its purpose. However, if a screen reader user encounters a checkbox, they don’t have access to that visual information.
The screen reader software will need to tell the user that the checkbox exists, whether it’s currently checked or unchecked, and what will happen if the user activates that checkbox. This semantic information provides the context that the user needs to operate the website.
To deliver that information effectively, websites need to use a common framework. That’s the purpose of the accessibility tree: It ensures that every website provides the same type of machine-interpretable metadata so that assistive software works as expected.
The accessibility tree includes four properties for each element:
- The name of the element.
- A description of the element, which provides more context than just the name.
- The role of the element, which describes what kind of object it is (such as a button or a checkbox).
- The state of the element, where applicable (such as whether a checkbox is checked or unchecked).
The best way to provide these properties is to use native HTML. HTML is widely understood by all types of assistive technology, and with a few exceptions (namely, the <div> and <span> elements), HTML is semantic.
Plain old semantic HTML (or POSH) is the best tool for developing an accessible website. However, it’s not the only tool available.
CSS (Cascading Style Sheets) properties can also affect the accessibility tree. For example, display:none can remove an element from the accessibility tree completely, which may improve the experiences of AT users in some cases. JavaScript can also change the state of elements, which is reflected in the accessibility tree.
Related: What "Programmatically Determined" Means for Accessibility
WAI-ARIA and the Accessibility Tree
Sometimes, an element cannot be defined with native HTML. This is especially true for dynamic (regularly changing) content. When this is the case, developers can provide semantic information via WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications).
WAI-ARIA markup is designed specifically for communicating semantic info to assistive technologies. It’s extremely powerful, but when used improperly, it can introduce accessibility issues. For that reason, we strongly recommend working with an accessibility partner when writing and testing WAI-ARIA markup.
Related: Don't Use ARIA to Fix Broken Semantics
How do I view my website’s accessibility tree?
You can view your website’s accessibility tree via the developer tools included with most major web browsers. An important note: If you’re not familiar with website DOMs, you might find the information overwhelming or confusing.
Here’s how to view the accessibility tree in Firefox or Chrome:
- In Google Chrome, right-click on a webpage, then click Inspect. Select the Accessibility tab from the DevTools pop-up window.
- In Mozilla Firefox, you’ll need to enable the Accessibility Inspector in Developer Tools. Review this guide from Mozilla for enabling the Accessibility Inspector and accessing the accessibility tree.
Developers should regularly inspect the accessibility tree for issues, particularly if a website accessibility analysis reveals potential problems. It’s helpful to ask questions when reviewing the tree:
- Do all objects have appropriate names and descriptions?
- Could I understand the purpose of the object if I couldn’t perceive it visually?
- Are any important elements missing from the accessibility tree? If so, why?
- Does the accessibility tree update if I change the state of an element (for example, by collapsing a menu or clicking a checkbox)?
Remember, you shouldn’t make sweeping changes to the accessibility tree unless you understand its purpose — and you’re committed to testing your content thoroughly against the Web Content Accessibility Guidelines (WCAG), the international standards for accessibility.
If you need additional guidance, we’re ready to help. Send us a message to connect with an expert or review our Introduction to ARIA for Web Accessibility.
