What ARIA still does not do

In 2014 I wrote an article What ARIA does not do

It stated:

ARIA is a set of attributes that can be added to HTML elements (and other markup languages) to communicate accessibility role, state, name and properties which are exposed by browsers via platform accessibility APIs. This provides a common, interoperable method of relaying the information to assistive technologies. That’s it. It is the same method used by browsers to convey the inbuilt (or default) accessibility information of native HTML features. The difference being that authors can wire up this information for themselves in the DOM using ARIA, before they could not.

10 years later, the message is unchanged.

Clarity

Little has changed in relation to what effect the addition of ARIA attributes has to the display or behavior of elements,  that have modified accessibility semantics, nothing has changed in regards to mainstream user agents (i.e. browsers). Little has changed as to how Screen readers screen readers support ARIA semantics, except that support for them has improved markedly.

Screen readers did and still do treat the element as it’s represented in the Accessibility tree:

Typical support patterns of HTML elements, with implicit or explicit roles, states and properties, by screen readers:

• Identification of an element by role as the user moves through the content.
• Announcement of the text content of an element.
• Announcement of the start and end of an element.
• Change in voice as the content of an element is announced.
• Announcement of an elements accessible name and/or description
• Announcement of states and properties.
• Emission of a beep or other sound when an element with a particular state or property receives virtual focus.
• Instructions on how to operate interactive elements such as form controls.
• Navigation of elements by keyboard and “quick access” lists of a particular elements.
• Change in how keystrokes are handled for interactive roles. Screen readers on Windows in particular, pass some keystrokes through to the browser to allow, for example the input of text into a text field. They also may change their interaction mode to support such interaction.

As it says in the Standard

1.3 User Agent Support

Aside from using WAI-ARIA markup to improve what is exposed to accessibility APIs, user agents behave as they would natively. Assistive technologies react to the extra information in the accessibility API as they already do for the same information on non-web content. User agents that are not assistive technologies, however, need do nothing beyond providing appropriate updates to the accessibility API.

For example: take the following HTML

Explicit role
<div role="main">main content</div>

vs

Implicit role
<main>main content</main>

Mainstream Browsers do not imbue <main> with any behaviour’s, while Screen readers such as JAWS provide the following interaction key strokes:

• Move to Main Region Q
• Move to Next Region  R
• Move to Previous Region SHIFT+R
• Select a Region INSERT+CTRL+R

See Jaws HTML Support for information about how HTML element semantics are supported.

All is fine and dandy as long as you keep your promises

Use of ARIA is a promise you as a developer make to screen reader users.

As long as developers implement ARIA according to its rules of use in HTML and implement interaction patterns (usually via JavaScript) that agree with the standard pattern for a particular role, all is well. When they do not there is grief.

For example if a menu role is used, there is an expectation that using the arrow keys will navigate the menu items, also the expectation is that their will be child elements with role=menuitem or menuitemcheckbox or menuitemradio to navigate. If either is not the case then the user experience will be degraded, sometimes to the point where it is unusable.

Further Reading:

• Accessible Rich Internet Applications (WAI-ARIA) 1.3
• ARIA Authoring Practices Guide (APG)
• ARIA in HTML
• Understanding screen reader interaction modes