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 standard links, inputs, dropdowns, and buttons available in HTML and adding menus, grids, tab panels, tree views, and more. ARIA lays out how to ensure that these interfaces are accessible to people with disabilities, whether they just need to use keyboard commands or rely on sophisticated screen readers, speech recognition systems, or other assistive technologies.

With great power comes great responsibility, and it is essential to keep a few rules in mind before you start using ARIA:

1. First Rule of ARIA: Don't use it.

   Native HTML elements have accessibility built-in. So, if you need a textbox, use an input, if you need a dropdown, use a select, if you need a button, use a button. Just because you can build your own using ARIA and JavaScript doesn't mean it's a good idea -- in fact, it makes more work for yourself, your testers, and your users. (This is especially true of role="application" -- seriously, don't use it.)

2.  Second Rule of ARIA: Don't break stuff.

   If you do use ARIA, be careful not to break the built-in accessibility of native HTML. While you can use the "role" attribute to redefine a heading as a tab or a link as a button, that throws away the built-in accessibility of those HTML elements. Remember Rule #1.

3. Third Rule of ARIA: You have to make it work.

   ARIA tells assistive technologies what your component is supposed to do, but doesn't make it work. You have to add (and test!) all the JavaScript to make a menu drop down, a tree view expand, etc. And it all has to work with keyboard commands as well as the mouse.

4. Fourth Rule of ARIA: Don't hide focusable elements. 

   Remember Rule #2? If you add role="presentation" or aria-hidden="true" to an element that receives keyboard focus, you break it. This includes links, inputs, selects, textareas, buttons, and anything with tabindex="0" or greater. Don't do it.

And here are three bonus rules, learned the hard way:

1. Start with 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. 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.

2. 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. If you are considering a third-party library or framework, test their demos before you start using it.

3. Ask for Help

   ARIA can get complicated fast. If you're not an accessibility specialist, ask one for help -- 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!)
• ARIA in HTML - more technical guidance on how to use ARIA with HTML.
• ARIA 1.2 - the official standard. It's very technical, but use it if you need to. (ARIA 1.3 is coming soon.)