Skip to content

ARIA

Accessibility Tree

As you know, when you create an HTML document, you are building a Document Object Model (DOM). What you may not have realized is you are also making an accessibility tree from the DOM. The accessibility tree is a representation of the DOM that assistive technologies can understand.

Accessibility Tree in the DOM

Each thing (object) in the accessibility tree contains four items:

  1. name: What do we call this thing? How do we refer to it? This is not the name attribute; think of it more like a label of the element.
  2. description: How do we describe this thing?
  3. role: What kind of thing is it? Is it a navigation, a list, or a table?
  4. state: Does it have a state? For example, can it be checked or unchecked, collapsed, or expanded? Not every element may have a state.

Each object may also contain information on what can be done with an element. For example, a text input element can be typed into, etc.

A screen reader will often read the element's role, name, description, and state to the user.

Accessibility Tree in Chrome

We can use the Accessibility tool in our Developer tools to inspect the accessibility tree:

  1. Open your Developer Tools in Chrome. Above your styles panel, there is an Accessibility option.

    Access the accessibility panel in the developer tools

  2. Inspect different elements on a webpage to see the Accessibility tree in the top pane.

    The accessibility tree in the developer tools

  3. You can also receive information on each element with the inspector by hovering over each element.

    Accessibility info on element hover with inspect tool

What is ARIA?

ARIA (Accessible Rich Internet Applications) is a technology developed by the WAI (Web Accessibility Initiative). The WAI is part of the W3C that is in charge of developing standards and support materials for accessibility.

ARIA is a series of HTML attributes that you can use to add semantic meaning to your code. They are used like an href, class, or id attributes. They do not change the visual design or behavior of a site; instead, they are strictly used by screen readers or other assistive technologies.

ARIA attributes help to identify roles, properties, relationships, and states in your user interface. Native HTML doesn’t always provide the best description for screen readers; therefore, ARIA can help make websites and apps more accessible for people with disabilities.

As you know from last week, many elements have implicit semantics, meaning the element's purpose is described by its tags elements. However, some elements do not and are not helpful to assistive technologies, like a div. This is where ARIA is useful.

WAI-ARIA Authoring Practices

ARIA Roles

ARIA roles define how a particular HTML element functions semantically within the document. Many HTML elements already have a role defined. For example, a <button> element has the role of "button" and the <nav> element has the role of "navigation." When using semantic elements, we do not need an ARIA role. However, elements that provide no semantic meaning, like a <div> or <span> may need a role added via ARIA to provide more information to the screen reader.

Example of using an ARIA role to assign a <form> element a search role.

In the below example, the form element has been given a specific role of "search." A screen reader can quickly locate the search functionality on a page. 

<form role="search">
  <!-- search input -->
</form>

Semantic elements have default roles. Inspect a header or a navigation element and view the listed role in the Accessibility tab. Explore other roles on this page. How many can you find?

Inspect a <div> element. What role is given to this non-semantic element?

ARIA roles are pre-defined (link below), and they should ONLY be used when a semantic element is not available. Or, in the case of the form above, the "search" role helps clarify the purpose of the form.

Mozilla: List of ARIA Roles

Native HTML Roles

By default, most HTML 5 elements have roles assigned to them. Imagine the below example is of a main navigation. (A # has been used in place of path.) The navigation is built with list elements (which is best for accesibility, but more on that later).

View the accessibility tree for the rendered navigation to see what roles each element has.

<nav id="navExample">
    <ul>
        <li><a href="#">Home</a></li>
        <li><a href="#">Shop for Batteries</a></li>
        <li><a href="#">Contact the Store</a></li>
    </ul>
</nav>

The <li> element has a role of listitem

accessibility tree showing role of listitem for li element

Adding Roles

Since the purpose of this list is to serve as a navigation, we can override the default role to provide more meaningful information to screen readers. Using the WAI-ARIA Authoring Practices for Menus I can find out how to best describe my content.

  • Added a role of menubar to the <ul> element.
  • Removed the role on the <li>
  • Added a role of menuitem to each <li> element.
<nav id="navExample">
    <ul role="menubar">
        <li role="none"><a href="#" role="menuitem">Home</a></li>
        <li role="none"><a href="#" role="menuitem">Shop for Batteries</a></li>
        <li role="none"><a href="#" role="menuitem">Contact the Store</a></li>
    </ul>
</nav>

Important The above example is a unique case where I'm changing the default role to become more meaningful to the end-user. Typically, the native roles are sufficient, and ARIA roles are NOT needed. For example, the below snippet is coded poorly. Why?

<div role="button">Place Order</div>

ARIA States and Properties

ARIA states and properties are often used to support ARIA roles that exist on a page.

  • Properties often describe relationships with other elements and, for the most part, do not change once they’re set.
  • States are more dynamic and are typically updated with JavaScript as users interact with a page.

It’s common to refer to states and properties collectively as just ARIA attributes. Screen readers are notified when attributes change and can announce these changes to users after an interaction takes place. For example, the state of a checkbox can be set to "checked" or "unchecked."

aria-label

The code below is a button that contains a filter icon. Use your screen reader to interact with the button. Do you get any information about what this button should do? Inspect this element with the Developer Tools. What information do you see about the button?

Button with Icon

<button class="myButton">
    <i class="fas fa-filter"></i>
</button>

Note: The icon is created withe a special set of class values and an empty <i> element. This is a common technique to apply icons to your website. The icon set used below comes from Font Awesome.

ARIA can be added to provide a better description of the functionality. Use your screen reader on this element. How is this experience different? Inspect the button again with the Developer Tools. What changed in the accessibility information provided?

Button with Icon and ARIA label

<button class="myButton" aria-label="filter">
    <i class="fas fa-filter"></i>
</button>

Thearia-label can be used when the purpose of an element is not apparent with native HTML. As demonstrated with our filter button above, a screen reader will always read both the role and the name (label).

Another use-case of aria-label is when you have multiple navigations in your webpage (main navigation, sub-navigation, utility navigation, etc.). All of these navigation systems will use the <nav> element, which automatically has the role of "navigation." We can provide more context with ARIA, as shown below.

Using aria-label to distinguish between different navigation systems.

<nav aria-label="Main Menu">main navigation links go here...</nav>

<nav aria-label="Sub Menu">sub navigation links go here...</nav>

<nav aria-label="Utility Menu">utility navigation links go here...</nav>

aria-labelledby

The aria-labelledby attribute points to an existing element by its unique id. This establishes a semantic relationship between elements. This is used when there is no text available for a dedicated label, but other text on the page can be used to label the element accurately.

Non-Accessible Example

Let's look at an example from the video in week 12 (Accessibility Fundamentals with Rob Dodson).

Not Accessible: Shop Now Link

Men's Outerwear

Shop Now 
<h2>Men's Outerwear</h2>

<a class="myButton" href="mensOuterwear.html">
    Shop Now
</a>

Visually, the example above looks good. I know or expect to start shopping for Men's Outerwear by clicking on the "Shop Now" link. However, what is the experience for a screen reader? Try it out and inspect the information in the Accessibility Tree.

The main problem here is if the user lands on the link, they would have no idea what they are shopping for. The link does not provide context, or it's not descriptive enough.

Solution #1

Change the text on the link to be more meaningful. This is the easiest solution but may not fit every scenario. Now we have redundant information for users.

Solution 1: Meaningful link text

Men's Outerwear

Shop Now for Men's Outerwear 
<h2>Men's Outerwear</h2>

<a class="myButton" href="mensOuterwear.html">
    Shop Now for Men's Outerwear
</a>

Solution #2

We could add an aria-label to the link that reads "Shop for Men's Outerwear." The aria-label overrides the name of the link element, which was previously "Shop Now." Look at how the name of the element changes when we use the aria-label element (look at the name in the accessibility tree).

Solution 2: aria-label

Men's Outerwear

Shop Now 
<h2>Men's Outerwear</h2>

<a class="myButton" href="mensOuterwear.html" aria-label="Shop for Men's Outerwear">
    Shop Now
</a>

Solution #3

Using the aria-label is a great solution; however, since the text "Men's Outerwear" is already on the page, we can reuse it with id references and the aria-labelledby.

  1. Below, I gave the <h2> an id.
  2. Then, added an aria-labelledby attribute to the <a>
  3. Finally, I referenced the id of the <h2> in the aria-labelledby

I'm telling the link to use the content in the <h2> element as its label. This method is very maintainable because if I ever change the content in the <h2>, the link's label will automatically update!

Solution #3: aria-labelledby

Men's Outerwear

Shop Now 
<h2 id="outerwareHeading">Men's Outerwear</h2>

<a class="myButton" href="mensOuterwear.html" aria-labelledby="outerwareHeading">
    Shop Now
</a>

Solution #4

We can do even better! When we used the aria-labelledby as our label, it overrode the default name or label of the link, which was originally "Shop Now." Solution #3 changed the label to read "Men's Outerwear." We lost the significance of the "shop now" text. It's important to remember the aria-label and aria-labelledby override any default element name. But, the aria-labelledby can take more than one id!

  1. Below, I added an id to the <a>
  2. Then, added that id as a reference to the aria-labelledby attribute.

Now, the link is labeled by both the <h2> and the <a> content! Look at the accessibility tree one more time to see how the name of the element has changed.

Solution #3: aria-labelledby with multiple references"

Men's Outerwear

Shop Now 
<h2 id="outerwareHeading">Men's Outerwear</h2>

<a class="myButton" href="mensOuterwear.html" id="shopButton" aria-labelledby="outerwareHeading shopButton">
    Shop Now
</a>

Rules of ARIA

  1. No ARIA is better than Bad ARIA! If you are not sure about adding ARIA, do not add it! You can inadvertently make sites LESS accessible by creating screen reader noise or confusion.

  2. Use native HTML semantics whenever possible.

  3. An HTML element can only have one role but many properties or states at a time.

  4. Do not change native semantics!

Instructors Note

ARIA is probably the part of this unit that trips students up the most. Often, I see students using ARIA where it is not necessary. Remember, you have all the HTML semantic element to use! Always use those first! If you are adding ARIA into a webpage ask yourself:

  1. Why am I adding an ARIA attribute?
  2. Is there a semantic element that already communicates the meaning or purpose?
    1. If yes, don't use ARIA!
    2. If no, think carefully about what meaning or purpose needs to be communicated? Is it essential for the end user?

Resources

What the Heck is ARIA? A Beginner's Guide to ARIA for Accessibility

Why, How, and When to Use Semantic HTML and ARIA