An accessible name is the name of an element which is derived from one or more sources.
It is what is exposed to assistive technology, such as a screen‐reader when they access the element, or what a speech recognition user would need to say to access that element.
At its simplest an accessible name of a link, for example, is the content enclosed by the link tags.
This link's accessible name is "Bob"
You can see the accessible names of elements in most browser developer tools by inspecting the element and checking the accessibility panel.
Accessible name generation
But an accessible name can also be created from other things, like the relationship generated by a
This input's accessible name is generated by the label, so it is "Your name" and this is what will be announced to screen‐reader users when they land on the input.
<label for="name">Your name</label> <input id="name" type="text" />
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:
- contents (not form elements)
- derived from the label relationship (only form elements)
- placeholder (only form elements)
(I included placeholder and title in there for completeness, but please don't use these for anything where you need the users to actually read these attributes' content. I'd go as far as saying just never use them.)
So if you take the link from our first example and add an
<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 chnaging the accesible name.
Similarly if you take that link and add an
aria-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 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.
Where the button doesn't have any content as a background image, an icon font, or an image with no alt text is used, for example for a mobile menu icon, or a carousel control:
<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 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.
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 they didn’t provide an accessible name 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 title 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.
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.
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.
This is the button from the BBC example above (since I took this screenshot it has been fixed, although it took a redesign for this to happen).
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".
I've seen worse examples, where the meaning of the visual label was completely different to the accessible name 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, given a page where you have lots of article summaries each with a "Read more" link.
<h3>Dynamites awards in pictures</h3> <p>Teaser content ...</p> <a href="">Read more</a>
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).
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 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, but using the
h3 and link content to concatenate 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>
Bear in mind that any use of aria requires more testing with screen‐reader and voice-recognition software to ensure it works as expected. If you can get away without using aria, that is often the better option.
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
<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>
<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 Bob">change name</a>
If you want to learn more about how different speech-recognition software handles contextual content in an accessible name, I wrote up some findings from some testing.
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.