Accessible names

An accessible name is the name of an element (not to be confused with the name attribute on form fields). It is what is exposed to assistive technology, for example it is what is read out to a screen‐reader when they access the element, and it is what a speech recognition user would need to say to access that element on the page.

An example is the accessible name of a link. This can be, at its simplest, the content enclosed by the link tags. The accessible name of the link below is "Bob":

<a href="">Bob</a>

You can see the accessible names of elements in most browser developer tools by inspecting the element and checking the accessibility panel.

But an accessible name can also be created from other things, like the relationship generated by a for attribute. The following input's accessible name is generated by the label. The accessible name for the input is "Your name" and this is what will be announced to screen‐reader users when they land on it.

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

Accessible name computation

So we know accessible names can be assigned using a few different methods. Because of this we need some way of deciding which one wins out, especially if they are conflicting.

How an accessible name is computed is subject to a hierarchy of checks against the existence of various attributes, each one potentially overwriting the others (you can even see this order represented in the devTools display).

The order is in descending order of priority (so aria attributes win over everything else):

1. aria-labelledby
2. aria-label
3. contents (not form elements)
4. derived from the label relationship (only form elements)
5. placeholder (only form elements)
6. title

So if you take the link from our first example and add an aria-label attribute:

<a href="" aria-label="Tom">Bob</a>

that will overwrite the contents and the accessible name is now “Tom”. Note that the visible name will still be “Bob” as we are only changing the accesible name.

Similarly if you take that link and add anaria-labelledby attribute it will trump all of the others:

<a href="" aria-label="Tom" aria-labelledby="name">Bob</a>
<div id="name">Kim</div>

The link’s accesible name is now “Kim” despite the other changes still being present.

Missing accessible names

Where none of these ways of assigning an accessible name are present, the browser cannot calculate and accessible name and nothing is returned.

This is most commonly found where form inputs are missing the connection with their label, or the one I see most often is on buttons.

For example, if the button doesn't have any content because a background image, an icon font, or an image with no alt text is being used to display a visual-only message. You might have seen this yourself in a mobile menu (“hamburger”) icon, or a carousel control like the one below:

<button><img src="rightArrow.png" /></button>

To a screen‐reader user this will just be announced as "Button" so they will have no idea what it does.

For a speech-recognition user they could try a few words based on the visual appearance but will likely give up and resort to other means.

If you happen to have used an embedded SVG for that image, you might have inadvertantly provided an accessible name, and it could even have the opposite effect to the one you might have wanted, like the example below:

On Autotrader’s homepage they have a carousel which uses an SVG icon inside the directional buttons.

<button type="button" ...>
  <svg xmlns="http://www.w3.org/2000/svg" ...>
    <title>chevronLeft</title>
    ...
  </svg>
</button>

Unfortunately on this page an accessible name was not provided for the button. However because the SVG had a title attribute, this is what is exposed as an accessible name (as it counts as Contents as far as accessibility is concerned). The “chevronLeft” title from the SVG whilst meaningful to the designer who exported it, is not of any use to the end-user, not least because it suggests the arrow points in the opposite direction when it has been rotated using CSS for the right-facing button.

For those wondering, yes the left button uses the same SVG and the image rotated for the opposite direction, so both left and right buttons on the carousel had “chevronLeft” as their accessible name.

What they should have done in this case was hide the SVG from assistive technology using aria-hidden and provided a suitable aria-label on the button itself.

<button aria-label="Next" type="button" ...>
  <svg aria-hidden="true" xmlns="http://www.w3.org/2000/svg" ...>
    <title>chevronLeft</title>
    ...
  </svg>
</button>

So accessible names are very important for users to understand what the various controls on the page do and having the wrong ones can even cause the user to do something they didn't intend.

Be careful though

This does mean that you can do things like override the visible contents of the element with a different accessible name, which can lead to issues.

The following example is the code for the button from the BBC screenshot above (since I took this screenshot it has been fixed, although it took a redesign for this to happen).

<button aria-label="Next">Continue</button>

The visible content is "Continue", but the accessible name is "Next" as the aria-label has overridden the content‐derived accessible name.

For a screen‐reader user who can see (many screen‐reader users are not fully blind), this can be a bit confusing as the visible and audible messaging is different.

For a speech‐recognition user it is frustrating as they will try to say "Click 'continue'" which will not work because the software has been told the accessible name for this button is "Next". In this situation the speech-recognition user will (probably after a few tries) resort to asking the software to number all the controls on the page to allow them to select the correct one and continue.

I've seen worse examples, where the meaning of the visual label was completely different to the accessible name - for example using an aria-label of “cancel” on a button with the visual text of “continue” - and would have caused serious issues in a user's journey.

WCAG even has a criterion to cover this called “Label in name” to ensure the visible text is included in the accessible name.

Manipulating accessible names for good

But occasionally it can be useful to have a different accessible name from the visible one.

If you have a number of links which have similar functionality, but where adding unique visible text to each item might make the interface cluttered or confusing for other users, you can use certain techniques to provide different values to different groups of users.

For example, a page where you have lots of article summaries, each with a “Read more” link. The issue here is that a screen‐reader user would not be able to distinguish the purpose of the links when viewing the links in isolation (this is one way screen‐reader users navigate a page - for more on this take a look at my guide on the JAWS screen-reader).

<h3>Dynamites awards in pictures</h3>
<p>Teaser content ...</p>
<a href="">Read more</a>

They will see a list of "Read more" and will have to go into the content to find out which one they need to follow to get to the article they want:

Read more
Read more
Read more

But making the links more visually contextual like “Read more Dynamites awards in pictures” would make the interface overloaded and repetitive, helping one group to the detriment of another.

We need a way to satisfy both and one way to do this is with an aria-label to modify the accessible name, like so:

<h3>Dynamites awards in pictures</h3>
<p>Teaser content ...</p>
<a href="" aria-label="Read more Dynamites awards in pictures">Read more</a>

This keeps the visual the same but makes the links make sense to screen‐reader users as they will see a list of links like this:

Read more Dynamites awards in pictures
Read more Voices of our veterans on Remembrance Day
Read more Robin helps OC deliver on hybrid working

It also still works for speech recognition users. As we have kept the visible label in the accessible name, the user can still say "click 'read more'" and the software will place a number next to each link to allow them to pick the one they want.

Using multiple sources

You can even reuse existing content to build an accessible name by using aria-labelledby. This takes a list of IDs of elements and constructs an accessible name based on the order of the IDs.

This allows you to re‐use content (with all the advantages and pitfalls that gives). In the example below I'm creating the same accessible name as we have just done, but using the h3 and link content via aria-labelledby to concatenate them into one phrase.

<h3 id="article1-title">Dynamites awards in pictures</h3>
<p>Teaser content ...</p>
<a href="" id="article1-more" aria-labelledby="article1-more article1-title">Read more</a>

Adding context without aria

Actually what I'd recommend is using some extra HTML and CSS to achieve the same result, like so:

<a href="">Edit<span class="visually-hidden"> thing one</span></a>

This uses a CSS class which hides the content visually, but crucially not from assistive technology, and achieves the same effect as the aria-label whilst being a more robust solution.

Placement of non-visible contextual content

The critical thing with speech recognition users and editing an accessible name to add context is that only added to the end of the visible label. Speech recognition software varies in ability to search for content and most don't respond well to the visible content not being the first content in the accessible name.

For example if you have a link like this:

<a href="">change name</a>

and you want to add some context, don't do this:

<a href="" aria-label="Bob change name">change name</a>

or this

<a href="" aria-label="change Bob's name">change name</a>

as most speech recognition software won't make the match when a user says “Click ‘change name’”.

Instead add the new content to the end of the visible label:

<a href="" aria-label="change name for Bob">change name</a>

Wrap up

Accessible names are how you communicate the meaning of the interface to your users and getting it right is really important.

If you have any doubt as to what the accessible name is for an item, most browser developer tools now have an accessibility panel which shows you the computed value. However testing with screen‐readers and speech recognition is still necessary to ensure the correct meaning is conveyed.