Accessibility Object Model Explained

Accessibility Object Model is a project undertaken by the W3C that aims to improve the experience of using an assistive technology device.

Here, developers would provide information to assistive technology APIs, making it easier to navigate the web (along with the information that browsers already provide to these APIs).

This new information will be stored in a JavaScript API called Accessibility Object Model (AOM). AOMs are currently developed across Mozilla, Google and Apple.

Before We Start

It is important to understand that as you develop a website, make sure to use semantic landmarks like <head>, <main>, <footer> and ,<nav> in your code. This ensures that pivotal sections of the website are easily navigable by assistive technology devices, like a keyboard or screen-reader..

Furthermore, add ARIA roles to these landmarks. For example, for <header>, which is defined as your website’s global site header, its ARIA role would be ‘banner’. This ensures that the assistive technology device clearly understands what it needs to do, as it encounters these landmarks.

Adding ARIA roles to all the actionable elements (of all landmarks), meant to be interpreted by an assistive technology device, is a better practice.

AOM Implementation

The W3C plans to implement Accessibility Object Model (AOM) using the following:

1. Accessibility Tree

Assistive technology devices primarily interact with an accessibility tree, when interpreting a website.

An accessibility tree is a modified DOM (Document Object Model) tree, created by the browsers, which has very few images but a lot of text and links. An accessibility tree is hosted inside the AOM API.

In the case of apps, they directly expose the semantic version of their UI in terms of an accessibility tree to assistive technology devices, using the AOM API.

The assistive technology devices use this information to create an alternate user interface (like a spoken interface) of the UI, which is then presented to the user.

As the user interacts with the interface, this information is then passed to the app using the API. The app then interprets this user action appropriately.

Also, when creating elements, always use the native version of it instead of ‘div’.

Properties of an accessibility tree: (with real-life examples)

1. name

How do you call the element? A link here with the text ‘Click Here’, will have ‘Click Here’ as its name.

2. description

What is the element about? When inserting a table, have a description explaining the table contents.

3. role

What kind is it? Is this a button or a nav bar?

4. state

What state is it? Is this a checked or unchecked checkbox?

Nevertheless, accessibility tree is currently aimed at a small number of developers who create and maintain the JavaScript frameworks and widget libraries that power the vast majority of web apps.

2. ElementInternals Object

The developers when developing these new custom elements would provide the semantics using the ‘ElementInternals’ object. This object will now be used to map elements to an accessible object.

Note: If these custom elements have a conflict with previously written author-provided semantics, the author-provided semantics take precedence.

3. User Action with Assistive Technology

Keeping privacy in mind, every user action triggers a synthesized DOM. Let us explain with an example.

When a ‘decrement’ is performed using an assistive technology device, it basically refers to a vertical scroll down using the scroll bar. Thus, a ‘down’ keyboard DOM gets triggered.

Fun Fact

There are a couple of functionalities that were initially planned but not executed:

a. Accessible Node

Initially, it was planned that each DOM element would have an associated Accessible Node, where the authors can write its accessible properties.

But this was complicated to implement as questions arose. Here is a couple of them:

1. ARIA properties or Accessible Node, which takes a priority?

2. How do we standardize this across all the browsers?

b. Virtual Accessibility Node

Initially, it was also planned to have nodes that are not associated directly with any particular DOM element, but ‘virtually’. Like what’s now available in native accessibility APIs.

Nevertheless, any events fired on virtual nodes would be an immediate indication that the particular user is using an assistive technology device. Thus, due to privacy concerns this idea got dropped.

Advantages of Accessibility Object Model (AOM)

1. No Sprouting

Currently, every element requires a lot of accessibility attributes to be written. For example, a ‘disabled button’ requires a ‘role’, ‘aria-label’ and ‘aria-disabled’ attribute. With a website having a lot of elements, maintaining such a large amount of attributes in the HTML would become very difficult.

Now, AOM allows developers to set accessibility attributes of an element directly in JavaScript.

2. Non-DOM Nodes

There are many instances where web apps contain content that does not exist as a DOM. This information can not be currently picked up by an assistive technology device.

But with AOM in place, you can define an accessibility tree that contains all such labels. These can be easily interpreted by an assistive technology device.

3. Great for Testing

With all the accessibility attributes now in one place, you can easily access the names, roles and states of your nodes. Making the testing process more efficient!

If you are testing for Mac, do use the ‘Accessibility Inspector’ tool. It uses the same APIs assistive technology devices use to get information from the accessibility objects they encounter. You can download this from Xcode (from Mac App Store) for free.

4. Accessibility Events

Quite simply, any user action that a user performs using an assistive technology device is called an accessibility event.

But there are also situations where there is a discrepancy between such events and an actual input. Might sound confusing, let us explain.

Ideally when an user ‘swipes up’ or ‘swipes down’ in an assistive device, it means they are adjusting the slider.

But ‘swipe up’ and ‘swipe down’ are predefined actions in a screen reader.

To overcome such instances, AOM allows you to fix other customer actions that you can consistently apply to all the assistive technology devices.

Example: Using up and down keys in a keyboard for slider movement.

This was it! Hope you now have a good understanding of the changes AOMs (Accessibility Object Model) are bringing to the accessibility landscape.

If you are one of those who want to improve your website’s accessibility, but find it too extensive and confusing, Wally is for you.

Wally simply scans your website, and points out those specific parts of your code that needs to be improved. You just have to fix these, in order to enable all of your users to have the same experience.

We ourselves offer an ‘Auto-Fix’ option, which you can instantly apply, if you wish to do so.

Furthermore, not only your website, make your organization 360° accessible. That is, using Wally you can enable all the content generated by your organization, across different departments accessible. Be it documents, code, marketing copy, images, ads, etc.

Try Wally now on a completely Free Trial, or speak to our accessibility experts now.