Document Object Model and the Accessibility Tree
On webpages the Document Object Model (DOM) and the Accessibility Tree (ACT) are used by assistive technologies (AT) like screen readers and speech recognition. They enable AT to discover accessibility information about content displayed in the web browser.
The Document Object Model
The DOM is the data representation of the objects that comprise the structure and content of a document on the web. It renders and provides interaction for elements in the User Interface (UI).
For example, if there's a <button> element, the browser will render this in the UI, making it focusable using a keyboard. With a click event handler added, the button can then be activated by clicking, tapping or pressing the space or enter keys, or using voice commands.
Example code and image for a 'Post Comment' button:
<button>Post Comment</button>
The Accessibility Tree
The ACT contains accessibility information for HyperText Markup Language (HTML) elements. Browsers create the accessibility tree based on the DOM tree. Platform specific Accessibility APIs then provide a representation of the UI that can be understood by assistive technologies.
For example, when an assistive technology is running, the browser uses the ACT to show the button's role, its accessible name and focusable state:
- role: button
- name: Post Comment
- state: focusable
A screen reader uses this information to tell the user what they're dealing with. In this case, the screen reader will use the role and name information from the ACT to inform the user that it's a "Post Comment button".
The same information is used by speech recognition software to correctly identify the intended target of a voice command. If the speech recognition user says "Click Post Comment button", the software will identify the object in the DOM that has a role of button and an accessible name of "Post Comment". The software then carries out the instruction to click on it.
The accessibility properties of the button (name, role and state) are part of the default implicit HTML semantics.
Extending HTML using Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA)
There are times when the HTML semantics need to be extended. For example, there's no way in HTML to indicate if a button is pressed.
To do this, you must apply Cascading Style Sheets (CSS) to update the visual appearance of the button for sighted people. WAI-ARIA is used to communicate the semantic change to people who use a screen reader. In the case of a button, you can use aria-pressed to indicate if a button is pressed or not using "true" or "false".
Example code that shows a "Post Comment" button is pressed using aria-pressed="true":
<button aria-pressed="true">Post Comment</button>
When the browser parses the HTML via the DOM and ACT, it recognises the aria-pressed attribute and changes the element's role. If aria-pressed is set to true, it also updates the element's state:
- role: toggle-button
- name: Go
- state: focusable, pressed
You can use WAI-ARIA to apply names and descriptions, roles and states to elements that do not natively have this information in the HTML.
Tips
Follow these tips to improve user experience for your colleagues:
- use HTML elements in the way they're natively intended
- always use semantic HTML over ARIA when it's available
There is a problem
Thanks for your feedback