2.5.3 Label in Name

MCS Accessibility Team

MCS Accessibility Team
Last Updated July 23, 2020

The following directions are part of a full step-by-step guide to making a HubSpot website WCAG 2.1 AA compliant. These recommendations are intended for websites managed on the HubSpot CMS but can be adapted for other content management systems.

LEVELA
Principle: Operable
User interface components and navigation must be operable.
Guideline: Input Modalities
Make it easier for users to operate functionality through various inputs beyond keyboard.

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

View Official WCAG 2.1 Compliance Techniques

Understanding 2.5.3 Label in Name

Many HTML controls – like form inputs, buttons and so on – contain visible text labels and accessible names. To understand this criteria, you need to understand these two components:

  • Label: A label identifies the control for all users and is visible to all users text immediately above, inside, or beside the element.
  • Name: This is what assistive technology uses to tell the user what the element is. It can be programmatically determined. (Important note: The accessible name is different from the name attribute on input elements.) The name may or may not be visible. An example of a name is alt-text and aria-labels: they tell a screen reader what to say, but are typically not visible.

People who rely on screen readers need to tell their technology the accessible name of the component so the software knows which one to activate. If the accessible name does not match the visible label, the user will not know what correct name to say.

Simply put, this criteria states that whenever you have a component with an accessible name, the label of that element must contain the name. 

Recommended Solutions

The best practice is to make your labels and names unique and matching one another, so there's no confusion what the user needs to say to their technology to interact with the component.

If you need to include more descriptive details in your non-visible accessible name, you may do so. Just make sure to always have the text of the label at the start of the visible name.

Here's an example. Imagine an e-commerce listing like this:

Listing of three different products – all products have a button that says "BUY"

<button onclick="alert(Sneakers added to cart');" aria-label="Buy">Buy</button>

Here, if a user says "Buy" to add an item to their cart, the software won't know which item to add and no interaction will take place.

Let's say the button has a non-visible aria-label of "Buy Sneakers."

<button onclick="alert(Sneakers added to cart');" aria-label="Buy Sneakers">Buy</button>

Now, the software expects the user to say "Buy Sneakers" out loud in order to activate the button. This is great for speech input users, but visually impaired text-to-speech users who can see the "Buy" label won't know to say this.

So the best way to resolve this criteria is to make every single label visible, unique, and descriptive. Then, make your accessible name match your label, or a least start with the same text. 

A more accessible listing would look like this:

Ecommerce listing of three different products – sneakers, sweatshirt and t-shirt. Each has a button that describes what you're buying

<button onclick="alert(Sneakers added to cart');" aria-label="Buy Sneakers">Buy Sneakers</button>

Every button's label is unique and matches the accessible name. All users would know to say "Buy Sneakers" aloud, so the software can activate the correct button.

For more information, please visit the official W3C article: Understanding 2.5.3 Label in Name


Questions?

Let us know if we can help you address this specific WCAG Recommendation.