Accessibility Tree

Understanding the importance of the accessibility tree is crucial to learning how assistive technologies may (or may not) interact as intended with our digital products.

What is the Accessibility Tree?

The accessibility tree is a hierarchical structure utilized by the accessibility API on a user's device. This structure exposes vital accessibility information users of assistive technologies require to perceive, operate, and understand user interfaces.

The information provided by the accessibility tree includes essential information such as any names, roles, and states for form elements, links, and content in the user interface.

Why is the Accessibility Tree Important for User Experience?

Assistive technologies will only operate reliably when the correct accessibility information is provided to the accessibility tree.

If the correct accessibility information isn't provided, an assistive technology user will find using a digital product difficult or impossible.

People with disabilities depend upon various assistive technologies being sent the correct information to allow them to use our digital products.

The Concept of "Technical" Accessibility

Ensuring that User Interfaces are correctly presented to the accessibility API on our users' devices is commonly referred to as 'technical accessibility'.

Technical accessibility is essential.

It is one of the most fundamental parts of making user interfaces work for assistive technology users.

Technical accessibility is a crucial ingredient of broader usability for assistive technology users.

Ensuring our digital products can be operated effectively with a wide range of assistive technologies is foundational for enabling accessibility.

What Are Names, Roles, and States?

To guarantee a user interface is technically accessible, we need to understand what information needs to be sent to the accessibility tree.

Elements in the user interface will generally have some or all of the following properties needed to be sent to the accessibility tree.


An assistive technology uses the 'name' provided by the operating system or accessibility API as a label for a user interface element.

Example: A label for a button can be provided by the visible text inside it. This is then announced by assistive technology like a screen reader.

There are several ways to provide a 'Name' for a user interface element. In the example below, 'Send' is the name.

<button type="button">Send</button>


An assistive technology uses the 'role' provided by the operating system or accessibility API to determine what a user interface element is and how to interact with it.

Example: A user interface element needs a role to communicate if it is a radio button. An assistive technology then knows what interaction pattern to follow or announce if someone listens to the user interface.

In the example below, adding type="radio" to the <input> element assigns it a role of radio and conveys this to the accessibility API.

<label for="cats">Cats</label>
<input id="cats" type="radio" />


An assistive technology uses the 'state' provided by the operating system or accessibility API to determine what state a user interface element currently has.

Example: A checkbox input has a state to communicate if it is 'checked' or 'unchecked'. An assistive technology then knows what interaction pattern to follow or announce if someone listens to the user interface.

In the example below, adding the 'checked' property to the <input type="checkbox"> conveys the state to the accessibility tree.

<label for="dogs">Dogs</label>
<input id="dogs" type="checkbox" checked />

HTML and Semantics

Using correctly structured, validated, and semantic HTML in a user interface is integral in ensuring the correct information is sent to the accessibility tree, which helps assistive technology users perceive and understand the user interface.

The name, role, and state properties are usually included when using standard HTML elements. HTML affords us the best chance for accessibility.

WAI-ARIA and 'Faux' Semantics

Although not always advised, it may be necessary to not use standard HTML and create a custom control in some instances.

For example, a non-semantic <div> or <span> may be used to build a control instead of a standard HTML form element like a <button>.

When this happens, a faux role, state, and property must be explicitly added to that <div> or <span> (and modified, if they change) so that they are correctly conveyed to assistive technology.

This can be accomplished by using WAI-ARIA, which provides artificial semantics to user interface elements.

Example - a span with a WAI-ARIA role="button"

<span role="button" tabindex="0">Faux</span>

WAI-ARIA should be used with caution and only as a last resort when using standard HTML elements is impossible.

If used without due attention and thought, it can make a user interface more inaccessible than accessible.

We also need to be wary of inconsistent WAI-ARIA support in various browsers and assistive technology combinations.

Using WAI-ARIA without testing support means we are potentially introducing new barriers when trying to remove them.

Screen Reader Inconsistencies and Accessibility Bugs

It is normal and anticipated to have slightly varying announcements across different browsers and screen readers.

This inconsistency results from the different combinations of discrete accessibility platform APIs, accessibility trees, and screen readers.

To ensure a user interface will be consistently operable across different screen readers or browsers, you must correctly expose the name, role, and state information in the interface to the accessibility tree in each browser. After this, each brand of screen reader needs to correctly consume that information from the accessibility tree.

When testing functionality with several screen reader and browser combinations, hearing slightly different terminology or order of announcements is expected, so accessibility user acceptance tests need to be aware of this.

It is more beneficial to focus on whether what you hear from the variety of screen readers is generally consistent and the interaction is understandable. Any name, role, and state information should be correctly announced.

On Accessibility Bugs

In a classic sense, an accessibility bug is a mismatch between the accessibility tree and assistive technology.

Sometimes HTML code conveys the correct information to the accessibility tree, and we can view this in the code inspector in a browser, but a screen reader is not announcing this as expected.

This is a screen reader bug.

Another issue could be the HTML code conveys the correct information to the accessibility tree, but when you view the accessibility tree in your browser's code inspector, you can see that it has not been presented.

This is a browser bug.

The best strategy for technical accessibility is to prototype HTML early in your process and test with different browsers and assistive technology combinations to determine what markup offers the most robust assistive technology support for the feature or functionality you are creating.

How to View the Accessibility Tree

You can view what is exposed to the accessibility tree in each web browser through the developer tools.

For example, in Google Chrome:

  1. Right-click anywhere on the page and select 'Inspect' to open Chrome Developer Tools.
  2. Under the 'Elements' tab, click the 'Accessibility' tab.
  3. The first item in the list is the Accessibility Tree.

Automated Accessibility Testing Tools

Automated accessibility testing tools are helpful. Amongst other things, they tell you if the rendered code in the DOM has the correct role, states, and properties in accord with the HTML or WAI-ARIA specifications.

Note that this is not the same as telling you if the name, role, and state are correctly conveyed to the accessibility tree. The browser DOM relates closely to what is sent to the accessibility tree, but the browser DOM is not the same as the accessibility tree.

This is why testing with assistive technology is essential.

Accessible Names and Descriptions

Accessible names and accessible descriptions are vital when considering the screen reader listening experience.

Accessible Name

The 'name' part of the name, role, and state is sometimes called the accessible name.

The accessible name is a label that provides information about the purpose of a user interface element.

A button, for example, without an accessible name, will just be announced as a non-specific 'button' by a text to speech assistive technology like a screen reader.

Without an accessible name, its purpose will be unknown to the screen reader user.

Example - A button without any accessible name

<button type="button"></button>

Example - (Elided) A button utilising an aria-label to provide an accessible name

<button type="button" aria-label="Send">
<svg aria-hidden="true" focusable="false">...</svg>

Accessible Description

User Interface elements can also have what is called an accessible description.

The accessible description is an optional 'hint' that will augment any name provided for that user interface element. The hint is announced after a short delay by a screen reader.

It is not required to provide a description as a name. A user interface element is adequate. Still, it can help better communicate the purpose of any non-standard interaction.

Hints can be turned off in the screen readers verbosity settings, so never place vital information into an accessible description, as a screen reader user is not guaranteed to hear it.

An accessible description is provided through the aria-describedby attribute.

Example - using aria-describedby to provide a hint

<button type="button" aria-describedby="hint">Theme</button> ...
<span id="hint">Change colors and text to suit your preferences</span>

The Role of Design

Technical accessibility is technical by definition, but the design has a crucial role to play to help ensure key content has human-readable labels.

Content design determines the choice of labels or descriptions by deciding on terminology, voice, and tone across the product.

Content design does not solely relate to the visible text displayed in the User Interface. Therefore, it also must include text alternatives for all non-text elements of the User Interface.

For more information on naming non-text content, please refer to Alt text and Content Labels.

HTML Design is Part of Development

Developers have a pivotal role in how assistive technology operates with our user interfaces.

With some exceptions, most role and state information for user interface elements is included when we use standard HTML.

There is more than one way and some nuance in how to add an accessible name to a user interface element.

How this may be achieved will relate to the specific context and is a development choice. Accessible naming will only be successful if the developer understands accessible name calculation.

Accessible Name Calculation

Browser vendors and assistive technology vendors agreed upon an algorithm for recursively computing the name and description of an accessible object.

The algorithm is necessary to ensure information about the User Interface is reliably and consistently provided to users, regardless of the browser and assistive technology in use.

The algorithm has an order of preference for calculating the accessible name for an element. In addition, each user interface element has specific rules and pros and cons around how it can be labelled.

The Hierarchy of Methods for Providing an Accessible Name
  1. aria-labelledby
  2. aria-label
  3. <label> with "for" attribute (relates to form controls)
  4. placeholder (relates to input type text)
  5. alt (relates to images)
  6. <caption> (relates to tables)
  7. <legend> (relates to fieldset)
  8. innerText content (if applicable)
  9. title attribute
  10. value (input type button, submit, or reset)

Like the accessible name, the accessible description also has a hierarchy for calculation, and each approach has pros and cons.

  1. aria-describedby
  2. title
  3. placeholder


Each decision we make in designing and developing a user interface has effects on all users, especially those who depend on assistive technology.

Understanding how the decisions we make affect how user interface elements are communicated to assistive technologies helps us make better choices when building a Workday for everyone.

Further Information

Can't Find What You Need?

Check out our FAQ section which may help you find the information you're looking for.

FAQ Section