Understanding ARIA Basics: Roles and Labels for Web Accessibility

ARIA, or Accessible Rich Internet Applications, can be a tricky thing to get into, especially for a brand-new developer or someone learning. A quick look at ARIA documentation can make the whole thing daunting, as there is a lot there.

But there is something to know about ARIA, something I learned well while researching for this article. A lot of the time HTML covers ARIA automatically. Semantic HTML often includes the very thing that ARIA might be seeking to cover. I will probably write another article on how ARIA and semantic HTML interact, although this article will cover that a little as well. Also don't forget that if you are unsure of what ARIA element to use, don't use any. Using the wrong one can make for a poor user experience. ARIA is still worth talking about, as it helps screenreaders and opens the web in a more inclusive and accessible way.

For this article, I made a horrible little web page using HTML with ARIA and nothing else. This is why it isn't functional or looks good, those are things that will be covered in later articles.

See the page here: https://ashlavadev.github.io/aria_basics/
View the source code (with comments) here: https://github.com/AshlavaDev/aria_basics

Roles vs Labels

One thing that did confuse me for a little bit when I was first starting was the difference between a role and an aria-label. A role governs what the element does, and comes from a list of roles. (see Further Reading for a link to a list) The aria-label is what a screen reader will feed the audio. It can be whatever you want, the screen reader will parse it. This means the label should be semantically readable and coherent so it makes sense to a listener.

Since navigation and menus are often at the top of any web page, at least on desktop designs, it makes sense to start there.

  <div role="navigation" aria-label="Menu">
    <ul role="menu">
      <li role="menuitem"><a href="#" aria-label="Home">Home</a></li>
      <li role="menuitem"><a href="#" aria-label="About">About</a></li>
      <li role="menuitem"><a href="#" aria-label="Home">Contact</a></li>
    </ul>
    <button aria-label="Close">X</button>
  </div>

If for whatever reason you decide against using a nav HTML element (you should probably use nav though) there is the navigation ARIA role. You should attach an aria-label to it (or an aria-labelledby) to ensure that a screen reader user knows what the element is.

The navigation role acts as a grouping (there is also a group role that could also be used) while the menu role tells the screen reader that the list is a functional menu. Each list item, therefore, has a menuitem role, which while implicit also should be clarified. The links on each item will also get an aria-label to clarify to the screen reader although given the text on the links this could be skipped.

The close button, which is a common element seen on mobile menus, has an aria-label and nothing else. There is a button role, however, since semantic HTML is preferred the button element is used instead. The label is very useful, however, since the button text does not specify what the button does it is useful to clarify with any screen reader users.

Images

  <div role="img" aria-labelledby="images-label">
    <img src="https://picsum.photos/200" alt="The first random image">
    <img src="https://picsum.photos/200" alt="The second random image">
    <p id="images-label">This would have a description of the overall images</p>
    <p>The images, randomly generated by <a href="https://picsum.photos/" target="_blank">Lorem Picsum</a> will be the same due to seeding synchronously</p>
  </div>

Given that images are usually found in the semantic img element, ARIA is often not used. The alt attribute is used instead. However, there may be times where several images are grouped for a specific purpose, making one larger composite image on the webpage. The container for those images would therefore not be the img element, but something else. That container would then receive the img role, and it's label will describe the overall image in the same way the alt attribute does. The alt attribute for the individual img components then describes the specific images used in the makeup of the piece.

This example also demonstrates the aria-labelledby format. This allows for another element, in this case a p tag, to be used as the aria-label. It is useful if there is a visible element, such as a caption, that contains the same information that you wish to use for a screen reader. For those familiar with a fig element in HTML, it is much the same way as the figcaption section.

Forms

A common use of old ARIA is in forms, where much has been depreciated in favour of semantic HTML and as such demonstrates why semantic HTML is often better for accessibility.

  <form aria-label="Form using ARIA">
    <label for="name">Full Name:</label>
    <input type="text" id="name" aria-label="User's Name">

    <label for="email">Email:</label>
    <input type="email" id="email" aria-label="User's Email">

    <input type="checkbox" id="checkboxer" aria-label="Checkbox">
    <label for="checkboxer">ARIA?</label>

    <button type="submit" aria-label="Login">Login</button>
  </form>

Since virtually all elements of modern forms are semantic, there is little need for roles with form elements. Aria-labels can still be useful, however.

Progression Bars and Sliders

Progression bars, something seen often in things like multipage forms, have a very interesting ARIA capacity that they share with sliders.

  <div role="progressbar" aria-label="Progress Bar" aria-valuemin="0" aria-valuemax="100" aria-valuenow="75">
    <span>75% Done (and won't change without more elements)</span>
  </div>

As shown, there are ARIA values that can be attached to the progress bar that allows screen readers to understand what the minimum and maximum values are, as well as the current value which would change based on the functionality. The slider element can also use the same ARIA attributes in the same way.

ARIA Hidden

The hidden attribute can be used when elements on a page can be hidden or shown depending on user interactivity. (This could have also been used in the menu section)

  <button aria-expanded="true" aria-controls="collapse-content">Toggle Content</button>
  <div id="collapse-content" aria-hidden="false">
    <p>This is the content that can be expanded or collapsed.</p>
  </div>

The aria-hidden attribute is a boolean, true or false, that is toggled using javascript, which is why it is not functional on this page. The controlled content is linked to something such as a button using an id attribute through the aria-controls, allowing a screen reader to know what elements are connected.

Describedby

The last element this article will discuss is the aria-describedby attribute.

<p id="button-description">This button, if hooked up to some javascript, would perform some kind of action, but really is only there right now to show how ARIA describedby works. Labelledby or semantic regular html is preferred</p>
<button aria-describedby="button-description">Click Me For Things</button>

This is a long-form version of the labelledby attribute. An HTML element, in this case a button that does not have text that describes its own functionality, is linked in the same way as the labelledby attribute to another element through an id, and is longer than a simple label. Ideally, this practice should be avoided but can be useful to describe something in greater detail if needed.

The End

Hopefully, at least one person reading this is helped by my first clumsy attempt at writing about web accessibility as a developer.

Thank you for reading!

ARIA Basics: Roles and Labels

Table of contents