The accessibility tree

At this month’s Accessible Bristol, Léonie Watson talked about improving accessibility by making use of WAI-ARIA in HTML, JavaScript, SVG and Web Components.

The talk started with the distinction between the DOM tree, which I assume all front-end developers will have heard of, and the accessibility tree. Of the accessibility tree, I had a vague idea intuitively, but, to be honest, I did not know it literally exists.

The accessibility tree and the DOM tree are parallel structures. Roughly speaking the accessibility tree is a subset of the DOM tree.
— W3C on tree types

The accessibility tree contains ‘accessibility objects’, which are based on DOM elements. But, and this is the important bit, only on those DOM elements that expose something. Properties, relationships or features are examples of things that DOM elements can expose. Some elements expose something by default, like <button>s, others, like <span> , don’t.

Every time you add HTML to a page, think ‘what does this expose to the accessibility tree?’

This could perhaps lead us to a new approach to building accessible web pages: every time you add HTML to a page, think ‘what does this expose to the accessibility tree?’.

Exposing properties, relationships, features and states to the accessibility tree

An example:

<label for="foo">Label</label>
<input type="checkbox" id="foo" />

In this example, various things are being exposed: the property that ‘Label’ is a label, the relationship that it is a label for the checkbox foo, the feature of checkability and the state of the checkbox (checked or unchecked). All this info is added into the accessibility tree.

Exposing to the accessibility tree benefits your users, and it comes for free with the above HTML elements. It is simply built-in to most browsers, and as a developer, there is no need to add anything else to it.

Non-exposure and how to fix it

There are other elements, like and <div> that are considered neutral in meaning, i.e. they don’t expose anything. With CSS and JavaScript, it is possible to explain what they do, by adding styling and behaviour.

<!-- this is not a good idea -->
<span class="button">I look like a button</span>

With CSS and JavaScript, it can be made to look and behave like a button (and many front-end frameworks do). But these looks and behaviours can only be accessed by some of your users. It does not expose nearly enough. As it is still a <span> element, browsers will assume its meaning is neutral, and nothing is exposed to the accessibility tree.

Léonie explained that this can be fixed by complementing our non-exposing mark-up manually, using role and other ARIA attributes, and the tabindex attribute.

<!-- not great, but at least it exposes to the accessibility tree -->
<span class="button" role="button">I am a bit more button</span>

For more examples of which ARIA attributes exist and how they can be used, I must refer you to elsewhere on the internet — a lot has been written about the subject.

Exposing from SVG

With SVG becoming more and more popular for all kinds of uses, it is good to know that ARIA can be used in SVG. SVG 1.1 does not support it officially, but SVG 2.0, that is being worked on at the moment, will have it built-in.

SVG elements do not have a lot of means to expose what they are in a non-visual way (besides <title> and @), and this can be improved with ARIA labels. Léonie gave some examples, and wrote a blog post about SVG accessibility which I can highly recommend.

Exposing from Web Components

Web Components, without going into too much detail, are custom HTML elements that can be created from JavaScript. For example, if <button> does not suit your use-case, you can create a <my-custom-button> element.

At the moment, there are two ways of new element creation:

• an element based on an existing element (i.e. is like , but…). It inherits its properties/roles from the existing element if possible
• a completely new element. This inherits no properties/roles, so those will have to be added by developer that creates the element.

The first method was recently nominated to be dropped from the specification (see also Bruce Lawson’s article about why he considers this in violation with HTML’s priority of constituencies, as well as the many comments for both sides of the debate).

Again, like <span> s used as buttons and with SVG, these custom elements, especially those not inherited from existing elements, scream for more properties and relations to be exposed to the accessibility tree. Some more info on how to do that in the Semantics section of the spec.

“Code like you give a damn”

Léonie ended her talk with a positive note: to build accessible websites, there is no need to compromise on functionality or design, as long as you “code like you give a damn”. This showed from her examples: many elements, like <button> expose to the accessibility trees, they come with some free accessibility features. And even if you use elements that do not come with built-in accessibility features, you can still use ARIA to expose useful information about them to the accessibility tree.

Personally, I think the best strategy is to always use elements what they are used for (e.g. I would prefer using a <button type="button"> for a button to using a supplemented with ARIA). In other words: I think it would be best to write meaningful HTML where possible, and resort to ARIA only to improve those things that don’t already have meaning (like SVG, Web Components or even the <span> s outputted by the front-end framework you may be using).