Before you rack your brains to read this rather technical article, let’s first find out if it’s relevant to you: Do you build your own components like checkboxes, dropdowns, or buttons from scratch?
Yes? Then you’ve come to the right place – unfortunately or fortunately, depending on how nerdy you are.
To check your components for accessibility, you need to know what an accessibility tree is and how to read it. This will make it easier for you to optimize your components for accessibility.
Overview: How to create an Accessibility Tree from your code
Every time you open a website, your browser reads and processes the underlying code. The result is the Document Object Model (DOM).
The DOM is the heart of every website, as it’s used not only to create the visual layout but also the accessibility tree. When you interact with a website, for example, by expanding and collapsing buttons, you’re actually interacting with the DOM. Nothing happens without the DOM being aware of it. The DOM also relays updates. That’s why you can dynamically expand and collapse menus on websites, and screen readers can retrieve this information from the accessibility tree.
The DOM is therefore the foundation for everything we want to do on websites.
For beginners: What is the DOM?
We need the Document Object Model (DOM) so that we can rely on all websites functioning consistently. This is the only reason you can open and use the same website in 100 different browsers.
Developers refer to this as a programming interface. The DOM ensures that elements in an HTML document can be read, modified, added to, or deleted from.
This all sounds very abstract at first, but the DOM is nothing more than a tree that your browser creates for a website. When we talk about a tree, we mean a tree structure made up of “nodes” and “objects”.
The DOM defines:
- All HTML elements as objects (e.g., link or button)
- The properties of all HTML elements (e.g., checkbox selected)
- The methods for accessing all HTML elements (e.g., retrieving an element by its ID)
- Events for all HTML elements (Button: Click event)
Change content on your website.
Every change on your website works because you’re modifying the DOM. For example, when you expand and collapse buttons, the object’s property in your tree changes in the background. That’s why the browser knows it needs to rebuild the page and display a collapsed element.
To trigger these changes, you need a programming language like JavaScript. The following code shows how to modify an HTML element in the DOM using JavaScript.
<html>
<body>
<p id="Example"></p>
<script>
document.getElementById("Example").innerHTML = "Change!";
</script>
</body>
</html>The <script> part is particularly important for us. Here we retrieve the document object (document) and then execute a method (.getElementById(“Example”)) to change a property of the element (.innerHTML = “Change!”).
The DOM is the interface here that defines the function .getElementById(“Example”), so that all programming languages can call the same function to retrieve the element with the ID “Example” from the HTML.
Now you know 1.34% about what a DOM is and what it does. That’s enough for now!
What is an Accessibility Tree?
Your browser creates an accessibility tree from the DOM tree, which assistive technologies such as screen readers can understand.
An accessibility tree is essentially a mirror image of the DOM tree. Instead of DOM objects, it has accessibility objects. For our browser to create the correct accessibility tree for assistive technologies, the following four pieces of information must be set correctly.
The four properties:
- A name (What is the thing called?)
- A description (How is the thing described?)
- A role (Is it a button or a list?)
- A state (Is a submenu open or closed?)
HTML Element Name
An assistive technology uses the “name” provided by the Accessibility API as a label for an element.
Example: A label for a button can be provided by the text visible on the button. This is then displayed by an assistive technology such as a screen reader.
<button type="button">Send now</button>There are several ways to specify a “name” for a user interface element. Calculating the name can be quite complicated, but it’s not particularly relevant. It’s much more important to know what the element does than what it’s called.
Here you can learn more about how elements in the accessibility tree get their names.
Description of the HTML element
Some elements need more than just a name to make it clear what they are or what they do. For example, tables have descriptions. These descriptions can, for instance, explain what kind of information the table contains.
This type of description doesn’t have to be visible, however. It’s possible to use ARIA attributes like aria-describedby to set descriptions for an element that are only readable by screen readers. This is used, for example, with complex graphics. You can find more information in the WAI-ARIA section.
Role of the HTML element
The role tells assistive technologies what they are dealing with: a button, a checkbox, a list, and so on.
By default, many semantic elements in HTML have a role. Non-semantic elements in HTML have no role; <div> and <span> without additional semantics, they return “null”. The role attribute can provide semantics.
ARIA roles are added to HTML elements using role=”role type”, where “role type” is the name of a role in the ARIA specification. Some roles require that associated ARIA states or properties be specified; others are only valid in conjunction with other roles.
For example, screen readers will display `<ul role=”tabpanel”>` as a “tab panel”. However, if the tab panel does not have nested tabs, the element with the role “tabpanel” is not actually a tab panel, and accessibility is thus actually worsened.
Incorrect or missing role and state assignments are among the most common mistakes in accessibility development. Therefore, developing components yourself is strongly discouraged when alternatives exist.
State of the HTML element
The “state”… well, it communicates the element’s state to a screen reader. For example, whether a checkbox is checked or unchecked, or whether a submenu is open or closed.
Where can I find the Accessibility Tree?
In Chrome:
- First, select an element and examine it.
- Next, navigate to the “Accessibility” control panel.
- Here you can see the “Accessibility Tree” and other useful information, including “ARIA attributes”.
In Chrome, you can also view the complete Accessibility Tree at the following URL: chrome://accessibility/. Then navigate to the “Pages” section and click the “View Accessibility Tree” button.
What is this WAI-ARIA?
Accessible Rich Internet Applications (ARIA) is a set of roles and attributes that define how web content and web applications (especially those developed with JavaScript) can be made more accessible to people with disabilities.
ARIA extends HTML so that elements can be correctly passed to supporting technologies – when no other mechanism exists.
ARIA allows, for example, the creation of:
- Accessible JavaScript widgets
- Form instructions and error messages
- Communicating live page changes to assistive technologies.
However, ARIA’s first rule is:
“Is there a native HTML element [HTML5] or attribute that already has the semantics and behavior you need? Then use it instead of making an element accessible through ARIA.”
So if possible, stick to the rule of thumb: “No ARIA is better than bad ARIA.”
When might you be forced to use ARIA anyway?
- This applies if the function is available in HTML but not implemented, or if it is implemented but accessibility is not supported.
- If the design precludes the use of a particular native element because the element cannot be styled according to the designer’s wishes. (That’s why designers should also be familiar with native HTML elements.)
- If the desired function is not available in native HTML.
Simple ARIA example
The following example is from Mozilla and nicely illustrates how to use ARIA and, at the same time, how much easier life can be if you don’t.
Let’s assume we want to integrate a progress bar into our website. However, we won’t use the native HTML element, but will build one ourselves.
The code for this looks like this:
<div
id="my-progressbar"
role="progressbar"
aria-valuenow="75"
aria-valuemin="0"
aria-valuemax="100"></div>First, we need a container: a simple div. Theoretically, we could then simply style this div with CSS and connect it with JavaScript to create a functioning “progress bar”.
A simple `<div>` element has no semantics, which is a particular problem for assistive technologies. To give the element semantics, we use ARIA roles and properties.
First, we assign the element’s role using the attribute `role=”progressbar”`. This tells the browser that this element is a JavaScript-enabled progress bar widget. The other attributes, `aria-valuemin` and `aria-valuemax`, specify the minimum and maximum values for the progress bar, and the attribute `aria-valuenow` describes the current state of the progress bar. It must therefore be updated using JavaScript.
Our beam is now barrier-free!
However, programming, accessibility testing, and documentation would have been much easier if we had simply used the native HTML element:
<progress id="percent-loaded" value="75" max="100">75 %</progress>Especially since, as with all web technologies, there is no uniform support for WAI-ARIA when combining different browsers and assistive technologies. Therefore, if you use WAI-ARIA, you must test it thoroughly; otherwise, you are more likely to introduce than remove barriers!
Inconsistency between browsers and screen readers
It is normal for messages to vary slightly between different browsers and screen readers. This inconsistency arises from the different combinations of individual accessibility platform APIs, accessibility trees, and screen readers.
To ensure your website is consistently usable across different screen readers and browsers, you need to…
- Properties such as name, role, and status information are correctly passed to the Accessibility Tree in each browser.
- Every screen reader must also correctly read the information from the accessibility tree.
When testing functionality across different screen readers and browser combinations, you can expect slight variations in terminology or message order. The important thing is that all information regarding name, role, and status is announced correctly.
Bugs related to digital accessibility
A technical accessibility error is often a discrepancy between the accessibility tree and assistive technologies.
Screen reader error: Sometimes the HTML code sends the correct information to the accessibility tree, as we can see in the browser’s code inspector, but the screen reader reports something different. This is a screen reader error.
Browser bug: Sometimes the HTML code passes the correct information to the accessibility tree, but when you view the accessibility tree in the browser, the information is still not displayed. This is a browser bug.
What’s the best strategy for identifying and avoiding these errors early? Test the code with different browsers and assistive technologies!
Conclusion Accessibility Tree
Understanding what an accessibility tree is and what it does is essential for developing digitally accessible websites. As you may have noticed, HTML and a browser already do much of the work for you. Your two main tasks are:
- To decide whether it is really necessary to use WAI-ARIA
- If so, set the HTML element’s properties correctly so that assistive technologies can access it.
