WCAG 2.5.3 Label in Name: Connecting Visible Labels with Accessible Names

WCAG 2.5.3 Label in Name: what it requires

WCAG 2.5.3 Label in Name requires that the accessible name for a user interface component contains the visible label text. The rule ties what sighted users see to what assistive technology users hear or can speak to. This reduces confusion when the visible label appears on the page but the programmatic name does not match.

Why this matters

Many users rely on screen readers, voice commands or switch devices. If the visible label is not part of the accessible name they hear, they cannot reliably find or activate controls. That causes errors, frustration and extra effort.

Which elements it covers

• Buttons and links with visible text labels
• Form controls where a visible label is present
• Custom widgets that include a visible label (for example, custom select or toggle)
• Any control where the visible label is presented as part of the component

How accessible names are determined

The accessible name comes from the W3C Accessible Name and Description Computation. Typical sources include element text, aria-labelledby, aria-label, and the host language text. The key for WCAG 2.5.3 is that the string visible to sighted users must be present in that computed accessible name.

Common name sources

• Visible element content (for native buttons and links)
• aria-labelledby that points to visible label nodes
• aria-label that supplies a programmatic name
• Alternative text for images used as controls

Typical failures and why they happen

• Using aria-label or an icon without including the visible text. The screen reader hears only the aria-label, which may omit the visible label.
• Placing visible text outside the control so it is missed by the accessible name computation.
• Using placeholder text as a visible label. Placeholders are not reliable names.
• Updating visible label text but not updating the accessible name for dynamic content.

Concrete examples

Situation	Why it fails	How to fix it
Button shows: “Save” but has aria-label=“save item” on a child icon only	The accessible name does not include the visible word “Save” as a single string. Screen reader users may get only “save item” or nothing depending on markup.	Move the visible text into the same element or use aria-labelledby referencing the visible text node. Ensure the computed name includes “Save” exactly as seen.
Icon button shows label next to it visually, but the button element has only an empty aria-label	The visible label sits outside the interactive element and is not picked up by the accessible name algorithm.	Either wrap the visible label inside the button or give the button an aria-labelledby that points to the visible label element.
Form input shows label “Email” but the accessible name is the placeholder only	Placeholders are not substitutes for labels. The accessible name can differ from the visible label.	Use a proper or aria-labelledby. Make sure the accessible name contains the visible label string “Email”.

Step-by-step testing

1. Find an interactive control with a visible label on the page.
2. Note the exact visible label string, including punctuation and numbers.
3. Inspect the computed accessible name using the browser accessibility inspector, Axe, WAVE or a screen reader. Confirm the string the tool reports.
4. Compare both strings. If the visible text does not appear in the accessible name, mark it as a failure of Label in Name.
5. Retest after any code changes and when labels update dynamically.

How to fix common cases

• If the visible label is inside the control, ensure it is part of the element content so the accessible name naturally matches.
• If the visible label is separate, add aria-labelledby on the control pointing to the label element’s id.
• Prefer aria-labelledby when the label is already visible. Use aria-label only when there is no visible label.
• For image-only controls, use a clear or an accessible name that includes the visible text used visually.
• When labels include dynamic values, update the accessible name at the same time so both remain in sync.

Code pattern examples (described)

Failing pattern: a button element contains an icon element plus visible text placed outside the button. The button itself has an aria-label that omits the visible text. This causes a mismatch.

Passing pattern: move the visible text inside the button element so the element text becomes the accessible name. Or, give the button an aria-labelledby attribute that points to the id of the visible label node. The computed accessible name then contains the visible string.

Edge cases and notes

• If the visible label is decorative and not meant to name the control, do not link it. Instead mark it decorative with CSS or ARIA where appropriate.
• Short visual labels with icons still need the same exact string in the accessible name. Small differences can confuse voice command matching.
• Mobile voice commands and assistive tech sometimes rely on exact phrase matching. That raises the importance of including the same visible text in the accessible name.

Developer checklist

• Verify each control with a visible label has that text in its accessible name.
• Prefer aria-labelledby when binding a visible label to a control.
• Avoid relying on placeholder text as the only label.
• Keep visible and programmatic labels in sync when content updates.
• Use accessibility inspectors and screen readers during QA.

Final notes

Label in Name closes a simple but common gap between sighted and non-sighted users. The fix is often small: ensure the visible label string is part of the computed accessible name. That single change improves clarity for screen reader users and for people who control interfaces by voice.

If you want, tell me one control from your site and I will outline the exact code fix for it.