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.
On this page
- How information flows between the browser and assistive technologies
- Document Object Model (DOM)
- Accessibility APIs, trees, and objects
- Design and develop for the accessibility tree
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)
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.
For more on the DOM, see:
- Introduction to the DOM — MDN Web Docs
- Appendix: HTML versus the DOM — Chrome Developers
- What is the Document Object Model — DOM Level 3 — W3C.
For all the details on how browsers render web pages, see:
- Population the page: how browsers work — MDN Web Docs
- How Browsers Work: Behind the scenes of modern web browsers — HTML5 Rocks.
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.
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.
For an overview of accessibility APIs and their history, see Accessibility APIs: A Key to Web Accessibility — Smashing Magazine.
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
For more on the accessibility tree, what it includes, and how it works, see:
- The accessibility tree — Semantics to Screen Readers — A List Apart
- How accessibility trees inform assistive tech — Hidde de Vries
- The Accessibility Tree — Ben Myers
- The Accessibility Tree — Web Fundamentals — Google Developers.
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.
- 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:
- Accessible names and descriptions
- Accessible roles, states and properties (coming soon).
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?
- Chrome: The Accessibility pane — Chrome Developers
- Safari: View node properties for a DOM node — Safari Developer Help
- Edge: Test accessibility using the Accessibility tab — Microsoft Docs
- Firefox: Accessibility Inspector — MDN Web Docs
Accessibility Object Model (AOM)
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 with the semantics needed to represent the content. When ARIA is used correctly, it enables 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:
For more on the AOM, see: