A bugbear about aria-label
Posted 31st March 2026 in Accessibility
I was writing about how to write the aria-label for <nav> elements and I kept referring to the aria-label as the ‘label’, which bothered me.
You know how pernickety I can get about what things are called; I mean, I wrote over 600 words on why not to use ‘headers’ and ‘headings’ interchangeably. So allow me to dig into why the ‘label’ bit of aria-label gets on my nerves.
Let’s use the Web Content Accessibility Guidelines (WCAG) as our reference point for the terminology. Here’s their definition for ‘label’:
text or other component with a text alternative that is presented to a user to identify a component within web content
It’s referring to what is presented visually; usually text or something else with a ‘text alternative’, like an icon.
WCAG then goes on to define a ‘name’ as:
text by which software can identify a component within web content to the user
So this is always text, and specifically about how software uses text to convey something to the user. It’s about the underlying accessible name. That might match the label, but it won’t if the label is:
- an icon
- a shortened version of a longer, more descriptive name, relying on surrounding content for visual context
Maddeningly, the ARIA spec describes aria-label in terms of it being a ‘name’ too:
It provides the user with a recognizable name of the object. The most common accessibility API mapping for a label is the accessible name property
So my article about aria-label for <nav> elements was much easier to read when talking about aria-labels as if they were labels, but it wasn’t technically correct. If aria-label is always used to give something a ‘name’, wouldn’t aria-name have made more sense…?