Accessibility

Introduction to ARIA

What is ARIA and how to use it correctly.

Time to read: 15 min

Briefly

ARIA (Accessible Rich Internet Applications) is a set of additional attributes that extend the capabilities of HTML, SVG, and other languages to create more accessible interfaces.

ARIA helps to enhance the accessibility of elements or turn a static page into a dynamic web application for users of assistive technologies. With the help of ARIA markup, you can improve the accessibility of interactive elements, link elements to each other, indicate their state, mark changes on the page, or describe the document's structure.

ARIA does not affect the appearance of elements or their behavior, nor does it change the DOM. ARIA attributes only change how browsers, Accessibility API, and assistive technologies interact with elements and pages.

Who it helps

The main users of ARIA are people with visual, motor, and cognitive disabilities who use assistive technologies and accessibility settings in operating systems or browsers. These can include:

  • Screen readers.
  • Braille displays.
  • Screen magnifiers.
  • Alternative input devices and manipulators — external computer buttons, head pointers, virtual keyboards.
  • Voice control and text-to-speech programs.

Users of assistive technologies usually navigate using the keyboard.

How to understand it

The appearance of elements does not always match their functions. For example, an element in the demo looks like a button with the text "Clear Form."

Open demo in the new window

For this element, a semantically neutral tag <div> is used. Therefore, for screen readers, this is not a button, and they cannot focus on the element.

        
          
          <div class="button button-aqua">Clear Form</div>
          <div class="button button-aqua">Clear Form</div>

In this situation, ARIA can help turn <div> into a button. We will add the ARIA role button, and we will also place the element in the focus order using the HTML attribute tabindex="0".

        
          
          <div  class="button button-aqua"  role="button"  tabindex="0">  Clear Form</div>
          <div
  class="button button-aqua"
  role="button"
  tabindex="0"
>
  Clear Form
</div>

Now the element is accessible for screen readers. Users can focus on it and learn that it is a button named "Clear Form."

The best solution for the accessibility issue of this button is the HTML tag <button>. Then there is no need to add additional attributes to the element or track clicks with a script. This functionality is already included in the tag by default. It sounds strange, but one of the main rules of using ARIA is to try not to use ARIA.

        
          
          <button class="button button-aqua">Clear Form</button>
          <button class="button button-aqua">Clear Form</button>

A more complex example is a message indicating the success or failure of an action. How can we inform users of assistive technologies that something has happened on the page? For example, that the form has been successfully cleared.

Once again, ARIA comes to the rescue. We will add role="status" for the success message of the form clearance and link it to the button using the aria-controls attribute. Thanks to this ARIA role, the screen reader will automatically announce the message when the user clicks the button.

        
          
          <button  class="button button-aqua"  aria-controls="message">  Clear Form</button><div  class="status-message"  role="status"  id="message"></div>
          <button
  class="button button-aqua"
  aria-controls="message"
>
  Clear Form
</button>

<div
  class="status-message"
  role="status"
  id="message"
>
</div>
Open demo in the new window

When not to use

Mastery of ARIA lies not so much in how to use it, but when not to use it.
ARIA Spec for the Uninitiated: Part 3, Gerard Cohen.

ARIA is generally not needed when the capabilities of HTML, SVG, and other languages are sufficient. Therefore, instead of <div role="button">, it’s better to use <button>, and instead of <div role="main"> — <main>. Semantic HTML elements already have almost everything needed for accessibility built in. For example, they have the necessary roles and functionality for interactive elements.

There are several resources that can help you quickly learn about the built-in roles of HTML tags:

When it will be useful

ARIA will be useful in all cases where the capabilities of HTML are insufficient. That is, when there are no elements with the required roles, properties, and states. Additional attributes will be needed in several situations:

  • Dynamic content updates. For example, timers, alerts, parts of pages that do not load immediately.
  • Custom interactive elements and enhanced keyboard navigation, especially when using JavaScript. Examples include dropdowns, tabs, tooltips, or modal windows.
  • Adding additional landmarks to the page. These are parts of the page that users of assistive technologies can quickly navigate through. Examples are tab regions or search areas.
  • Fixing accessibility issues in browsers and for assistive technologies due to different support for features from HTML, CSS, and other languages.

Structure

ARIA consists of three parts — roles, states, and properties.

Roles are the primary purposes and functions of an element. They are set through role="".

Roles come in different types. Some can be responsible for interactive elements, for example, button and tab. Some roles are needed to create landmarks on the page. For example, search and banner.

There are roles for composite elements that require specific child elements. For example, an element with the role list must have at least one nested element with the role listitem. This is logical since a list is made up of its items.

States — the condition in which an interactive or non-interactive element is found.

Properties — additional functions of the element.

States and properties are similar to each other and are defined through the aria-*="" attribute. They are often grouped together and referred to as ARIA attributes. The main difference between them is that the values of property attributes often do not change as much as those of state attributes. For example, the value of the property aria-label changes less frequently than the state aria-checked.

ARIA attributes can also vary. Some attributes can be combined with almost all element roles, for example, aria-live and aria-label. Some are suitable only for interactive elements, for example, aria-hidden and aria-pressed. There are attributes that are mandatory for certain roles. For example, an element with the role combobox must have the state aria-expanded.

Complete list of roles and list of attributes from the ARIA 1.2 specification.

Rules for usage

There are five main rules for using ARIA.

Do not use ARIA

Do not use ARIA if you can use HTML tags and attributes.

In most cases, semantic HTML tags can be used instead of ARIA attributes.

        
          
          <!-- Wrong ⛔ --><div role="banner">  <div role="navigation"></div></div><!-- Right ✅ --><header>  <nav></nav></header>
          <!-- Wrong ⛔ -->
<div role="banner">
  <div role="navigation"></div>
</div>

<!-- Right ✅ -->
<header>
  <nav></nav>
</header>

Do not change semantics

Do not change the built-in semantics of elements without serious necessity.

When you use ARIA roles, the built-in roles of HTML tags are overridden. Therefore, for custom elements, it’s better to use semantically neutral <div> and <span>, unless it’s an exceptional case.

        
          
          <!-- Wrong ⛔ --><h2 role="tab">I am the first tab</h2><!-- Right ✅ --><div role="tab">  <h2>I am the first tab</h2></div>
          <!-- Wrong ⛔ -->
<h2 role="tab">I am the first tab</h2>

<!-- Right ✅ -->
<div role="tab">
  <h2>I am the first tab</h2>
</div>

All interactive elements are keyboard accessible

A role is a promise that an element will behave accordingly. If it is an interactive element, it must receive focus using the keyboard. For example, it's customary to move between tabs using the right and left arrows, and to open them by pressing Enter or the space bar.

To make a custom element interactive, use the HTML attribute tabindex. Try to avoid positive numbers as a value for the attribute and use it only where absolutely necessary. For example, visually impaired users do not need to focus on paragraphs, headings, and similar text content on the page.

        
          
          <!-- Wrong ⛔ --><span role="button" tabindex="1">  Upload Photo</span><!-- Right ✅ --><span role="button" tabindex="0">  Upload Photo</span>
          <!-- Wrong ⛔ -->
<span role="button" tabindex="1">
  Upload Photo
</span>

<!-- Right ✅ -->
<span role="button" tabindex="0">
  Upload Photo
</span>

More information about keyboard navigation for different interactive elements can be found in the APG patterns section (ARIA Authoring Practices Guide).

Be careful with role="presentation" and aria-hidden="true"

Do not use role="presentation" and aria-hidden="true" on visible elements that are in the focus order.

The presentation role removes an element's semantics. An interactive element will remain in the focus order even with its semantics removed. In this case, screen reader users can focus on it but will not know the role of the element.

The aria-hidden property hides an element from screen readers and other assistive technologies, but it does not visually hide it. If you use this ARIA attribute on a non-interactive element with a nested interactive element, the nested element will inherit this attribute. This can also lead to accessibility issues for assistive devices.

        
          
          <!-- Wrong ⛔ --><button role="presentation">  Send Greetings</button><button aria-hidden="true">  Send Greetings</button><div aria-hidden="true">  <button>    Send Greetings  </button></div><!-- Right ✅ --><!--  The description of the image is taken from the paragraph,  and the paragraph is linked to a <div> with the image role--><div role="img" aria-labelledby="caption">  <img src="dog.png" alt="" role="presentation">  <p id="caption">    A dog has tilted its head, pressed its ears back, and is looking    curiously right into the camera.  </p></div><button>  <span class="emoji" aria-hidden="true">👊</span>  <span class="text">Send Greetings</span></button>
          <!-- Wrong ⛔ -->
<button role="presentation">
  Send Greetings
</button>

<button aria-hidden="true">
  Send Greetings
</button>

<div aria-hidden="true">
  <button>
    Send Greetings
  </button>
</div>

<!-- Right ✅ -->
<!--
  The description of the image is taken from the paragraph,
  and the paragraph is linked to a <div> with the image role
-->
<div role="img" aria-labelledby="caption">
  <img src="dog.png" alt="" role="presentation">
  <p id="caption">
    A dog has tilted its head, pressed its ears back, and is looking
    curiously right into the camera.
  </p>
</div>

<button>
  <span class="emoji" aria-hidden="true">👊</span>
  <span class="text">Send Greetings</span>
</button>

Interactive elements need names

All interactive elements must have accessible names. These names further clarify the purpose of the element. Screen readers announce them before the role.

Names are set in two ways:

  • using HTML — the text contents of tags and the attributes alt and title;
  • using ARIA attributes aria-label and aria-labelledby.
        
          
          <!-- Wrong ⛔ --><button>  <img src="logo.svg" alt=""></button><!-- Right ✅ --><button>  <img src="logo.svg" alt="Twitter"></button><button aria-label="Twitter">  <img src="logo.svg" alt=""></button>
          <!-- Wrong ⛔ -->
<button>
  <img src="logo.svg" alt="">
</button>

<!-- Right ✅ -->
<button>
  <img src="logo.svg" alt="Twitter">
</button>

<button aria-label="Twitter">
  <img src="logo.svg" alt="">
</button>

Additional rules

  • Do not clutter the markup with unnecessary ARIA roles and attributes.
  • Always test ARIA elements in different browsers and with different screen readers.

Specification

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) is a technical specification that describes how ARIA markup is structured and should work. The specification is similar to ECMAScript. It describes how ARIA should be implemented in browsers and specific languages referred to as host languages. For example, in the web, host languages are HTML and SVG.

WAI-ARIA has several versions.

You can follow updates on WAI-ARIA on the W3C news page.

Related recommendations

  • APG — recommendations in simple language on how to use ARIA correctly.
  • Using ARIA — recommendations on how to make HTML elements more accessible with ARIA 1.1.

Related specifications

Support and testing

The topic of ARIA support is not the simplest. The reason is that several parties are involved — browsers, the Accessibility API, operating systems, and assistive technologies. They may have different versions, bugs, and implementations of ARIA features.

Browser support for ARIA is quite high — 98.7% in 2022, according to Can I Use. Screen readers differ significantly from each other, and usually, they have different approaches to implementing ARIA features.

Another problem is ARIA support on mobile devices. Many ARIA attributes are tied to keyboard navigation, so they are not always well supported on touch devices.

So ARIA is learned through self-testing and with real users of assistive technologies.

There are several websites that can help you roughly estimate the level of support for ARIA attributes:

You can conveniently follow bugs due to the different implementations of ARIA in screen readers and browsers via bug trackers:

There is a separate tool for searching GitHub repositories — Find accessibility stats by github repository.

Automated tools are effective for identifying major and obvious issues with ARIA and code in general. Here are some of them:

On the W3C site, you can find a complete list of accessibility evaluation tools.

Links

Read also

We use cookies for the analytics