How to meet SC 2.5.3 Label in Name

For any user interface component that has a visible label — with text or an image of text — the accessible name must contain the visible label text.

Why does it matter?

Speech input users can speak the visible labels of user interface controls, such as links and buttons, to activate those controls. For example, Click Send message for a button labeled “Send message”. However this only works if the label text corresponds with the control’s accessible name, and cases where it doesn’t can create confusion or frustration for users.

To avoid such problems, any control with a visible text label should have that same text included in its accessible name.

What are the failures?

Let’s begin with what the WCAG failures are.

Control does not have an accessible name

When a form control has a visible label but lacks an accessible name, speech input users may struggle to interact with it. This can occur when the visible label is not properly associated with the control, making it unrecognizable to both screen readers and voice command tools.

❌ Failing example

Lack of association between the <label> and the <input> means it has no accessible name:

<label>First name</label>
<input type="text" id="firstName">

✅ Passing example: Explicit label association (recommended)

The <label> element should have a for attribute that matches the id of the corresponding form control:

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

✅ Passing example: Using aria-labelledby

If the labeling element is not a <label> then the aria-labelledby attribute can be used. This attribute references the ID of the visible label to associate it with the control:

<span id="firstNameLabel">First Name</span>
<input type="text" aria-labelledby="firstNameLabel">

✅ Passing example: Using aria-label

If association methods aren’t practical for some reason, the aria-label attribute can be used to define the accessible name:

<span>First Name</span>
<input type="text" aria-label="First Name">

Accessible name does not contain the visible text

The accessible name should include the label text. If the accessible name does not contain the visible text, speech input users may struggle to interact with the element.

❌ Failing example

The button’s accessible name is defined with an aria-label attribute that does not contain the visible label text:

<button aria-label="Apply for this position">Submit</button>

✅ Passing example

The aria-label attribute contains the visible label text. When the visible label and accessible name are not an exact match, it’s best practice to begin the accessible name with the visible text:

<button aria-label="Apply for this position">Apply</button>

Accessible name has interspersed words

The accessible name should match the visible label text in the same order it appears. If there are additional words in between, then a spoken command of the visible text may not work as expected.

❌ Failing example

The aria-label value includes extra words in between the visible label text:

<span>Enter First Name</span>
<input type="text" aria-label="Please enter your First Name">

✅ Passing example

The aria-label value contains the same text as the visible label, ensuring that no additional words are inserted or rearranged:

<span>Enter First Name</span>
<input type="text" aria-label="Enter First Name">

Word order does not match the visible text

The accessible name should follow the same word order as the visible label. If the words are rearranged, this may cause confusion for speech input users.

❌ Failing example

The words in the accessible name are reordered:

<button aria-label="Products Search">Search Products</button>

✅ Passing example

The accessible name maintains the same word order as the visible label:

<button aria-label="Search Products">Search Products</button>

What are the Best Practices?

So what does count as a Best Practice?

Ideal: Accessible name exactly matches the visible label

Recommended best practice is that the accessible name and visible label text are identical.

Most speech recognition software, such as Dragon or Windows Voice Access, can recognize and activate controls based on their visible label, even if additional text appears before or after the visible label present in the accessible name. Dragon can activate controls with either value, even if they’re completely different. However, Apple’s Voice Control only responds to the accessible name, so it won’t recognize a command based on the visible text, unless it’s identical to the accessible name.

For example, if a button’s visible label is “Submit Form”, while the accessible name is “Complete and Submit Form”, then Dragon and Windows Voice Access should still recognize and activate the button with a Click Submit Form command. However Voice Control will not, since the accessible name differs from the visible text.

To provide the best user experience:

1. Ensure the full text of the control’s accessible name is visible, and not truncated by ellipses (three dots).
2. Use a unique accessible name for each control within the same page or view.
3. Avoid using additional non-visual text, such as visually-hidden or aria-label, if it’s not essential.

Sufficient: Accessible name begins with the visible label

If an exact match is not possible, the accessible name should begin with the visible label text. For example, if a button’s visible label is “Submit Form”, then visible text such as “Submit Form for Review” would respond to a Click Submit Form command for the majority of speech input users.

Resources

• Understanding SC 2.5.3: Label in Name (Level A)
• Technique F111: Failure of Success Criteria 1.3.1, 2.5.3, and 4.1.2 due to a control with visible label text but no accessible name
• Technique F96: Failure due to the accessible name not containing the visible label text
• Technique G211: Matching the accessible name to the visible label

Image credit: Casey Botticello.