Skip to content
Accessible Technology

ARIA on websites

Accessible Rich Internet Applications (ARIA) is a W3C specification for markup that can be added to HTML to help screen readers and other assistive technologies to better understand the elements on a web page. It can be essential if the website includes dynamic content.

For an overview of this issue, see ARIA in our IT Accessibility Checklist.

ARIA vs WAI-ARIA

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.

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 Page regions on websites.

ARIA authoring practices

ARIA can be challenging to implement correctly. A key resource that can help is the W3C’s WAI-ARIA Authoring Practices. This resource includes a growing collection of design patterns that have been carefully created with extensive community input.  Design patterns include accordions, carousels, dialogs, disclosure (show/hide), grids, sliders, and many more. 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 always consult these design patterns in order to help build a web where common web widgets have a consistent interface across websites.

If you are choosing widgets, modules, plugins, or libraries for your website, rather than building widgets from scratch, be sure to research their accessibility, including whether they conform to the W3C’s recommended design patterns.

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.

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.