Label and name from content mismatch

Rule ID: label-content-name-mismatch
Ruleset: axe-core 3.2
User Impact: Serious
WCAG: 2.5.3
You are viewing older version of the axe rule.
Go to the latest version (3.3)

What if your accessibility tools could do more?

Axe can catch a lot of accessibility issues, but what if accessibility tools could do more? Join our beta program for a new tool that takes an exciting new approach to accessibility testing.

Compliance Data & Impact

User Impact

Disabilities Affected

  • Blindness
  • Low Vision
  • Deafblindness
  • Mobility/Dexterity

Requirement(s)

  • WCAG 2.1 (A): MUST
  • WCAG 2.0 (A): MUST
  • Section 508: MUST

WCAG Success Criteria

  • 2.5.3 Label in Name

Section 508 Guidelines

  • 1194.22 (n) Information required to complete electronic forms online

How to Fix the Problem

Fix this issue by ensuring that the accessible name — such as the aria-label — contains the text of the visible label in the same order in which it appears. While it is not necessary that the visible label and accessible name match exactly, it is a best practice to have the accessible name begin with the visible text.

The following examples pass the Label and name from content mismatch rule:

  • Visible label and accessible name matches when trailing white spaces are removed:

    <div role="link" aria-label="next page ">next page</div>
  • Character insensitivity between visible label and accessible name.

    <div role="link" aria-label="Next Page">next page</div>
  • Full visible label is contained in the accessible name.

    <button name="link" aria-label="Next Page in the list">Next Page</button>

The following examples fail the Label and name from content mismatch rule:

  • Visible label doesn’t match accessible name.

    <div role="link" aria-label="OK">Next</div>
  • Not all of visible label is included in accessible name.

    <button name="link" aria-label="the full">The full label</button>

Why this is Important

This rule applies to any element that has:

  • a semantic role that is a widget that supports name from content, and

  • visible text content, and

  • an aria-label or aria-labelledby attribute.

Note: widget roles that supports name from content are: button, checkbox, gridcell, link, menuitem, menuitemcheckbox, menuitemradio, option, radio, searchbox, switch, tab, treeitem.

Expectation

The complete visible text content of the target element either matches or is contained within its accessible name.

Note: Leading and trailing whitespace and difference in case sensitivity should be ignored.

Speech input users can interact with a webpage by speaking the visible text labels of menus, links, and buttons that appear on the screen. It is confusing to speech input users when they say a visible text label they see, but the speech command does not work because the component's accessible (programmatic) name does not match the visible label. When a user interface component has a visible text label — whether it be real text or an image of text — that text must also be found in the component's accessible (programmatic) name. When the visible label and accessible (programmatic) name for interactive components are in sync, speech input users can effectively interact with those components.

Rule Description

Interactive elements labeled through their content must have their visible label as part of their accessible name

The Algorithm (in simple terms)

For each user interface component that includes a visible text label, the accesible name MUST match (or include) the visible text in the label.

Resources

Refer to the complete list of axe 3.2 rules.

Was this information helpful?

You have already given your feedback, thank you.

Your response was as follows:

Was this information helpful ?
Date/ Time feedback was submitted :