What’s New in WCAG 2.1: Label in Name

WCAG 2.1’s Label in Name Criterion, Explained

WCAG 2.1 introduced several new Success Criteria when it arrived in 2018. One of the more impactful additions for form and interface design is Label in Name (criterion 2.5.3), which governs how the visible text on a component relates to its programmatic name.

What the criterion requires

For those unfamiliar with the terminology, a Success Criterion is a testable, technology-agnostic statement used to measure accessibility conformance. Label in Name sits in the “Operable” category under “Input Modalities” and is rated Level A, meaning it represents a base level of compliance.

The criterion itself is concise:

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

The intent is straightforward: the words a user sees on a control should also appear in the control’s accessible name — the programmatic label exposed to assistive technologies. The two don’t need to be identical; a visual “Submit” paired with an accessible name of “Submit Now” satisfies the requirement because they share a common term. The goal is to eliminate confusion between what is read aloud or processed by assistive tech and what is visibly rendered on screen.

Why mismatches break assistive tech

Consider a contact form where the submit button displays “Send” but carries an aria-label of “Submit”:

<form>
  <label>
    Message:
    <textarea name="message"></textarea>
  </label>

  <button aria-label="Submit">Send</button>
</form>

This button fails the criterion. The visible label (“Send”) has no association with the accessible name (“Submit”), so speech-recognition users who try to activate the control by speaking the text they see will get no response. The mismatch creates friction and can even trigger accidental commands when the hidden accessible name functions as an unexpected voice command.

A simple fix is to remove the redundant aria-label entirely, letting the button’s visible text serve as its accessible name:

<form>
  <label>
    Message:
    <textarea name="message"></textarea>
  </label>

  <button>Send</button>
</form>

Sighted screen-reader users also benefit when audible output matches on-screen text, reducing the cognitive load required to reconcile two different terms for the same control.

Common failure patterns

Several recurring anti-patterns violate Label in Name:

• A <button> whose spoken label and visual text share no common words.
• A label mismatch caused by an “accessibly hidden” span that adds text to the accessible name not present visually.
• An input using aria-labelledby whose referenced text fails to establish a correlation with the visible label.

These issues are widespread. The WebAIM Million project, which evaluated 4.2 million form inputs in 2020, found that 55% were improperly unlabeled — whether via a missing <label>, absent aria-label, or broken aria-labelledby association.

Pairing a <label> with an input is a good start, but the accessible name must also align. If a field is visually labeled “First Name,” the aria-label should use the same or similar wording. Failing to connect these names creates extra cognitive work: speech-input users must remember a different spoken command than the text they see, and screen-reader users must reconcile audio output with the visual interface.

Determining which text counts as the label

Interfaces often contain multiple text strings near a single control, so it’s important to identify which one functions as the visible label. Best practices for predictability suggest positioning labels:

• immediately to the left of text inputs, dropdowns, and similar widgets;
• immediately to the right of checkboxes and radio buttons;
• inside buttons or tabs, or directly below icons that function as buttons.

Punctuation and capitalization are treated as optional when used symbolically. “First Name” works fine without a trailing colon, and “Next” is acceptable without an ellipsis. Note also that components lacking any visible text label fall outside the scope of this criterion. Similarly, text used symbolically rather than as human language — such as icons in a rich text editor — is governed by the separate Images of Text criterion (1.4.5).

Why it matters

Aligning visible labels with accessible names gives speech-input users the ability to activate controls directly by speaking what they see, without guessing at alternate terms. The payoff extends beyond compliance: consistent terminology between visual and programmatic labels creates a smoother experience for all users, since assistive technologies read names that match what everyone else sees on screen.

Developers can verify conformance by inspecting source code, using browser DevTools, or running automated checks with tools such as the WAVE extension or Axe from Deque Systems. The criterion may sound like a minor detail, but for users who rely on speech input or screen readers, a label that matches what they see is often the difference between a usable interface and an inaccessible one.