Skip to content
Accessible Technology

ARIA

Overview

ARIA is a W3C specification that stands for “Accessible Rich Internet Applications.” It consists of markup that can be added to HTML in order to communicate the roles, states, and properties of user interface elements to assistive technologies (AT). This information helps screen readers and other AT to better understand the elements on a web page and to provide a user interface that enables their users to effectively interact with those elements.

Officially the specification is named WAI-ARIA, where WAI stands for Web Accessibility Initiative, the subgroup within the W3C that developed it. However, it is typically referred to as ARIA for simplicity, and we’ve chosen to use the short version throughout this website.

Techniques

The first rule of ARIA

According to the W3C’s document Using ARIA, the “First Rule of ARIA” is:

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

ARIA should never be your first choice for a solution. Use semantic HTML first. Then, add ARIA markup as needed.  That said, if your website or application is highly interactive and includes rich, dynamic content, ARIA is likely required in order to make your website accessible.

ARIA landmark roles

One of the easiest features of ARIA to implement is landmark roles, a set of roles for identifying common regions of the page, such as the banner, navigation, and main content area. For more on this topic, see our Page regions page.

Accessible names and visible labels

Web designers and developers might want to know the label or name of an element as it will be announced by screen readers. Occasionally, there might be good reasons to override this label or name with one that is more descriptive for screen reader users. When using these sorts of techniques, it can be helpful to know the rules for how link text and other labels are calculated by assistive technologies. The “Accessible Name” of an object is its name recognized by assistive technologies.

The W3C Accessible Name and Description Computation specification provides a precise formula for how this should be calculated. Put simply, an object is named using one of the following, in descending order of precedence:

  1. An aria-labelledby attribute
  2. An aria-label attribute
  3. A built-in naming feature for that object such as:
    • alt attribute for an image
    • <label> for a form control
    • <caption> for a table
  4. Content of the object (e.g., text or CSS content)
  5. A placeholder or aria-placeholder attribute for form controls
  6. A title attribute

There are two important considerations regarding an object’s accessible name:

  • The accessible name should include the content of any visible label.  For example, if a button visibly says, “Help” but has aria-label="Show keyboard shortcuts", then assistive technologies recognize the button as the “Show keyboard shortcuts” button. Therefore, if a screen reader user attempts to find the “Help button” (perhaps because a sighted user has told them it’s there), they won’t be able to find it – there is no such button.   Also, speech input users won’t be able to say “Click Help” to trigger the button, again because the button isn’t recognized.
  • The accessible name should be discoverable. If a button has no visible label (e.g., a button that contains an icon rather than text), add the accessible name to the title attribute, so sighted users can discover the accessible name by hovering over the object with a pointer. Once discovered, speech input users can use voice commands to click the button (e.g., “Click Play”). That said, a better practice is to supplement the icon with a visible label, as this benefits anyone who is unfamiliar with the icon.

Additional resources

The following are some of the best resources for learning more about ARIA:

  • MDN ARIA Site – This site from the Mozilla Developer Network is a hub for excellent information, including tutorials, articles, and examples.
  • WebAIM Introduction to ARIA – This introductory tutorial from WebAIM is well written and includes a few basic ARIA examples.
  • The W3C ARIA Specification – This is the definitive resource on ARIA, the technical specification itself.
  • ARIA Authoring Practices Guide (APG) – This W3C resource includes a growing collection of design patterns that have been carefully created with extensive community input.  Design patterns include dialogs, disclosures (i.e., show/hide content with a button click), accordions, carousels, tooltips, and dozen of other common web widgets. Each design pattern includes documentation of the needed ARIA markup, as well as details about how the widget should respond to specific keystrokes. Designers and developers should bookmark this resource and always consult these design patterns when building a component for their website.  If you are choosing third-party components rather than building them from scratch, be sure to research their accessibility, including whether they conform to the W3C’s recommended design patterns.

WCAG 2.1 success criteria

The issues described on this page, and associated Techniques pages, map to the following success criteria in the W3C’s Web Content Accessibility Guidelines (WCAG) 2.1: