What is it?
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 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:
- Abstract roles: don’t worry about these too much, you’ll never use them directly. They exist as a conceptual basis for other roles.
- Landmark roles: these delimit major regions of the page that are navigational landmarks. They include navigation menus, search fields, footers, etc.
- 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.
- Widget roles: these are interactive elements that the user can control in some way. They include buttons, scrollbars, tab panels, etc.
- 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.
- 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 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).
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
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:
<button>element already has implicit
- A selected radio button with the
checkedHTML attribute already has implicit
Additionally, never add ARIA attributes that contradict the native semantics of that element. For example:
<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
false. Checkboxes, on the other hand, do support a third,
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 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:
- There is no HTML element that has an implicit
searchrole. In most cases, we will use a form element and give it the explicit
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:
<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
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-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.
- ARIA 1.1 on the W3C website
- ARIA on the MDN web docs
- Latest ARIA Authoring Practices on the W3C website
- “No ARIA is better than bad ARIA” on the ARIA Authoring Practices 1.1
- Categorization of roles on ARIA 1.1
- Supported states and properties on ARIA 1.1
- Landmark Roles on ARIA 1.1
ARIA and HTML:
- ARIA in HTML on the W3C website
- Document conformance requirements for use of ARIA attributes in HTML on ARIA in HTML
- Allowed ARIA roles, states and properties on ARIA in HTML
- ARIA Landmarks Example on the W3C website
- Semantic Structure: Regions, Headings, and Lists(new layout)[new window] on WebAIM (2020)
- Accessible Landmarks by Scott O’Hara (2018)