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
<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
<!-- this is not a good idea --> <span class="button">I look like a button</span>
<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
<!-- 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 @
Exposing from Web Components
<button> does not suit your use-case, you can create a
At the moment, there are two ways of new element creation:
- an element based on an existing element (i.e.
, 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).
<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).