An Accessibility Object Model for Meaningful Markup

When it comes to web accessibility, meaningful markup is important. It includes semantics for browsers so they know how various things function. Accessibility Object Model suggestions are comprised of ways to incorporate semantics right into JavaScript without markup. This article will address those suggestions and where they currently stand.

More than Just HTML

In short, markup builds accessibility trees, which describe various things on web pages to AT (assistive technologies). Using these particulars, AT can instruct the browser to “browse by heading” and perform advanced table navigation, to name a couple of examples.

There are a number of semantic elements to pick from during the development process. The HTML element set is extensive. Even if something is developed for a semantic element that doesn’t exist, reprogrammed components that integrate with current HTML elements give you several semantics at no extra cost.

At times, a single set of HTML elements is not sufficient.  You’ve conceptualized an interface without any semantic tags apparent in HTML. WAI-ARIA plays a vital role in such scenarios: with it, you can send accessibility-related details to the browser with regulated attributes (such as labels, statuses, and semantics).

Examples of helpful ARIA include:

With aria-expanded=”true|false”, you can establish the status of a button that collapses or expands content.

With role=”alert”, a live section can be converted into an element: when updating content, AT users are alerted about the changes.

Additionally, ARIA is an option, as it can convert standard elements into ones with HTML equivalents already in place (like links and buttons). This is discouraged, though – besides altering semantics, it puts developers in charge of affordances (such as keyboard activity). For example, rather than <span role=”button”>, it would be more secure to utilize <button type=”button”> and obtain keyboard activity for free. As of 2019, native buttons can be customized (ones that need accessibility bugs, such as minimized keyboard support, at least).

The benefits of AOM

If you are hypothetically creating something that goes through the ARIA rule (ARIA is only to be used if absolutely necessary), you have the option to apply markups on it. Simply add the relevant attributes. After the Accessibility Object Model is carried out, ARIA can be applied as well without markup.

The suggested AOM (Accessibility Object Model) will be a JavaScript API to let programmers change (and at some point, experiment with) the accessibility tree for an HTML page. The accessibility tree will be accessible by developers immediately. You can liken this to what Service Workers provide for the network: they offer programmers a way to regulate something that could only be performed by a browser. Regulation of such low-level aspects allows developers to try out and build new features without having to wait for the standards process. Using AOM, web components not yet present in HTML could be defined by such people.

Accessing low-level components like these provides developers with control. They also make developers accountable for accessibility, performance, and security. It can be time-consuming and challenging to assign best practices to each of these duties. To be fair, it is simpler and more logical to utilize the defaults of a browser. Expanding the internet in this way is more useful for groups that have time to dedicate to such endeavors.

At the moment, AOM is programmed by individuals from Apple, Google, and Mozilla. They have defined a quartet of project phases. Here is some information about those plans and the benefits they bring.

An end to ‘sprouting’

Interfaces ridden with advanced controls can hastily turn into an onslaught of attributes – also known as “sprouting” by the HTML spec. A disabled button, for example, may warrant aria-disabled, aria-label, and role attributes, which is quite laborious to maintain and add, markup-wise. As a solution to this, AOM will allow developers to establish element accessibility attributes in JavaScript directly.

For instance, you can establish an element with aria-expanded directly on the element:

el.ariaExpanded = true;

Before, we were only able to establish this expanded attribute by alternating the  attribute value in the markup. Using AOM, the ARIA attribute set will double as elements that DOM nodes can use, which are IDL (Interface Definition Language) attributes. Attributes are reflected by IDL markup attributes. Using the earlier example, we can deduce that, once el.ariaExpanded is set to true, an un-existing attribute can be added to el and be set to true.

ARIA attribute mapping for IDL attributes is explained further in the specifications for ARIA 1.2.

In applications containing some variation of virtual DOM, such as the ones created with frameworks like Vue and React, best practices suggest refraining from DOM and instead allowing the framework to handle DOM adjustments. In these applications, establishing semantics in the template or markup will likely remain the default method.

Relationships lacking IDs

The id attribute in HTML defines a specific element. This is utilized by form labels: we pair attributes of labels with their matching input by directing labels towards the id of the relevant field. For ARIA, there are several elements that must be directed towards an id (or many of them), such as aria-controls (one element regulates another element), as well as ARIA-describedby (one element is described by that element/those elements).

For AOM, you can connect elements with others directly by designating them as follows:

formField.ariaLabelledBy = formLabel;

The accessibility tree’s non-DOM nodes

In several specified instances, a web app might have content that isn’t present as a DOM node. For example, on a bus station’s diagram of escalators, you will see a label for every escalator. Also, an informative popup window can be widened. These details would be lost to assistive technologies in such cases. Using AOM, you can establish an accessibility tree featuring all expanded states and labels. This would then be articulated to AT, giving users better comprehension.

Ideal for testing

The AOM endeavors to use attributes of reading accessibility, too, for the sake of assessments. Using AOM, you will have the ability to access the states, roles, and names of the HTML nodes in such tests directly.

The ARIA element data can be tested by having attributes read out. Using AOM, they would interpret what has been programmed into the accessibility tree of the browser. This will perfect the testing process.

Accessibility events

We have several useful events in JavaScript that allow us to take action on user inputs like touch, keyboard types, and clicks. In several instances, there are inconsistencies between assistive technology input and discrepancy events.

Léonie Watson discussed this at the JSConf Asia 2019 conference on the topic of Web Components. She suggested movements like “swipe down” and “swipe up” should have their own definitions for each iOS VoiceOver user:

When a screenreader runs from a touch screen, the swipe down/up gestures would likely modify a slider’s value if they have been used for screenreader-centric instructions.

Since screenreader users currently use the “swipe down” and “swipe up” gestures to stimulate screenreader-centric commands, it wouldn’t be feasible for them to use those gestures again for another purpose when developing an app.

This is why AOM endeavors to carry events directly associated with assistive technologies. AT can develop regular approaches to allow the user to make conduct-particular actions, or what Apple refers to as semantic events.

Accessibility event examples:

Decrement and increment for moving from one item to another in a custom slider (such as using down/up arrow buttons)

dismiss for model overlay closure (such as pushing the ESC button)

There are concerns about AT-centric events: malware programmers are capable of using them to determine if a user has a mobile or visual disability of some sort.

Existing status

The AOM specifications are currently in development, as are the implementations. Several browsers have utilized aspects of AOM. The portions that may have been used the most are attribute reflections. This feature is most useful for Edge and Chrome attributes (enabled through about:config) as well as Safari (in the Developer menu, choose ‘Accessibility Object Model’ from the Experimental Features setting). Firefox does not support AOM at the moment.

Upon viewing the IDL tests enabled with AOM flags, you will notice your browser’s support limits based on the attribute reflection aspect of the specification.

In closing

Basic solutions are usually the most straightforward approach when you want to make your product function as best it can. For instance, for a field marked “date of birth”, you refrain from using an elegant, intricate date-picker, and instead, depend on a labeled input. Regular HTML will work well for this in the long run. Odds are it will function optimally for users and please whoever is performing an accessibility audit. However, if there are custom controls for your product that aren’t present in HTML, you should articulate the accessibility properties needed to assistive technologies.

AOM is a fascinating new proposal in which accessibility particulars obtain their own APIs, which are more advanced than current DOM approaches, such as getAttribute and setAttribute. Such methods establish and put out values that can be programmed into accessibility tree properties. However, those values don’t engage with properties on their own. It’s a notable change. With accessibility details accessed directly, we can establish markup-free properties. We can build accessibility trees for aspects that aren’t present in the DOM (such as canvas element contents). They would also be useful to test accessibility for the sake of refinement.

Leave a Reply

Your email address will not be published.

*

*

*