ARIA Accessibility: The Beginner‘s Guide to Understanding How it Works

Web accessibility has become increasingly important in recent years as more and more essential services and information move online. For people with disabilities who rely on assistive technologies like screen readers, proper accessibility can make the difference between being able to fully engage with a website or application and being shut out entirely.

One of the key tools in a developer‘s accessibility toolkit is ARIA—Accessible Rich Internet Applications. At a high level, ARIA is a way to provide additional semantics and context about UI elements so that assistive technologies can properly convey them to users. Let‘s dive deeper into what ARIA is, why it‘s needed, and how to use it effectively.

What is ARIA?

ARIA, or Accessible Rich Internet Applications, is a set of roles, states, and properties that can be added to HTML elements to describe their meaning and purpose to assistive technologies. It essentially acts as a translator, providing a common language for developers to explain complex custom UI widgets to screen readers and other accessibility tools.

You can think of ARIA like CSS for assistive tech. Just as CSS allows developers to change the visual presentation of HTML without altering the underlying semantics, ARIA allows developers to modify the accessibility semantics without changing the core HTML elements and attributes.

Why ARIA is Needed

While HTML has become much more semantically expressive with the addition of elements like <nav>, <article>, and <section> in HTML5, there are still many common UI patterns that lack native semantics, especially when it comes to dynamic content and custom widgets.

For example, there is no native HTML element for a tab panel, a very common UI pattern. Without ARIA, a set of tabs would just look like a list of links to a screen reader user, with no indication of which tab is currently selected or that activating a tab will change the visible content on the page.

ARIA allows us to bridge that gap by providing a role of "tab" and "tabpanel", a state of "aria-selected" to indicate the active tab, and a property of "aria-controls" to link a tab to its associated panel. With these ARIA attributes, the tab panel becomes understandable and operable to assistive technology users.

ARIA Roles

ARIA roles define what an element is or does. There are several categories of roles:

  • Abstract roles are used to support WAI-ARIA role taxonomy for the purpose of defining general role concepts.
  • Widget roles describe common UI widgets like sliders, menubars, tabs, and dropdowns.
  • Document structure roles describe structures that organize content in a page, such as articles, headers, or navigation.
  • Landmark roles identify regions of the page intended as navigational landmarks.

Adding an ARIA role overrides the native role semantics of an element. For instance, adding a role of "button" to a <div> will make it announce as a button to screen reader users (although it won‘t automatically make it focusable or give it keyboard event listeners—those need to be added with JavaScript).

Some common widget roles include:

  • alert
  • button
  • checkbox
  • dialog
  • link
  • menuitem
  • progressbar
  • radio
  • scrollbar
  • slider
  • tab
  • textbox
  • tooltip
  • treeitem

ARIA States and Properties

While roles describe what an element is, states and properties provide additional information about an element‘s state (e.g. if a checkbox is checked) or properties (e.g. a label for a form field).

States are used to describe the current condition of UI elements that can change, such as if a dialog is open or closed, if a button is pressed or unpressed, or if an accordion panel is expanded or collapsed. States are changed programmatically as users interact with the element.

Some common states include:

  • aria-checked (for checkboxes and radio buttons)
  • aria-current (to indicate current page in navigation)
  • aria-disabled (to indicate an element is visible but not editable or operable)
  • aria-expanded (for expandable elements like accordions and menu buttons)
  • aria-hidden (to remove elements from the accessibility tree)
  • aria-pressed (for toggle buttons)
  • aria-selected (for tabs and selected rows in grids)

Properties are used to define immutable characteristics of an element, establish relationships between elements, or provide annotations.

Some common properties include:

  • aria-controls (identifies element(s) controlled by the current element)
  • aria-describedby (identifies element(s) that describe the current element)
  • aria-label (defines string to be used as accessible name when native labeling is insufficient)
  • aria-labelledby (identifies element(s) that label the current element)
  • aria-live (indicates element will be updated, and describes the types of updates the user agents should notify users about)

ARIA live regions are elements with dynamically changing content, the updates to which should be conveyed to users, such as a status message after submitting a form. The aria-live property has three allowable values: off (default), polite (updates announced at next graceful opportunity), and assertive (updates announced immediately). The related aria-atomic and aria-relevant properties allow for further customization of when and how live region content changes are announced.

ARIA Usage Guidelines

While ARIA provides a powerful tool for making inaccessible content accessible, it can also harm accessibility if used incorrectly. Some key principles to follow:

  1. Always use native HTML elements and attributes when possible. ARIA should only be used when native HTML can‘t adequately express the necessary semantics.

  2. Never change native semantics, unless you really have to. For example, don‘t add a role of "button" to a heading just to make it focusable. Assistive tech users rely on native semantics to understand and navigate content.

  3. All interactive ARIA controls must be usable with the keyboard. If you add a role of "button", you must also add tabindex="0" to make it keyboard focusable and add keyboard event listeners for the SPACE and ENTER keys to trigger the button action.

  4. Hide decorative content from assistive technologies using aria-hidden="true". This will remove the element and all its children from the accessibility tree. Be cautious not to overuse aria-hidden, as it can make content updates harder to notice for screen reader users if large sections are hidden.

  5. Always test with a variety of assistive technologies, not just screen readers. Different tools may interpret ARIA in different ways. Testing with actual users is the best way to ensure your ARIA implementation is working as intended.

Example ARIA Code Snippets

Here are a few examples of common ARIA patterns:

Simple tab panel:

<ul role="tablist">
  <li role="presentation">
    <a role="tab" id="tab1" href="#panel1" aria-selected="true">Tab 1</a>
  </li>
  <li role="presentation">  
    <a role="tab" id="tab2" href="#panel2" aria-selected="false">Tab 2</a>
  </li>
</ul>
<div id="panel1" role="tabpanel" aria-labelledby="tab1">
  <p>Content for Panel 1</p>
</div>
<div id="panel2" role="tabpanel" aria-labelledby="tab2" hidden>  
  <p>Content for Panel 2</p>
</div>

Button with pressed state:

<button type="button" aria-pressed="false">
  <span class="on">On</span>
  <span class="off">Off</span>
</button>

Alert role:

<div role="alert">
  <p>Invalid username or password.</p>
</div>

Hiding decorative SVG:

<svg aria-hidden="true">
  <path d="..."/>
</svg>

ARIA and Accessibility Testing

When implementing ARIA, it‘s critical to test that it‘s working as expected with actual assistive technologies. A few testing tips:

  • Use your browser‘s accessibility inspector to view the computed accessibility tree and inspect ARIA attributes. These tools can help identify issues like invalid roles or missing labels.

  • Test with a screen reader to ensure elements are properly labeled, described, and interactive as intended. Don‘t just rely on the visual appearance.

  • Use automated accessibility testing tools like aXe or Lighthouse to catch common ARIA issues like missing or duplicate roles, states and properties that reference nonexistent IDs, and more.

  • Most importantly, test with real assistive technology users to get direct feedback on the usability and understandability of your ARIA implementation.

Conclusion

ARIA is a powerful tool for making web content more accessible, especially for complex custom widgets and dynamic content. By providing additional semantics and context, ARIA allows developers to describe UI elements in ways that all users can understand and interact with.

However, ARIA is not a substitute for good semantic HTML, keyboard accessibility, or other accessibility best practices. It should be applied judiciously and progressively, only when native HTML is insufficient.

When used properly as part of a comprehensive accessibility strategy, ARIA can help ensure your website or application is perceivable, operable, and understandable for all users, regardless of ability. Isn‘t that what the web is supposed to be all about?

Similar Posts