Label in name

Silktide compares the text visitors can see on buttons and links with the name assistive technology uses for the same control. When the two disagree, people who operate websites by voice cannot activate the control by saying what they see.

Why this matters

Speech-recognition users look at the screen and say what they see: "click Send". The software matches those words against each control's - the name uses. Attributes like aria-label replace that name, so a button showing "Send" but labeled aria-label="Submit" only answers to "click Submit". The visible word fails silently, and the user has no way to discover the hidden name they were supposed to say.

The mismatch also confuses users working with sighted colleagues, who hear a different name than the person next to them sees.

This is success criterion 2.5.3 (Label in Name), a requirement - part of the most basic conformance level.

How to fix it

Remove the override where it adds nothing: a button whose visible text already says what it does needs no aria-label.
Where the override adds context, start it with the visible text: aria-label="Read more about pricing" for a "Read more" link keeps the spoken command working.
Never use aria-label to say something different from the visible text.

<!-- Problem: says "Send" but answers to "Submit" -->
<button aria-label="Submit">Send</button>

<!-- Fix: visible text included in the accessible name -->
<button aria-label="Send message">Send</button>

<!-- Simplest fix: no override at all -->
<button>Send</button>

How Silktide tests this

Find the visible buttons and links on each page, including elements with an ARIA role of button or link.
Only test controls that override their name with aria-label or aria-labelledby - without an override, the visible text is the accessible name and the criterion is automatically met.
Read the control's visible label: its text content plus the of any images inside it. Labels shorter than 2 characters are skipped, as are controls with an empty accessible name (a separate problem covered by other checks).
Normalize both strings - lowercasing, collapsing spaces, and stripping decorative punctuation - then require the visible label to appear within the accessible name.
For card-style links containing a heading plus supporting text, accept the heading as the label instead, since that is the text a visitor would naturally speak.

Troubleshooting

The accessible name is longer than the visible text

That is fine, provided the visible text appears within it. WCAG recommends the accessible name start with the visible text, but any placement passes this check.

Form fields are not tested

Text inputs and other form fields take their visible label from a <label> element rather than their own text, so they are covered by separate labeling checks instead of this one.