Websites

The Accessible Rich Internet Applications (ARIA) suite provides developers with additional tools to manage how assistive technologies like screen readers interpret website content. Developed by the W3C's Web Accessibility Initiative (WAI), the WAI-ARIA technical specification augments HTML (HyperText Markup Language) with additional roles, states, and properties, allowing authors to create custom, accessible components.

Using ARIA

The first rule of ARIA is: Don't Use ARIA.

Misuse of ARIA can cause more harm than good. When possible, use semantic HTML.

Consider a button element as an example. Using native HTML, the code for a button reinforces its semantics:

<button>Confirm</button>

Screen readers announce both its name ("confirm") and its role ("button"). Browsers provide generic styling for the button. It's focusable: users can tab to it with the keyboard. Pressing Enter or Spacebar while the button is focused will activate it.

Using ARIA, an author can create a custom button:

<div role="button">Confirm</div>

Again, screen readers announce both its name ("confirm") and its role ("button"). However, browsers do not provide any additional styling. Moreover, it's not focusable and keyboard access is not provided by the browser. Authors must not only style it to make it look like a button, but also ensure that it is focusable and handles both Enter and Spacebar keyboard inputs.

With great power comes great responsibility. When you use ARIA, you are making a promise that the components you build behave as expected.

Custom Components

Some components simply do not exist in native HTML. For example, HTML does not provide a robust tree view component. Complex components like this require the use of ARIA to convey accessibility semantics to screen readers.

The ARIA Authoring Practices Guide provides a variety of design patterns for common components, including expected keyboard interaction and ARIA roles, states and properties. Use this guide as a reference and test using both the keyboard and screen readers to validate your designs.

A Note on Menus

The ARIA Authoring Practices Guide provides a pattern for menus. This pattern is typically inappropriate for websites: the ARIA menu role is intended for application menus (e.g., the File menu at the top of a desktop application). For website navigation, refer to the W3C tutorial on fly-out menus.