Meaning without markup: Accessibility Object Model

category: thoughts

Meaningful markup is essential for accessibility, because it brings semantics. In short, it tells the browser what things are. Proposals for the Accessibility Object Model include a new way to convey semantics: without markup, directly in JavaScript. In this post, we will look at the proposals and their current status.

Beyond the scope of HTML

To get a more detailed overview of how the quality of our markup impacts end users, see my previous post How accessibility trees inform assistive tech. To summarise: our markup gets used to construct accessibility trees, which inform assistive technologies (AT) about what things are on our pages. With this information, AT can offer features like ‘browse by heading’ and advanced table navigation.

There are plenty of semantic elements to choose from when we build a component. The set of HTML elements is enormous. Even if you build a new thing for which no semantic element exists, custom components that combine existing HTML elements let you have at least some of your semantics for free.

Sometimes the set of HTML elements really does not cut it. You’ve created an interface concept for which reasonably no semantic tag exists in HTML. This is where WAI-ARIA comes in: it lets you provide accessibility-relevant information to the browser using standardised attributes, including semantics, states and labels.

Some examples of effective ARIA:

There is also ARIA that can turn elements into elements for which there are already existing HTML equivalents, such as buttons and links. This is not recommended, because apart from changing semantics, it also makes affordances like keyboard behavior the developer’s responsibility. For instance, instead of <span role="button">, it is much safer to use <button type="button"> and get the keyboard behaviour for free. In 2019, styling native buttons is no longer a problem. Certainly not one that warrants accessibility bugs like reduced keyboard support.

How AOM will help

So, let’s say you are making something that passes the first rule of ARIA (paraphrased: “don’t use ARIA if it is not needed”). You could use markup for this: just add the appropriate attributes. Once the Accessibility Object Model is implemented, you could also apply ARIA without markup.

The proposed Accessibility Object Model (AOM) will be “a JavaScript API to allow developers to modify (and eventually explore) the accessibility tree for an HTML page”. In other words: it gives developers direct access to the accessibility tree. In a way, that’s a bit like what Service Workers do for the network and Houdini for style: give developers control over something that was previously done only by the browser. All in the name of an extensible web: control over these low-level features enables developers to experiment and create new things without waiting for the standards process. Perhaps, with AOM, people could define Web Components that don’t exist in HTML just yet.

Having access to low-level features like these, gives developers power (yay!). But at the same time, they also give developers more direct responsibility, regarding aspects like security, performance and accessibility. It can be tricky and time-consuming to implement best practices and fulfill all those responsibilities. Admittedly, is it easier, and often sensible, to use browser defaults. Extending the web like this is probably most practical for teams that are able to invest the time.

AOM is currently developed by people from across Mozilla, Google and Apple. They’ve defined four phases for the project. Let’s look at some of the plans and how they help.

No more ‘sprouting’

Interfaces with a lot of advanced controls can quickly become a sea of attributes, which the HTML spec calls “sprouting”. Even a simple disabled button might require role, aria-label and aria-disabled attributes. That’s a lot of attributes, not just to add, but also to maintain (in markup). To solve this, AOM will let developers set accessibility attributes of an element directly in JavaScript.

For example, to set aria-expanded on an element, you could do it on the element directly:

el.ariaExpanded = true;

Previously, we could only set this attribute to expanded by switching the value of the attribute in the markup. With AOM, the set of ARIA attributes will also exist as properties that DOM nodes can have, so called IDL (Interface Definition Language) attributes. The IDL attributes are said to reflect attributes in the markup. In the above example, that means that upon setting el.ariaExpanded to true, an attribute (if it does not yet exist) is added to el and it is set to true.

The mapping of ARIA attributes to IDL attributes is defined in the ARIA 1.2 specification.

Note that in applications that have some form of virtual DOM, like those built with frameworks including React and Vue, best practices prescribe “don’t touch the DOM, let the framework deal with DOM changes”. In those applications, defining semantics in the markup or a template will probably still be the go-to approach.

Relationships without IDs

In HTML, the id attribute uniquely identifies an element. Form labels make use of this: we associate label attributes with their corresponding input by pointing the label’s for to the input’s id. In ARIA, there are a number of properties that need to point to an id (or multiple ids), like aria-controls (this element controls that element) and aria-describedby (this element is described by this element/these elements).

With AOM, one can associate elements with other elements directly, by assigning them like this:

formField.ariaLabelledBy = formLabel;

Non-DOM nodes in the accessibility tree

In some very specific cases, a web application may contain content that does not exist as DOM nodes. For instance: drawing a train station’s map of available elevators on a canvas. Each elevator has a label, and also a informational popup that can be expanded. This information would currently be lost to assistive technologies. With AOM, you could define an accessibility tree containing all the labels and expanded states. These would then be conveyed to AT, so that users can understand them.

Good for testing

The AOM also aims to bring reading accessibility attributes. The intended use case: testing! With AOM, you would be able to access the names, roles and states of your HTML nodes directly in tests.

Tests can already access an element’s ARIA information by reading out attributes today. With AOM, they would read out what something has actually computed to in the browser’s accessibility tree. This functionality has the potential to make tests better.

Accessibility Events

In JavaScript, we have a number of useful events that let us act on user input like clicks, keyboard presses and touch. In some cases, there is a discrepancy between such events and input from users of assistive technologies.

In her talk Web Components and the AOM at JSConf Asia 2019, Léonie Watson explained that actions like “swipe up” and “swipe down” mean different things to users of VoiceOver on iOS:

When you have a screenreader running on a touch screen, the flick up and flick down gestures [developers] would probably use for adjusting the value of a slider, are already used for screenreader specific commands.

Because screenreader users already use “swipe up” and “swipe down” gestures to trigger screenreader specific commands, it would be impossible for them to use the same gestures for something else in the app you’re developing.

This is why AOM aims to bring events that are specific to assistive technologies, so that AT can design consistent ways to let the user perform certain actions. Apple calls these semantic events.

Some examples of accessibility events:

There is a large privacy concern associated with AT-specific events: malicious site owners could use them to detect if someone has a visual or mobility impairment.

Current status

The specifications for AOM are still in progress, and so are implementations. Various browsers have implemented (parts of) AOM). The part that seems to have most implementations is attribute reflection. This feature works for most attributes in Chrome and Edge (enable via about:config) and Safari (pick ‘Accessibility Object Model’ from Experimental Features setting in Developer menu). There is currently no AOM support not in Firefox.

If you look at the IDL tests with AOM flags enabled, you can see how much your browser supports of the attribute reflection part of the specification.

Wrapping up

Simple solutions are often the easiest way to get your product to work for as many people as possible. For example, when for a date of birth field, you decide against a fancy, complex datepicker and rely on a clearly labelled input[type=text] instead. Standard, boring HTML goes a long way. Chances are it will work well for users and make your accessibility auditors happy. But if your product has custom controls that just don’t exist in HTML, you will want to convey the right accessibility properties to assistive technologies.

AOM is an interesting new proposal in which accessibility information gets its own APIs beyond existing DOM methods like setAttribute and getAttribute. Those methods set and get out values that compute into properties of accessibility trees, but they don’t deal with those properties directly. It’s a subtle difference. With direct access to accessibility info, we could set accessibility properties without markup, we could create accessibility trees for things that don’t exist in the DOM (like for contents of canvas elements) and testing accessibility may improve.

Many thanks to Léonie Watson, Wilco Fiers and Havi Hoffman for their feedback on earlier drafts of this post and Anne van Kesteren for answering questions.

Comments & mentions (52)

Léonie reposted this
design.ethics.code replied: I worry that this will open the door to turn into a “just install the accessbility module” situation… and all meaningful thought will go out the window
design.ethics.code likes this
FoxFurry likes this
negi4a likes this
Romain Gervois likes this
Gerhard reposted this
Jan Skovgaard likes this
Gerhard likes this
Randall Kaemmerer likes this
Juan Olvera ???????? ???? likes this
Scott O'Really? reposted this
Alicia Jarvis (She/Her), CPACC, CSM ???????? reposted this
Kathleen McMahon likes this
Scott O'Really? likes this
Alicia Jarvis (She/Her), CPACC, CSM ???????? likes this
diversity likes this
Johan 23 Jul 2019 10:58:00

First of all, thanks for teaching me about `role=“alert”`, I am going to use that for a piece of UI which I call the messaging stack.

Second, I love the idea of associating labels with form elements through Javascript. This would solve the problem of it just not being done in practice.

Things like this and the “sprouting” as described also keep markup cleaner and easier to transport from project to project.

I see this AOM thing as a modernization of ARIA, which obviously needs modernizing. Nobody is an expert, any ARIA question lead to a lot of other questions, and the different screen readers that react to ARIA all do in different manners.

If we have a way forward, we can have new implementations, that will hopefully be a bit clearer, and live in a world that cares a bit more about accessibility than it used to.

accessibility= reposted this
Roel Van Gils replied: Hidde demystifies the Accessibility Object Model. #a11y
Ghent Inclusive Design Meetup likes this
Michael Hastrich likes this
Koen Kivits likes this
Nikolay Cholakov????4❤ reposted this
Nikolay Cholakov ???? 4 ❤ likes this
Anneke Sinnema likes this
Paul Grenier likes this
Baldur Bjarnason @baldur@toot.cafe replied: “Meaning without markup: Accessibility Object Model” hiddedevries.nl/en/blog/2019-0…
Mozilla Hacks replied: Interested in the future of accessibility? - learn about AOM as it evolves...
Alan Dalton likes this
Access42 replied:
En complément, Hidde de Vries a récemment publié un article sur le même sujet ! hiddedevries.nl/en/blog/2019-0… #a11y #accessibilité
Francoise Conil likes this
Stefan Hoard ???????? reposted this
jail likes this
Stefan Hoard ???????? likes this
razh likes this
Peter Galiba replied: hiddedevries.nl/en/blog/2019-0…
Frontend Daily replied: Meaning Without Markup: Accessibility Object Model - hiddedevries.nl/en/blog/2019-0…
Bruno Gonçalves likes this
Satoshi Takeda replied:
AOM hiddedevries.nl/en/blog/2019-0…
Веб-стандарты replied: Смысл без разметки: AOM, объектная модель доступности. Хидде де Врис про новый JS API, который позволит считывать и изменять дерево доступности в браузере непосредственно, а не через DOM, как это происходит сейчас — hiddedevries.nl/en/blog/2019-0…
Geoffrey Crofte ???? ???????? replied:
Meaning without markup: Accessibility Object Model hiddedevries.nl/en/blog/2019-0… A way to create an Accessibility "tree" with no real DOM. (like in the canvas element)
Web Axe replied: I'm totally opposed to AOM. The title of this article itself is a clue (for 1 reason) why it's a bad practice. "Meaning without Markup: Accessibility Object Model" hiddedevries.nl/en/blog/2019-0… #aom #a11y #webdev
Arnaud Delafosse replied: AOM or Accessibility Object Model is on its way, some fear it may cause new #a11y, privacy and security issues. ⤵️
Renaud Berthier reposted this
Marco Zehe replied: If you've ever wondered what the Accessibility Object Model is, what's behind the standardization etc., @hdv recently wrote a good summary about it. See his original tweet:
Marco Zehe replied: If you've ever wondered what the Accessibility Object Model is, what's behind the standardization etc., @hdv recently wrote a good summary about it. See his original tweet:
Mashal Waqar likes this
Jeremy Keith replied:

Meaning without markup: Accessibility Object Model

Hidde gives an in-depth explanation of the Accessibility Object Model, coming soon to browsers near you:

In a way, that’s a bit like what Service Workers do for the network and Houdini for style: give developers control over something that was previously done only by the browser.

Adactio Links replied: Meaning without markup: Accessibility Object Model hiddedevries.nl/en/blog/2019-0…
Sami Keijonen replied:
Accessibility object model. hiddedevries.nl/en/blog/2019-0…
Hidde de Vries (@hdv) is a freelance front-end and accessibility specialist in Rotterdam (NL), conference speaker and workshop teacher. Currently, he works for the W3C in the WAI team (views are his own). Previously he was at Mozilla, the Dutch government replied:

Wow, the year only has 8 days left! Time for a review.

Like last year, I’ve divided this into highlights and things I learned.

Highlights

Projects

In the first half year of 2019, I continued my project at Mozilla’s Open Innovation team, building their People directory, and worked in the City of The Hague on accessibility and the internal design system.

In July I started a new project: at the W3C’s Web Accessibility Initiative (WAI), I am now working as part of the European Commission-funded WAI-Guide project. My work there is focused on improving the accessibility of/in tools that create web content, like CMSes. In short: we want more accessibility both for content editors (a good editing experience) and for end users (good output).

Apart from my work at the W3C, I’ve been doing the occasional WCAG audit and accessibility/CSS workshop in my own capacity too.

Speaking

Last year I spoke at my first conference. This year I got the opportunity to do new (and some older) talks in various places.

In March, I did a talk called It’s the markup that matters at De Voorhoede. It was part of their Future Proof Components event, and covered building accessible components, accessibility trees and the AOM.

At WordCamp Rotterdam and Inclusive Design Ghent, I shared 6 ways to make your site more accessible, based on my experience looking at common accessibility problems that front-end developers can do something about.

In October, I presented a very short lightning talk at the Web We Want session at View Source Conference, about how some accessibility problems could cease to exist if browsers would automatically fix them. The problems: zoomability, readability, color contrast and focus indication (the first three are each solved in at least one browser, the fourth has not). This talk, shockingly, won both the jury and audience award.

Also in October was a talk called Breaking barriers with your CMS at the Fronteers Jam Session (on behalf of W3C/WAI). This presented some of my recent work at WAI: it explained ATAG and the role of the CMS in accessibility efforts.

At the Design in Government Conference in November, I talked about the case for web accessibility from philosophical ethics, attending on behalf of W3C, and I did an updated version of my graphic design on the web talk in Dutch for Freshheads in Tilburg.

Then in December, I joined dotCSS to talk about the history of CSS: On the origin of cascades put some of that in a Darwin-themed talk. The venue was enormous and intimidating, and there was transport strikes, but the event itself was excellent, with a great atmosphere and very well organised.

I also did a number of in-house talks and workshops, about CSS Layout, ARIA and accessibility guidelines.

Reading

I read much more than last year (72 books so far), and have written more about books on this blog (see reading list about equality and reading list about tech and society). Reading more books helped me read less social media, watch less video and generally relax more.

Some notes:

  • Audiobooks are great as you can read them in situations where holding a book doesn’t work (e.g. walking a dog, housework)
  • To read more, finding the right books is half of the work (I mean, not literally… but it is important). I found more people to follow on Goodreads, keep a close eye on the literary supplements in the papers and love posts like 2018: books in review by Karolina Szczur.
  • Dutch libraries have ebooks and audiobooks that can be ‘borrowed’ via apps.

Writing

This year marked over 100 posts on this blog, I wrote 24 posts (including this one).

Some posts that people found interesting:

I also contributed to the Mozilla Hacks blog, writing Indicating focus to improve accessibility and How accessibility trees inform assistive tech. Thanks to Havi Hoffman for the opportunity!

Cities

This year I traveled to Antwerp, Berlin, Bristol, Essen, Ghent, Nice, Paris, Taipei and Vienna, using trains where possible, but I need to do better at that.

Things I learned

Here’s some random things that I learned about in the past year:

  • Recently I started working on an app with Svelte, the front-end framework that doesn’t ship in its entirety to the user’s runtime, but tries to compile as much as possible to vanilla JavaScript. Small bundles, yay!
  • As I started my project at the W3C, I learned a lot the standards process, the dynamics in Working Groups and the bots that help run teleconferences.
  • A large part of my work centered around authoring tools, or tools that create web content, and how they can help bring more accessibility in the world.
  • I became increasingly aware of the role of surveillance capitalism in the world.
  • I learned to love AirTable as a way to organise and plan the non-coding parts of my work, which are becoming a larger part of the whole

In any case, I’d like to thank the readers of this blog for reading and sharing the posts I’ve published, it means a lot. I wish you all a great 2020!

Leave a comment
Posted a response to this?

This website uses Webmentions. You can manually notify me if you have posted a response, by entering the URL below.