WCAG 2.5.3 - Label in name

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

WCAG 2.5.3

What does all of this mean?

This success criterion only applies when the element contains text or images of text — it does not apply to an image of an arrow with no text.

WCAG's definition of an element's label is the following: text or other component with a text alternative that is presented to a user to identify a component within Web content. It defines name as text by which software can identify a component within Web content to the user. These definitions are almost identical, but there is one important difference. Label is presented to the user and name is presented to software.

For most HTML elements, the WCAG name and label should be the same. For example, if a link has the text "Apply now" (Apply now), this text will serve as both the label (what a sighted user sees) and name (what a screen reader user would hear).

Finding the accessible name is not always straightforward, especially in one of these three scenarios:

1. For images, you must check the alternative text to discover the accessible name.
2. If an element has multiple bits of information competing for the accessible name, you must determine what rises to the top. This is especially common for form controls.
3. If an element uses ARIA labels (aria-label or aria-labelledby), this will override any other contender for an accessible name.

Sufficient techniques listed are including the text of the visible label as part of the accessible name and matching the accessible name to the visible label.

You can add more information to the link with an aria-label. But you need to have the words of the visible label in the same order they are in the visible text. The wording must be identical. You cannot, for example, have a link text "This is my awesome link text" and then have an aria-label "This is my link text". There are three clear failures for this criterion:

• Failure due to the accessible name not containing the visible label text
• The accessible name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text.
• The accessible name contains the visible label text, but one or more other words are interspersed in the label.

So pay attention to this, there are a lot of failures for this around the web. And do remember that add ARIA only if you need it. If the text content is clear enough, you don't need any ARIA.

Some say that you need to start with the visible text but that actually is not required. As long as the accessible name contains the visible text, the criterion passes. But it is best practice to start with the visible text, so I recommend doing it whenever possible.

Who benefits from this?

The users who benefit from this the most are speech-input users and text-to-speech users. If you have a button that visually says "Search" and then the name says "Find", the speech input user can have a lot of difficulties activating that button. Or at least it will be unnecessarily confusing.

Where this criterion is often failed?

On many websites, you see these card-like elements that link to another page. You often have at least an image and a title. A date, a category, or even some brief description text can also be present. How these kinds of elements are often created, is a link element with all the contents inside of it. And here you get the problem. If you have a lot of content inside the link, the screen reader experience will be less than optimal.

When a developer becomes acquainted with ARIA, many times they try to solve this by adding a more simple version of the content with ARIA. But this is a problem because then the visual label does not match the accessible name. So don't do this. Even if it seems like the most user-friendly approach. If you need to comply with WCAG A level, you need to pay attention to this. I've seen many people try to be clever with ARIA and unfortunately, often it completely fails.

On this blog in the blog listings, I have these kinds of elements as links to each blog post. I have an image, a date, a category, and a title inside the link. I use images only as decorative ones so I don't have alt texts in them. But in my opinion, all the other information is useful for the users. But having the screen reader announce the links like "Flexbox gap December 04, 2021 tech" sounds a bit silly. What I did was add extra content for the screen readers. It reads "Flexbox gap on December 04, 2021, in category tech". Which is a bit better, at least in my opinion. And this doesn't fail the criterion. But this will not be the best solution for all these kinds of content, especially when there are multiple language versions in play.

One other approach I've seen is to add separate links - one in the image, one in the title, and so on. This is not optimal either. You shouldn't link with different kinds of links to the same page. At least in this case only show one link for the screen readers. But for keyboard users, this will still be quite annoying because you would have to tab through multiple links just to get to the next card. So you would need to handle that as well. I don't really recommend this approach, you will very easily make browsing harder for your users.

What I would recommend is to try to design these elements so that you can have only one link in them, which describes the content well enough. If it is a link to another page on your site, often the title is enough. Many users react better to CTA (call to action) elements such as button-like links. If this is your case, then consider having the link only in the button. But try to make sure the buttons are something more descriptive than "read more". Avoid trying to be too clever with these card-like elements, and always remember to test your solutions against this criterion.

It is always best to have user testing. I recommend testing for both usability and accessibility. The real users show you the most realistic results. For developers, I recommend always doing proper technical design. With proper design and planning, you can avoid many of the issues.