ARIA in Action: The Authoring Practices Guide

ARIA is Complex, And Why Shouldn’t It Be?

It’s one thing to understand ARIA conceptually, and another thing to be able to confidently and competently use it. While this is not an exhaustive guide on how to use ARIA, we hope to provide a base level of information that can, at the very least, make ARIA feel less intimidating than it might at first. Seeing the complexity underlying digital accessibility and its more technical details can be helpful for understanding why sophisticated accessibility solutions that understand the nuances and details involved are the only ones with the potential to make a product accessible.

 

How ARIA Works

One of the goals of ARIA is to make web applications behave like desktop applications. Without ARIA, custom elements (a search bar with a drop-down menu of autofilled options as the user types, for example – known as a combobox) are mostly unrecognizable to assistive technologies (AT), and that means that AT users would also have a hard time interacting with those elements, to the extent that, in many cases, they simply wouldn’t try. And in many cases, the primary use of the web application/website in question is the one that happens to be inaccessible due to its complexity. Correctly used ARIA infuses those elements with semantics that the AT can effectively translate to the user, thereby making them accessible.

The primary resource for using ARIA is called the Authoring Practices Guide (APG), published by the W3C[1]. The APG includes a guide to ARIA best practices, design patterns, and examples of good ARIA usage. Recently, the W3C has updated the APG to make it more user friendly; previous versions were longform text-based documents, but this one’s interface is much more graphic and interactive. It resembles more mainstream component libraries, which should hopefully make it easier for developers to use.

ARIA is made up of roles, properties, and states, which are added as attributes to a web application’s HTML to help assistive technologies understand what custom elements in that application are. A role defines the purpose of an element; a property defines a relevant characteristic of an element, such as whether or not a table’s rows or columns are sorted in ascending or descending order; and a state defines a current condition of an element, such as whether a checkbox is checked or not. The APG lets the developer know which roles, properties, and states to apply to each element, according to the design pattern provided for it.

 

A Real-Life Example – Comboboxes

A combobox is “an input widget with an associated popup that enables users to select a value for the combobox from a collection of possible values.”[2] Once you know what they are, you start to see them everywhere, and the design pattern’s page includes several examples of them.

There’s a lot of functionality in this deceptively complex element, and from an accessibility standpoint, a lot of potential issues. Text input is the behavior that most shapes a user’s interaction with the combobox (though there are comboboxes that don’t support text input, known as “select only” comboboxes), and that’s where the visual focus stays throughout the interaction. The text input serves as a trigger for the popup menu, and it can act as a filter for a set of predetermined options or be an arbitrary value determined by the user. Autocomplete behavior is another factor that influences combobox complexity. This refers to the nature of possible values presented by a popup and the way they are presented. There are four possible options, and they all require different ARIA labels to effectively present them to AT users. Without the ARIA, these are entirely inaccessible.

 

How We Use ARIA Affects User Experience – Grids vs. Tables

ARIA can also be important when distinguishing between elements because it dictates the way users interact with them. Tables and grids, for example, look more or less the same to sighted users, but for anyone relying on AT to interact with them, the user experience (UX) for each one is very different. A grid is a container that enables users to navigate the information or interactive elements that it contains using directional navigation keys, such as arrow keys, Home, and End. It can be used to group elements together (layout grids) as well as present detailed data as a spreadsheet (data grids). The range of possibilities is wide, but all grids share the way they’re navigated and the way the visible focus behaves within and around them.

A table, on the other hand, is “a static tabular structure containing one or more rows that each contain one or more cells; it is not an interactive widget.” However, tables can and do present a combination of information and interactive widgets within them, and each element is considered separate. That means that tables are navigated just like the rest of the page – via the tab key. For tables, usually the native HTML table element will be sufficient for labeling the table itself, and ARIA is used for making sense of the logical order of rows, columns, and any interactive widgets within them.

While visually, grids and tables are similar, if a table contains a lot of information or interactive elements, a user may have to press the tab key many times to get through it. In that case, the UX would be vastly improved by making that table into a grid. By doing so, the user would have the option of navigating out of the grid by tabbing out of it, instead of essentially being trapped inside it. And the only difference between those two scenarios is the correct application of ARIA.

 

No ARIA Is Better Than Bad ARIA

ARIA is a powerful tool, and it can make or break the UX for someone who uses assistive technology to interact with web applications. It’s much better for someone to come to a website, realize it’s inaccessible, and go elsewhere, than it is for them to try to use a website that seems to be accessible, only to have a frustrating experience at best, and inadvertently do something that has negative consequences at worst (see our blog about data privacy and accessibility, for example).

But that doesn’t mean we should avoid using it for fear of messing up. It means that we need to be thoughtful about how to apply ARIA and stick closely to the APG’s recommendations to make sure we’re doing it correctly. When in doubt about which design pattern to follow, consult with experts. And importantly, testing your product for accessibility to reveal any misapplications of ARIA is vital. We’re more than happy to help you with that.

As arguably the most technical aspect of digital accessibility, ARIA can be intimidating, especially with statements like “no ARIA is better than bad ARIA[3],” but we’re here to help you understand why it’s important and worthwhile anyway, and to relieve some of the fear about getting it wrong. ARIA is a necessary part of digital accessibility (at least for the time being), and thorough accessibility testing must accompany it.

 

 

 

[1] See here

[2] As defined by the W3C here

[3] See here