A Few Remarks on Using ARIA

What ARIA does (and doesn't do), and how to use it appropriately.

WAI-ARIA (Accessible Rich Internet Applications) is a recommendation defining a way to make web content and web applications more accessible to users relying on assistive technologies (including, but not limited to, screen readers). ARIA provides additional information about web elements to improve usability and understanding.

Origin story

Why do we have to bother with ARIA? Why does it exist in the first place? Why do we have to have this set of attributes duct taped over HTML? As the web became more and more dynamic and interactive, we started creating new designs and UX patterns that the native HTML elements were not conceived to support. HTML became increasingly ill-equipped to handle these new patterns and interactions, which were missing appropriate semantics.

As we strayed further and further away from the simple pages of text with hyperlinks, we began creating countless new ways to present and collect information. ARIA was created to provide semantic information for these new patterns. If what you are building follows the common use-cases that native HTML provides for, great! You don't need ARIA. Otherwise, you can build up piece by piece, using ARIA as a toolbox. Think of ARIA as the piece of HTML that allows for extra flexibility.

No ARIA is better than bad ARIA

A widespread problem with ARIA is incorrect use. You may have heard of the first rule of ARIA, which states that you should not use ARIA when you can use a native element instead. It is often summed up as: No ARIA is better than bad ARIA.

What ARIA does—the only thing it does—is to convey additional information. Native elements, on the other hand, often do more, like handling focus and keyboard behavior. That's why they should always be preferred.

On Peanut Butter

More generally, it's important to ensure that the information conveyed via ARIA is accurate. Imagine driving a car in an unknown place. Without any signage, it would be hard—impossible, maybe—to find your way. Now imagine signs at every crossroad, but many of them pointing in the wrong direction. These street signs would not make things any easier for you. On the contrary, they'd be making your experience worse. This is exactly what happens when ARIA is misused. Like carefully adding a nice "Peanut Butter" label. On the shoe polish. Mistakenly declaring a heading as a label, a link as a button, a non-interactive element as interactive, and so on, does more harm than good.

Not only can your signs be misleading, they can cover up others: an ARIA role will override any implicit role the element may have had. So the risk is not only to add incorrect information, but also to hide the correct one.

More ways to do it wrong

It is also important to ensure the ARIA attribute is added to the correct element. Let's take the combobox pattern as an example. A collapsible list of options toggled via an input or a button is known as a combobox. The component can indicate that a selection is required. Visually, this is often conveyed with a red asterisk next to the label. But this information must be conveyed to all users, not only those looking at the visual rendering. The aria-required attribute exists precisely for that purpose.

A common error is to place the aria-required attribute on the combobox button. But, aria-required is only valid on certain elements, and <button> is not one of them. This is not a technical limitation, or one due to an arcane rule that only accessibility specialists can understand. On the contrary, it proceeds from common sense. It simply makes no sense to indicate that a <button> is required. What, exactly, would be required? To click it? Likewise, aria-required doesn't belong on the <label>. A button or a label element is not a point of user input. This particular button toggles a dropdown. What is required in this case is not to toggle the list, but to select an option. Therefore it is the dropdown (the listbox element) that should be marked as required.

ARIA is a promise

ARIA enhances accessibility by providing users with additional information about web elements. However, it’s crucial to ensure that this information makes sense. Misusing attributes, like adding aria-required on a button, can confuse users and lead to accessibility issues.

ARIA is a promise you make to users relying on assistive technology. It is a declaration about an element on the page. Sometimes there are expected interaction patterns. For instance if you write <div role="button">, screen readers will announce that the element is a button, and users will expect to be able to press the space bar to trigger the action.

Takeaways

Erroneous information can be extremely confusing. Double-check before using ARIA roles, states and properties. Ensure the ARIA attribute is needed, is the correct one, and is assigned to the correct element. In doubt, ask us on #accessibility on Slack.
ARIA doesn't add any functionality. Native elements, on the other hand, often do. Always use a native element when possible. When it's not, ensure you are implementing keyboard and focus support.