Why aria-label can be bad for accessibility

ARIA provides us with a toolkit of attributes we can use with HTML to improve the accessibility of our content. However, improper use can often create more barriers than it resolves.

According to a 2024 report by WebAIM, 'Home pages with ARIA present averaged 34.2% more detected errors than those without ARIA.'

One of the first ARIA attributes many developers learn and start to implement is aria-label. However, it is often misused and in doing so creates new issues. So why can aria-label be bad for accessibility?

It can break the first rule of ARIA

The first rule of ARIA is don't use ARIA. Well, sort of. If there's a native HTML element or attribute that provides the same semantics and behaviour needed, then we should use that instead.

In the case of aria-label there are often appropriate native elements or attributes available. We should be utilising <label> elements, link and button text, alt text, etc.

By using native HTML elements and attributes, we benefit from their in-built semantics which are often optimised in assistive technologies. We also enhance the general user experience. For example, consider the following form input:

<!-- Example of bad `aria-label` use -->
<span>Your name:</span>
<input type="text" id="name" aria-label="Your name">

The input has a visible 'label' provided by the span and aria-label provides an accessible label for screen readers. However, the visible label is not clickable. Many users benefit from being able to click on the label to move the focus onto the associated input field.

A better way of building this form input component would be using a <label> element associated with the input:

<label for="name">Your name:</label>
<input type="text" id="name">

Associating the label to its corresponding input not only makes this more accessible, it improves the overall user experience.

It can create unnecessary noise

We can use aria-label to provide additional context to landmark elements. However, this needs to be done with some thought. Some elements should only exist once on a page:

• <header>
• <main>
• <footer>

In these cases, we don't need to add a label. Their semantic meaning should provide the necessary context. Labelling these just creates noise.

For other landmark elements, we can use aria-label if it will provide useful information; for example, if a landmark element is used more than once (although overuse needs to be cautioned against).

Take the <nav> element; we might want to add an aria-label to distinguish between two separate navigation components on a page. However, the label should be clear and brief, again to avoid creating unnecessary noise.

Earlier this year, Ashlee Boyer reported to Vercel that their <nav> element for their homepage's primary navigation was excessively verbose.

The aria-label used by Vercel contained a lot of information:

aria-label="Navigation header with 5 links and 1 dropdown menu with links"

As highlighted by Ashlee, this information was unneeded. Vercel have since updated their code to use a much simpler label:

aria-label="Main"

However, this is still redundant as screen reader users will be able to understand the purpose of the navigation as it is part of the <header> element. Here, the aria-label could simply be omitted.

It doesn't translate well

Many people browsing the Web will come across content in languages other than their own. Some websites will have custom translations available, others will utilise automated translation services. Often, users have to auto-translate via their browser in order to understand the content.

Unfortunately, when we use ARIA attributes, this text gets overlooked in translation. Either the automated tool will not pick up on the ARIA values, or a real person translator will miss that this text exists.

While some automated translation services will pick up on ARIA values, not all do. As a result, we can't rely on these services for making our 'accessible' content understandable to all.

If there's the budget to use human translators, then developers need to ensure that all text strings, including ARIA values, get captured and sent for translation. However, the budget for this often doesn't exist. In which case, it is important to understand that use of aria-label may not be understood to all that use assistive technologies that implement it.

It can mask content

Depending on the element, aria-label will in some cases mask the content contained within the element's tags.

<a href="/" aria-label="home page">Welcome</a>

In this example, aria-label masks the link text for assistive technologies like screen readers. For these, 'home page' becomes the link text instead of 'welcome.'

Some elements, such as the landmark elements, aria-label will not mask the contents. For example:

<nav aria-label="footer">
	<!-- This content is not masked -->
</nav>

This is important to understand. By using aria-label we are potentially hiding content from some people. This would mean users are getting inconsistent experiences.

It can create an accessibility paradox

Following on from the issue of masking, this can also create another accessibility problem.

WCAG's success criterion 2.5.3 'label in name' states that:

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

When the visual label differs from the aria-label, those using their voice to control a Web page may struggle to select interactive components.

An example of this paradox can be found on the Twitter website. Here, aria-label is used on the primary navigation to provide additional information about the links.

This is what the aria-label looks like when there is one unread direct message:

aria-label="Direct Messages (1 unread conversation)"

Visually, the link appears as 'Messages'. For someone using their voice to control the page, they would likely try the command: 'click messages'. If you use Voice Control on a Mac, this command would fail.

Mac's Voice Control expects the full accessible label to be spoken in order for it to activate the link. 'Click messages' and even 'click direct messages' would not work as they do not include the full label text (which is not visible). The latter command would work if there were unread messages as, in this case, Twitter uses 'direct messages' as the accessible label (again this is not visible to the user).

Other voice command software may be more lenient. Tools like Window's Speech Recognition can handle partially spoken labels, as long as the the spoken words are early in the accessible label.

I've referred to this example as being on Twitter, as I first became aware of this issue when the site still went by that name. It has since been rebranded as X, and the problem with the accessible labels persists. It actually affects other menu items including the 'home' and 'notifications' links.

Summary

Use of aria-label is not necessarily bad. Appropriately implemented, it can enhance the experience for those using assistive technologies. However, it is important to remember that incorrect use can lead to further accessibility issues. We need to implement it sparingly.

To summarise, aria-label can be bad for accessibility because:

1. It can break the first rule of ARIA
2. It can create unnecessary noise
3. It doesn't translate well
4. It can mask content
5. It can create an accessibility paradox

Related resources

• Not so short note on aria-label usage – Big Table Edition - HTML5 Accessibility
• aria-label Does Not Translate - Adrian Roselli
• Don’t Overwrite Visual Labels With aria-label - Ashlee Boyer