Browsers, code and assistive technologies

Understand how web browsers, code and assistive technologies work together to render web content that meets the needs of assistive technology users, and how this depends on HTML markup.

How information flows between the browser and assistive technologies

The following describes at a high level how web content is made available to users of assistive technologies (AT) — see more details in the sections below.

The web browser creates the Document Object Model (DOM) out of the HTML markup and other resources.
From the DOM, the browser creates the accessibility tree, a model of the page’s contents where user interface elements are represented as accessible objects.
The browser communicates the accessibility tree to the operating system’s built-in accessibility application programming interface (API).
The accessibility API makes the accessibility tree available to assistive technologies (AT).
AT use the accessibility API to:
- read the accessibility tree and present its content to the user in a suitable format, for example, as speech.
- send commands to the browser to interact with the content, such as press a button.

For an introduction to AT, see Types of assistive technologies and who uses them — Knowledge Area: Assistive technologies.

Document Object Model (DOM)

When a web browser loads a web page, it downloads the HTML and associated resources, such as CSS, JavaScript and image files. From these, it constructs the Document Object Model (DOM).

The DOM is a representation of the HTML document’s contents as a hierarchical tree of objects. The DOM tree contains all the objects that make up the content in the web page, including the different HTML elements that provide the content’s structure, meaning and functionality.

The browser uses the DOM as the basis for what it presents to the user. The visual interface that’s displayed in the browser’s main window is a graphical and interactive representation of the page’s DOM. Its visual presentation is informed by the page’s Cascading Style Sheets (CSS), and additional functionality is provided through the page’s JavaScript. But the DOM, as a programmatic representation of the web page, can be presented to users in whichever ways that software and hardware are able to present it, for example, through speech or touch.

The contents in the DOM tree change as the user interacts with the web page, or as content is added, removed, or modified via JavaScript. To see how this works, see Inspecting the DOM.

The DOM is also an API that allows developers to manipulate and interact with the HTML document using JavaScript, querying or modifying its properties, and creating, destroying or moving objects in the DOM in order to, for example, present new content to the user or respond to some user action.

For more on the DOM, see:

For all the details on how browsers render web pages, see:

Accessibility APIs, trees, and objects

The DOM itself is not an efficient API for making web content accessible through all the different AT that people use. Instead, the browser and AT communicate with each other through another API and tree that are specially for accessibility.

Accessibility APIs

Every operating system (such as Windows, macOS, iOS or Android) has a built-in accessibility API that acts like an intermediary between software applications, such as a web browser, and the AT that someone is using on their device.

In a web context, the accessibility API enables the web browser to communicate information about the web page to AT, and AT to send information and commands back to the browser.

Examples of information that the browser conveys to AT via the accessibility API

the web page has finished loading
the title of the web page
a level 3 heading
a button with a name of ‘Submit application’
a link that the user just clicked

Example of information that AT conveys to the browser via the accessibility API

When a speech recognition software user says: “Click Submit application”, the AT submits a command to the browser, via the accessibility API, to click the user interface element named ‘Submit application’.

For an overview of accessibility APIs and their history, see Accessibility APIs: A Key to Web Accessibility — Smashing Magazine.

Accessibility tree

To make information about a web page available to AT through the accessibility API, the browser creates another hierarchical tree. This ‘accessibility tree’ is the model of the web page that’s presented to AT.

The accessibility tree is based on the DOM tree, but generally contains only information that’s relevant to AT. Not every element that’s in the DOM will necessarily be in the accessibility tree, such as elements without any semantics. On the other hand, the accessibility tree may contain elements that are not in the DOM tree, such as Shadow DOM elements that comprise some more complex components — for example, the play, volume, and other controls in the <video> element.

For more on the accessibility tree, what it includes, and how it works, see:

Accessible objects

In the accessibility tree, UI elements in the web page that are important from an accessibility perspective are represented as ‘accessible objects’.

There are 4 bits of information that an accessible object can typically include about the element it represents:

Role: This is what the associated element is or does.
Name (or accessible name): This is the name by which AT identify and refer to the element. It may or may not be visible. An accessible name is critical for some elements, especially interactive components, but not every element needs or should have an accessible name.
Description (or accessible description): This is an optional, additional description about the associated element. It may or may not be visible.
States and properties: These provide extra details about the associated element.

Depending on the operating system’s accessibility API, accessible objects can also include other information, such as details about an element’s visual text formatting.

Accessible objects are created in the tree based on their HTML markup. If a UI element’s accessible object needs to have a certain role, name, description, state or property to be accessible, but that information is missing in the code, some people will not be able to understand or interact with the UI element. To check the information associated with each accessible object in a web page, see Inspecting the accessibility tree.

For more on accessible objects, see Building up accessible objects — Semantics to Screen Readers — A List Apart.

Design and develop for the accessibility tree

The experience that AT users have reading and interacting with a web page depends on how well the page content is represented in the accessibility tree, which is based on the DOM, which, in turn, is based largely on the page’s HTML markup.

While JavaScript and CSS are also used in ways that impact the accessibility tree, correct semantic HTML markup is critical for ensuring that web content is faithfully represented in the accessibility tree and presented to AT users. This is why semantic HTML markup is so important.

For each piece of content, ask the following questions, and then apply the HTML markup (and any relevant JavaScript or CSS) accordingly:

What is its role?
Does it need an accessible name? If so, what is it? Note that interactive elements always need an accessible name.
Does it need an accessible description? If so, what is it?
Does it have any states or properties that need to be defined?

To learn more about how to ensure that the name, role, states and other aspects of UI elements are faithfully represented in the accessibility tree, see the following Knowledge Areas:

For more on the importance of semantics and HTML, see the Knowledge Area: Semantics and markup.

Inspecting the DOM

Use your web browser’s developer tools to inspect the current state of the DOM for the page you are viewing.

Chrome: Get Started With Viewing And Changing The DOM — Chrome Developer
Safari: Elements tab — Safari Developer Help
Edge: Get started viewing and changing the DOM — Microsoft Docs
Firefox: Page Inspector — MDN Web Docs

Inspecting the accessibility tree

Use your web browser’s developer tools to inspect the accessibility tree for the page you are viewing. Check the accessible objects in the tree and their names, roles, states and other characteristics. Are they correct for the content that they represent?

Accessibility Object Model (AOM)

The DOM API enables developers to alter a web page’s content, structure and functionality by using JavaScript to modify objects and their properties in the DOM tree.

However, where the accessibility tree is concerned, there’s currently no way to do the same thing with accessible objects. That is, we cannot use JavaScript to directly update the properties of an object in the accessibility tree, such as its name, role, or states. Instead, to change the semantics of an element as represented in the accessibility tree, developers need to add ARIA attributes or modify the DOM in some way that exposes the desired semantics in the accessibility tree.

Note: Accessible Rich Internet Applications (WAI-ARIA), or just ARIA, is a W3C technology for programmatically adding semantic information about content — such as its name, role, state or other properties. ARIA is intended to be used when the host markup language — for example, HTML — does not include elements or attributes with the semantics needed to represent the content.

When ARIA is used correctly, it enables assistive technologies (AT), especially screen readers, to relay the necessary semantic information about the content to the user.

As a rule, do not use ARIA if a native HTML element or attribute with the needed semantics or features already exists.

For more information, see:

Fortunately, work is progressing on a new API called the Accessibility Object Model (AOM). The AOM will allow programmatic access to the accessibility tree with JavaScript, much like the DOM API provides programmatic access to the DOM tree.

For more on the AOM, see: