Published at
Updated at
Reading time
3min
This post is part of my Today I learned series in which I share all my web development learnings.

I try to be a good web citizen, and keep things accessible. Now, I'm no expert, but there are some things web developers should check at least:

  • Do images have (or need) alt text?
  • Are links... well, links? And buttons... you guessed it, buttons?
  • Is the document outline logical, and are sections grouped by meaningful headings?

Some elements should also have accessible names, and today I learned a thing or two about them.

But first off, what are they — these accessible names?

Accessible names provide assistive technology users with an element's context and purpose. If a screen reader user focuses a button, the accessible name will tell what this button is about. Good stuff!

How can you check an element's accessible name? If you're not a screen reader user, pop open DevTools, and you'll find the accessibility information there!

Position of the accessible name display in Chrome, Edge, Safari and Firefox.

Note: The different browser DevTools have the accessibility tools in different places.

So what did I learn about accessible names?

What elements must have an accessible name?

I must admit, I've never questioned which elements must have a proper accessible name. Links and buttons seem obvious, but what about paragraphs or images?

Here's a quick note from the ARIA Authoring Practices Guide for accessible names and descriptions:

Both the WAI-ARIA specification and WCAG require all focusable, interactive elements to have an accessible name. In addition dialogs and some structural containers, such as tables and regions, are required to have a name.

A required accessible name for focusable and interactive elements makes sense. But what about all the other elements and resulting ARIA roles?

I don't want to list all of them now, but if you wonder about these, "Accessible Name Guidance by Role" is a good read and includes tons of info!

How is the accessible name computed?

Of course, there's a spec defining the accessible name computation.

As it goes with specifications, they're no easy read, and "Accessible Name and Description Computation 1.2" is no exception.

Let me tell you a secret...

If you check an element's accessible name in the Chromium DevTools, the different steps for defining an accessible name are shown and sorted in order of the computation!

Chrome DevTools showing the order of accessible name computation.

That's right: you see above that aria-labelledby trumps aria-label which trumps the content of an element.

(And I always thought these entries were sorted alphabetically...)

What happens if you set conflicting ways to define an accessible name?

Accessibility DevTools showing an element having `aria-labelledby`, `aria-label`, `title` and content to define the accessible name. `aria-labelledby` is taken.

Above, the element's accessible name could be based on aria-labelledby, aria-label, its content, or the title attribute. The resulting accessible name follows the computation spec and is the text provided by aria-labelledby.

If you want to learn more about accessibility, I discovered this gem in Sara Soueidan's talk "The “Other” C in CSS", which I can highly recommend watching!

If you enjoyed this article...

Join 5.1k readers and learn something new every week with Web Weekly.

Web Weekly — Your friendly Web Dev newsletter
Stefan standing in the park in front of a green background

About Stefan Judis

Frontend nerd with over ten years of experience, freelance dev, "Today I Learned" blogger, conference speaker, and Open Source maintainer.

Related Topics

Related Articles