Today, I learned about the “accessibility tree.

I am not sure who attribute this diagram to, but I borrowed this from Marcy Sutton.

The accessibility tree and the DOM tree are parallel structures. Roughly speaking the accessibility tree is a subset of the DOM tree. It includes the user interface objects of the user agent and the objects of the document. Accessible objects are created in the accessibility tree for every DOM element that should be exposed to an assistive technology, either because it may fire an accessibility event or because it has a property, relationship or feature which needs to be exposed. Generally if something can be trimmed out it will be, for reasons of performance and simplicity. For example, a <span> with just a style change and no semantics may not get its own accessible object, but the style change will be exposed by other means. W3C Core Accessibility Mappings 1.1

Basically, when a page renders in the browser, there is the Document Object Model (DOM) that is the underlying structure of the page that the browser interfaces with. It informs the browser that such-and-such is the title, what markup to render, and so on. It’s hierarchically structured kind of like a tree. There’s a root and a bunch of branches.

At the same time, there is an accessibility tree that is created. Browsers make them to give assistive technology something to latch on to.

When we use ARIA attributes, we are in part giving instructions to the browser about how to render that accessibility tree.

There’s a catch: not all browsers create accessibility trees in the same way; not all screen readers interpret accessibility trees in the same way; not all screen readers even refer to the accessibility tree, but they scrape the DOM directly — some do both.

Michael Schofield Michael is a deep-thinking beach-bum developer librarian doing and writing [sorta] impressive things around design, development, and the user experience. You should ask him to speak or do a workshop.