Introduction to ARIA
WAI-ARIA is the W3C Web Accessibility Initiative (WAI)'s specification for creating "Accessible Rich Internet Applications." Rich Internet Applications take the web to the next level -- going beyond the links, inputs, dropdowns, and buttons available in standard HTML and adding menus, grids, tab panels, tree views, and more. And ARIA lays out how to ensure that these interfaces are accessible to people with disabilities, whether they simply need to use keyboard commands, or rely on sophisticated screen readers, speech recognition systems, or other assistive technologies.
The Rules of ARIA
With great power comes great responsibility, and it is essential to keep a few rules in mind before you start using ARIA:
- First Rule of ARIA: Don't use ARIA.
- Second Rule of ARIA: Don't break stuff.
OK, literally, it's "do not change native semantics unless you really have to." In other words, be careful about using ARIA, specifically the role attribute, to remove the meaning from a meaningful HTML element like a heading. And, don't forget Rule #1.
- Third Rule of ARIA: It's on you to make it work.
- Fourth Rule of ARIA: Never hide focusable elements.
Remember Rule #2? That means no role="presentation" or "none" on any element that can receive keyboard focus, and no aria-hidden="true" on any element that can receive focus or contains elements that can receive focus. That includes links, inputs, selects, textareas, buttons, and anything with tabindex="0" or greater.
- Fifth Rule of ARIA (a.k.a. WCAG 4.1.2): Name, Role, Value & State.
All interface elements need to have: (1) a name (i.e., label) saying what it is, (2) a role saying what it does, (3) an indication of its current value, and (4) an indication of its current state (e.g., checked, read-only, etc.) That's what ARIA is for.
And here are three bonus rules, learned the hard way:
- Check the ARIA Authoring Practices Guide
The APG provides extensive detail on how to implement almost every common interface pattern. Check it before you start coding. Pay special attention to the Keyboard Interaction section -- if a component doesn't work with all the listed commands, it's not done. And, never just browse the ARIA spec looking for a role or attribute that sounds right (it's probably not). That's what the APG is for.
- Test, Test, Test
Always test your implementations to make sure they actually work with assistive technologies. That means building in adequate time and getting additional resources if necessary. And if you are considering a library or framework, test their demos with the Keyboard Interactions in the APG.
- Don't hesitate to ask
Especially with rich internet applications, accessibility can get complicated. If you're not an accessibility specialist, ask one -- the earlier in the process the better.
Using ARIA takes commitment -- commitment to using the standard patterns that are proven to work with assistive technologies, and commitment to taking the time to learn and do it right. If you're ready to start using ARIA in your web applications, see the resources below, remember the rules above, and don't hesitate to ask for help.
- ARIA Authoring Practices Guide - coding patterns, keyboard interactions, examples, and more (start here!)
- Using ARIA - practical tips including the Five Rules of ARIA
- ARIA 1.1 - the current official standard, it's very technical, but use it if you need it
- ARIA 1.2 - coming really soon, probably better to use this than 1.1 above
- ARIA-1.3 - already under development