Accessible Rich Internet Applications suite (ARIA)

 

What is it?

ARIA is a technical specification created by WAI; WAI is an initiative of the W3C. The current version is ARIA 1.1, but ARIA 1.2 is coming out in the near future.

Rich web applications (formerly known as “rich internet applications”) are websites with complex features that used to be possible only in desktop applications. ARIA is designed to supplement HTML by providing additional features that facilitate and enhance the accessibility of rich web applications.

Many of the techniques that can be used to meet the WCAG success criteria are based on ARIA. However, you must use ARIA responsibly, because misusing it is more detrimental for people with disabilities than not using it at all. Always remember: no ARIA is better than bad ARIA.

There are three types of ARIA attributes that can be added to HTML code:

  • Roles define the purpose of a component in the user interface.
  • Properties define the characteristics of a component.
  • States define the current condition of a component.

Keep reading to learn more about them!

ARIA roles

ARIA roles convey the purpose of a component in the user interface; for example, role="radiogroup" defines a set of radio buttons.

There are a total of 82 roles divided into six categories:

  1. Abstract roles: don’t worry about these too much, you’ll never use them directly. They exist as a conceptual basis for other roles.
  2. Landmark roles: these delimit major regions of the page that are navigational landmarks. They include navigation menus, search fields, footers, etc.
  3. Document structure roles: these tell us about the different types of content on the page and how they are organized. They include headings, tables, images, articles, etc.
  4. Widget roles: these are interactive elements that the user can control in some way. They include buttons, scrollbars, tab panels, etc.
  5. Live region roles: these are parts of the page that change content when the focus is elsewhere. They may change in response to some action taken by the user, or to some external event. They include alerts, timers, etc.
  6. Window roles: these are windows within the browser or application. They include dialogues, alert dialogues, etc.

ARIA properties and states

There are 27 ARIA properties, which define the characteristics of the component. For example, aria-required="true" can tell that selecting an item from a radio group is required before a form can be submitted.

There are 9 ARIA states, which define the current condition of the component. For example, aria-checked="true" can tell that a certain radio button is selected.

All ARIA properties and states are prefixed as aria-*, and can be collectively referred to as “aria-* attributes”.

Some aria-* attributes are global; they can be applied to elements with any ARIA role, or elements with no ARIA role at all. These include the commonly used aria-hidden (which hides an element from assistive technologies) and aria-label (which provides an accessible label for an element).

Other aria-* attributes can only be applied to elements with certain ARIA roles. For example, aria-checked can be used with role="radio" (among others), but not with role="navigation".

ARIA and semantic HTML

As we discussed in our semantic HTML page, most HTML elements have particular native semantics, many of which correspond to ARIA attributes (roles, properties, and states).

When using HTML semantic elements, never add ARIA attributes that are already implicit in that element. For example:

  • A <button> element already has implicit role="button".
  • A selected radio button with the checked HTML attribute already has implicit aria-checked="true".

Additionally, never add ARIA attributes that contradict the native semantics of that element. For example:

  • A <button> element cannot have role="heading"; a button is something you activate in order to perform an action, not something that gives you information about the structure of the page.
  • A radio button cannot have aria-checked="mixed"; radio buttons only support the values true and false. Checkboxes, on the other hand, do support a third, mixed state.

Always use semantic elements if possible, for multiple reasons:

  • Native semantics have better support, especially when it comes to internationalization. For example, if you’re using a screen reader in Finnish, a <nav> element is usually correctly announced as “navigointi” (Finnish word, Finnish accent), but a <div role="navigation"> is very often incorrectly announced as “navigation” (English word, Finnish accent).
  • Interactive elements have built-in functionality implemented by the browser. For example, a <button> element works with both mouse (or mouse emulators) and keyboard (or keyboard emulators). Adding role="button" will not automatically make it behave like an actual button.

Once again, please use ARIA responsibly. Remember: no ARIA is better than bad ARIA.

ARIA landmarks

ARIA landmark roles correspond to regions of the page that are considered significant from a navigational point of view. There are eight of them:

  • Banner (up to one per page): containing mostly information about the site in general, rather than the current page.
  • Navigation (no limit): containing mostly links for navigating the page or the site.
  • Main (up to one per page): containing the main content of the page.
  • Complementary (no limit): containing information that supplements the main region, but can still be seen as a separate entity.
  • Content info (up to one per page): containing information about the page or site.
  • Form (no limit): containing one or more elements that make a form (but not a search form).
  • Search (no limit): containing one or more elements that function as a search facility.
  • Region (no limit): for content sections that are large and important enough to be considered a major landmark, but are not suited for any of the other landmark roles.

Certain elements introduced in HTML5 have these ARIA roles as part of their implicit semantics. For example, the <main> HTML element has the implicit role="main", and we shouldn’t explicitly add it to the code. Here are the relationships:

  • <header>: implicit banner role.
  • <nav>: implicit navigation role.
  • <main>: implicit main role.
  • <aside>: implicit complementary role.
  • <footer>: implicit contentinfo role.
  • <form>: implicit form role.
  • There is no HTML element that has an implicit search role. In most cases, we will use a form element and give it the explicit role="search".
  • <section>: implicit region role.

All the content of a page should be contained by ARIA landmarks: some assistive technologies (such as screen readers) have shortcuts to go to specific landmarks, or to the beginning or end of the current landmark. Any content not inside a landmark could be missed by these users.

Some landmarks are top-level only: <header>, <main>, <aside>, and <footer> cannot be inside other landmark regions. The rest are allowed to be nested if necessary, but it’s not required. For example, a <nav> element can be at the top level or nested inside another landmark (such as <header>).

Only some landmarks can occur multiple times in a page (see earlier list): if there are multiple landmarks of the same type, they must be distinguished with the use of aria-label or aria-labelledby. For example, you may have a primary navigation bar (identified with aria-label="primary") at the top of the page, and a secondary navigation element (identified with aria-label="secondary")  inside the footer.

Resources

General ARIA:

ARIA attributes:

ARIA and HTML: