Rules of ARIA Use

ARIA and this Guide

I need to start with a disclaimer on this topic. WebAIM has a very comprehensive guide on ARIA, its rules, and specifics. If you want to read the very technical details please visit the included link to WebAIM in the links section. What this guide will include is my curated version of the ARIA specifics and good practices I've used over the years. I'm going to focus more on ARIA roles for form enhancements because that's the most common use in our industry. The most important advice I can impart on this topic is that if there is a native HTML element available then use that instead of an ARIA role value.

Rules of ARIA Use

1. If you can use HTML, a native HTML element or attribute, then do so.
2. Do not change native semantics, unless you really have to.
3. All interactive ARIA controls must be usable with the keyboard.
4. Interactive controls must have proper semantics and cannot be hidden.
5. All interactive elements must have an accessible name.

The label tag has some constraints. It can't assign multiple labels to one form control or link one label to multiple form controls. In some situations, there may be no visible text label available for a form control.

However, most of these labeling limitations can be addressed using three ARIA properties:

1. aria-labelledby
2. aria-describedby
3. aria-label

aria-labelledby

A label declares, "I am a label for this form control" by referencing the form control's id attribute value:
label for="fname"

With aria-labelledby, the form field references the id attribute of the text that acts as its label:

input aria-labelledby="fnamelabel"

The form control declares, "I am a control labeled by this element."

This guide is trying its best not to be a technical guide for coding but I did want to include one example of the aria that is useful. As usual WebAIM does a way better job of explaining Accessible Forms, so I'll defer to them as a reference. Just remember that these options are available should this come up in testing.

Button Enhancements

The semantics of buttons can be enhanced for buttons that have specialized functions.

To enhance the semantics of buttons with specialized functions:

Using button aria-haspopup="dialog" prompts screen readers to announce that the button triggers a dialog window. Other aria-haspopup values such as menu, listbox, tree, grid, and true are also available. Ensure adherence to ARIA Design Patterns.

For buttons that expand or collapse content, commonly known as disclosures, zippies, or accordions, button aria-expanded="true | false" can be employed. Setting the appropriate values informs screen readers about the button's state and the availability of subsequent content.

When dealing with toggle buttons, button aria-pressed="true|false" indicates whether the button is currently pressed/active or not.

Decorative and Presentational Elements

The role="presentation" attribute strips an HTML element of its default semantics, rendering it similar to a div or span. This is helpful when an element is employed solely for controlling presentation or layout, or when its native semantics aren't suitable. Common scenarios include layout tables, lists used for presentational structure, and svg elements that don't require alternative text.

Hiding content from screen reader users

The aria-hidden="true" attribute conceals specific content from screen readers. While there are limited scenarios where aria-hidden is necessary—typically, if content is visible on the page, it should be accessible to screen reader users. However, in instances where significant content repetition should be avoided or for elements not intended for screen reader presentation, aria-hidden="true" can be utilized.

Back to top