Rules of the Game, Rules of ARIA
First rule of ARIA: Don’t use ARIA. Well, there’s a bit more to it. And also 4 other rules that don’t get the same attention for their lack of meme potential.
ARIA or WAI-ARIA stands for Accessible Rich Internet Applications.
WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with HTML, JavaScript, and related technologies.
Source: W3C.org
We love anything that is rich in accessibility! But using ARIA labels is a bit like the Nuzlocke challenge, it sounds great until you’re in the middle of it and crying.
The iconic first rule of ARIA use is: Don’t use ARIA. Or to be exact: “If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.”
So basically, don’t use ARIA labels unless you know what you’re doing. But turns out there are more than just this one:
2nd Rule of ARIA Use
Do not change native semantics, unless you really have to.
For example, we want to build a heading that's a tab:
Instead of this:
<h2 role=tab>heading tab</h2>
Do this:
<div role=tab><h2>heading tab</h2></div>I know, it looks wrong. But this is why we have the first rule in place!
3rd Rule of ARIA Use
All interactive ARIA controls must be usable with the keyboard.
If you create a widget that a user can click, tap, drag, drop, slide or scroll, the user must also be able to navigate to the widget and perform an equivalent action using the keyboard. All interactive widgets must be scripted to respond to standard keystrokes or keystroke combinations where applicable.
For example, if using role=button the element must be able to receive focus and a user must be able to activate the action associated with the element using both the enter (on WIN OS) or return (MAC OS) and the space key.
4th Rule of ARIA Use
Do not use role="presentation" or aria-hidden="true" on a focusable element. Using either of these on a focusable element will result in some users focusing on 'nothing'.
Do neither this:
<button role=presentation>press me</button>
Nor this:
<button aria-hidden="true">press me</button>Applying aria-hidden to a parent or ancestor of a visible interactive element will also result in the interactive element being hidden, so don't do this either. If an interactive element cannot be seen or interacted with, then you can apply aria-hidden, as long as it's not focusable.
If an interactive element is hidden using display:none or visibility:hidden either on the element itself or any of the element's ancestors, it won't be focusable, and it will also be removed from the accessibility tree. This makes the addition of aria-hidden="true" or explicitly setting tabindex="-1" unnecessary.
5th Rule of ARIA Use:
All interactive elements must have an accessible name. An interactive element only has an accessible name when its Accessibility API accessible name (or equivalent) property has a value.
Need a refresher on how Accessibility APIs work? Threat not, for the Pokédex of Accessibility is here for you:
For the Advanced Trainer: Mew, Mewtwo, the DOM & Accessibility Tree
In the last episode of the Accessibility Championships, we covered the basic to intermediate training strategies for building a strong accessibility testing lineup. If you need a quick refresher, visit the previous training ground before advancing to the next level: