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
- If you can use HTML, a native HTML element or attribute, then do so.
- Do not change native semantics, unless you really have to.
- All interactive ARIA controls must be usable with the keyboard.
- Interactive controls must have proper semantics and cannot be hidden.
- 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:
-
aria-labelledby
-
aria-describedby
-
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.