Level AA

Shared components hand-authored per page drift in label, icon, and accessible name, forcing users to re-identify the same control on every page

3.2.4 Consistent Identification

In Plain Language

3.2.4 Consistent Identification (Level AA) requires that components with the same functionality across a set of pages are identified consistently -- same visible label, same accessible name, same icon, same text alternative[1]. A control that prints the current page should be labeled "Print" on every page it appears, not "Print" on one page and "Generate PDF" on the next.

Consistency here is about identification, not order. The sibling criterion 3.2.3 Consistent Navigation governs the order of repeated navigation components[2]; 3.2.4 governs how each component is named and depicted once it appears.

Why It Matters

  • Screen-reader users identify a control by its accessible name. When the same "Print" button is exposed as Print this page on one route and Generate hard copy on another, the two controls read as two different features and the user cannot reuse a learned shortcut or a cached mental model of the interface.
  • Users with cognitive and learning disabilities build recognition around a label-plus-icon pair[1]. A magnifying-glass icon labeled "Search" on the home page and a binoculars icon labeled "Find" on a category page breaks that pairing and forces serial re-discovery of the same control.
  • Voice-control users speak the visible label to activate a control. If the label drifts across pages -- "Search" here, "Find Items" there -- the command that worked on the previous page silently stops working, with no indication the target has been renamed.
  • A common failure pattern is a visible label that matches across pages while the aria-label diverges[1]. Sighted users see consistency; assistive-technology users hear two different controls. The mismatch also risks tripping 2.5.3 Label in Name on each page.

Examples

Do: Use the same label for the same function across pages

Products page:

Categories page:

✔ Same labels and icons for the same functions on both pages

<!-- Products page -->
<button>Search</button>
<button>Add to Cart</button>

<!-- Categories page -- same labels -->
<button>Search</button>
<button>Add to Cart</button>
Don't: Use different labels for the same function

Products page:

Categories page:

✘ Same functions but different labels -- Search vs Find Items, Add to Cart vs Buy Now

<!-- Products page -->
<button>Search</button>
<button>Add to Cart</button>

<!-- Categories page -- FAILS: different labels -->
<button>Find Items</button>
<button>Buy Now</button>
<!-- Same functions, different names -->
Do: Use consistent alt text for icons with the same function

Article page:

<img src="print.svg" alt="Print this page">

Report page:

<img src="print.svg" alt="Print this page">

✔ Same icon with same alt text on both pages

<!-- Article page -->
<button>
  <img src="print.svg" alt="Print this page">
</button>

<!-- Report page -- same alt text -->
<button>
  <img src="print.svg" alt="Print this page">
</button>
Don't: Use different icons or alt text for the same function

Article page:

<img src="print.svg" alt="Print this page">

Report page:

<img src="printer.svg" alt="Generate hard copy">

✘ Same function but different icon and alt text across pages

<!-- Article page -->
<button>
  <img src="print.svg" alt="Print this page">
</button>

<!-- Report page -- FAILS: different icon and alt -->
<button>
  <img src="printer.svg" alt="Generate hard copy">
</button>
<!-- Same function, different identification -->

How to Fix It

  1. Render shared controls from a single source of truth. Build one component per repeated function (search field, print button, share menu) and import it on every page. When visible label, icon, and aria-label live in one template, drift becomes a code change rather than an editorial accident.
  2. Do not let per-page authors hand-write the accessible name. A CMS field that lets a content author override the label on one page is the most common source of 3.2.4 failures. Lock the label on shared components at the template level; if variation is needed, it should reflect a genuine difference in function.
  3. Match visible label and accessible name. If the visible text is "Search", the accessible name (whether from the text node, aria-label, or aria-labelledby) must begin with "Search". A mismatch is an independent 2.5.3 Label in Name failure and also creates the exact inconsistency 3.2.4 forbids[1].
  4. Audit icon-only buttons across templates. For every icon-only control, confirm the same SVG and the same accessible name ship on every page where that function appears. Automated checks can diff accessible names for matching selectors across a crawl.
  5. Consistent does not mean identical. Context-appropriate variation is permitted when structure stays uniform -- "Print receipt" and "Print invoice" on different transaction pages are consistent, because the pattern "Print [document]" is preserved[1]. Different functions warrant different labels; the same function does not.

References

  1. [1] W3C (2023). Understanding Success Criterion 3.2.4: Consistent Identification. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/consistent-identification.html ↩ ↩ ↩ ↩ ↩
  2. [2] W3C (2023). Understanding Success Criterion 3.2.3: Consistent Navigation. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/consistent-navigation.html ↩