Skip to content
tallylibrary

Introduction to ARIA

5 minute read

Last updated:

Accessible Rich Internet Applications (ARIA) are a set of special roles and attributes that help make some websites easier to use for people with disabilities. ARIA adds to or replaces semantics on HTML elements that are being used in a different way than intended, such as an image being used as a button. ARIA should only be used when the native HTML elements do not convey the intended use.

Overview

Section titled “Overview”

When developers use native HTML elements as intended, ARIA is not needed. For example, a <button> element provides everything a screen reader user needs to use the button. But when a developer uses an <img> element for a button instead of a <button> element, they need to use ARIA.

ARIA attributes supplement HTML. They can be added to HTML tags such as <div> or <span> to help tools like screen readers understand how to use the elements.

ARIA attributes are a key component in accessibility. They help users of assistive technology connect with different tools. They also give more information about online content for these tools. ARIA can improve user interaction for people with disabilities, especially people who rely on screen readers and keyboard navigation. ARIA can also make components more understandable for people who use assistive technology.

ARIA attributes must be implemented according to specific guidelines to ensure they are used correctly and effectively. In addition, the overuse of ARIA elements can make content less usable for people with disabilities.

Who is Helped

Section titled “Who is Helped”

ARIA primarily helps users of assistive technologies, including people who rely on:

  • Screen readers
  • Keyboard users
  • Speech recognition software
  • Other adaptive technologies

Many different people with disabilities use these tools, including:

  • People who are blind or have low vision
  • People with motor skills disabilities
  • People with dyslexia and other reading disabilities

ARIA helps make the web more accessible. It provides necessary information for assistive technologies. These attributes help assistive technology users understand interface components. They show the structure and purpose clearly. This makes it easier for users with disabilities to navigate and interact with web content.

Types of ARIA

Section titled “Types of ARIA”

ARIA provides three different types of attributes that add meaning to HTML elements. Each type has a unique role. Together, they give assistive technologies details about an element. This includes what it is, its state, and its label if it’s missing.

The following sections describe the different roles, states, properties, and labels.

  • Roles describe what type of user interface element something is, such as a button, tab, or dialog.
  • States and properties give more details about the element. They show if it’s expanded, checked, or disabled.
  • Labels give clear names to elements. This helps assistive technologies announce them, even if the element lacks an accessible name.

Guidelines

Section titled “Guidelines”

ARIA can be helpful. However, it can also cause cognitive overload and can break functionality if not used properly. To avoid this problem, there are certain rules to using ARIA attributes responsibly. These are:

Use native HTML elements

Section titled “Use native HTML elements”

Use a built-in HTML element when it can already do what you need. Elements like buttons, links, and inputs come with built-in keyboard controls and screen reader support. If you create your own using a <div> and ARIA, you’ll need to carefully add all that behavior yourself. It’s easy to overlook a small detail, which can lead to big problems for screen reader users.

Example: Use a real button element to say submit. Do not use a <div> with a button role and a tabindex attribute.

Do not change what an element means

Section titled “Do not change what an element means”

Avoid overriding an element’s default meaning unless you have a good reason to do otherwise. Each HTML element defines what sort of UI element it is, and what kind of accessibility information it provides by default. A heading announces itself as a heading, and a button as a button. Adding a conflicting role simply adds noise.

Example: Let’s say you want to make a heading behave like a tab. You shouldn’t erase its default role as a heading to give it the role of a tab. You can achieve your goal by putting the heading inside an element with the tab role instead.

Make sure everything is keyboard-accessible

Section titled “Make sure everything is keyboard-accessible”

Anything you make keyboard accessible by adding ARIA roles and states should also be fully accessible by keyboard.

If a user can click, tap, drag, fling, scroll or otherwise manipulate something with a keyboard, it should act like a keyboard widget. It should respond to the keys that are expected to be used with it.

Example: When using role="button", the element must be focusable. Users should activate it with the Enter key or Spacebar, just like a native HTML button.

Never hide something that can be tabbed

Section titled “Never hide something that can be tabbed”

Do not apply a presentation role or the aria-hidden attribute to elements that is keyboard accessible

Doing so hides the element from assistive technologies. This is worse than just not labeling the element at all, since tabbing to it will result in the user hearing nothing at all. It is much better to allow the element to be announced as unlabeled, but still keyboard accessible and predictable in its behavior.

Example: Do not put a presentation role or aria-hidden on a keyboard accessible button that still says “Press me”. All elements that can be tabbed to should be announced to screen readers, to provide a self-consistent UI to keyboard users.

References

Section titled “References”