WCAG 3.2.4 Consistent Identification is a Level AA success criterion that says any component appearing across a set of pages with the same function must be identified consistently. In plain terms: if a control does the same job on every page, give it the same accessible name everywhere — don’t call one button “Search” and an identical one “Find.”

What 3.2.4 actually requires

The official wording from the W3C Understanding document is short: “Components that have the same functionality within a set of web pages are identified consistently.” Three words carry the weight.

  • “Same functionality” — two controls that do the same thing (submit a search, download the current document, save the form). Whether they look identical doesn’t matter; what they do does.
  • “Set of web pages” — the criterion is cross-page. A single page that uses one label internally can still fail when a sibling page names the same function differently.
  • “Identified consistently” — the accessible name (visible label, button text, link text, or image alt) follows a consistent pattern.

Crucially, consistent is not identical. W3C gives the pagination example directly: a “next page” arrow with alt text “Go to page 4” on one page and “Go to page 5” on the next is consistent — the pattern holds even though the number changes — and so it passes. The line is crossed only when the same function gets a genuinely different name.

Who it affects

This criterion lives under the Understandable principle (the “U” in POUR), and its primary audience is people who struggle when interfaces are unpredictable:

  • People with cognitive and learning disabilities benefit most. They recognize a repeated control by its name. When the same action is “Submit” here and “Send” there, that’s a fresh cognitive puzzle each time — exactly the load 3.2.4 exists to remove.
  • Screen reader users (JAWS, NVDA, VoiceOver) navigate by the announced accessible name, not the icon. Two identical-looking buttons with different aria-label values are announced differently, so the user can’t tell they’re the same function.
  • Speech-input users (Dragon, Voice Control) say the visible label out loud to activate a control. Inconsistent names mean a command that works on one page fails on the next.
  • People with low vision using magnification see only a slice of the screen at a time and lean on familiar labels to orient themselves.

Concrete failure examples — and the fixes

The documented failure is F31: using two different labels for the same function on different web pages. Here are the patterns we actually find during a site audit.

1. The “Search” / “Find” split. The home page has a <button>Search</button>; the results page has a <button>Find</button> driving the exact same query. This is W3C’s own textbook failure. Fix: pick one verb and use it for that function site-wide.

2. Identical buttons, mismatched aria-label. This one is invisible on screen — both buttons read “Save” — but assistive tech hears two different things:

<!-- Product page -->
<button aria-label="Save item to wishlist">Save</button>

<!-- Cart page (same wishlist function) -->
<button aria-label="Add to favorites">Save</button>

To a sighted user these are the same button. A screen reader announces “Save item to wishlist, button” and “Add to favorites, button” — two names for one function. Fix: use the same accessible name for the same action.

<button aria-label="Save item to wishlist">Save</button>
<!-- ...and the identical aria-label everywhere this control appears -->

This is also why misused ARIA labels and roles are a common source of 3.2.4 failures — the visible text looks consistent while the overridden name silently drifts.

3. Icon controls with drifting alt text. A document-download icon is alt="Download PDF" in the resources list and alt="Get file" in the footer. Same icon, same function, two names. Fix per W3C’s G197 technique: label the function consistently — alt="Download [document title]" everywhere — which keeps it consistent while still naming each specific file. (See alt text best practices for getting the wording right.)

4. The “Print receipt” / “Print invoice” trap — which is not a failure. W3C explicitly calls a printer icon labeled “Print receipt” on one page and “Print invoice” on another consistent, because the pattern is identical and the difference reflects genuinely different content. Don’t over-correct these into a vague shared “Print” and lose the useful context.

The recurring fix is structural: define the accessible name for each reusable control once, in a shared component or template, so the same name ships to every page automatically. That’s why 3.2.4 problems cluster in hand-built or page-by-page sites and rarely appear where a real component library enforces the label.

How to test for 3.2.4

It’s a cross-page consistency check, so automated scanners — which look at one page at a time — almost never catch it. F31’s test procedure is two manual steps:

  1. Inventory repeated functional components. Across your key page set (home, category, product, cart, contact, account), list every control that recurs: search submit, add-to-cart, save, download, the logo home-link, social icons, “read more” links.
  2. Compare the accessible name of each. For every repeated function, confirm the name follows a consistent pattern from page to page. Read the visible label and the computed accessible name — inspect aria-label, aria-labelledby, title, and image alt, because the override is where consistency breaks.

A fast way to surface mismatches: open each page in a screen reader, pull up the list of buttons or links, and listen for the same function announced two different ways. Because the criterion hinges on intent and equivalence — only a person can confirm two controls truly share a function — this is firmly in the territory of expert manual review, not a one-click tool. Where each name is computed from is governed by 4.1.2 Name, Role, Value, so the two criteria are best tested together.

3.2.4 is part of WCAG 2.1 Level AA, the standard that anchors most U.S. web accessibility law. The Department of Justice’s April 2024 Title II rule formally adopted WCAG 2.1 AA for state and local government sites, per ADA.gov — which sharpens AA as the practical benchmark for private businesses too. Digital accessibility lawsuits continue at high volume: UsableNet recorded over 4,000 ADA-related digital lawsuits in 2024 in its 2024 year-end report.

You won’t often see “3.2.4” named alone in a demand letter — it’s rarely the headline. But inconsistent labels surface during the same expert testing that documents the bigger failures, and they undercut any claim of conformance: a site that names the same checkout action three different ways visibly isn’t built to AA. Fixing 3.2.4 also pays off beyond compliance — consistent labeling reduces support tickets and abandoned carts for every user.

This is general information, not legal advice. For your specific exposure, consult a qualified attorney.

Fixing it the right way — not with an overlay

Consistent identification is a content and code problem, and no accessibility widget can solve it. An overlay can’t know that your “Search” button and your “Find” button are the same function, and it certainly can’t rewrite your aria-label values to match across templates. The durable fix is to standardize the accessible name for each reusable control in your source — exactly the kind of hands-on remediation Curbcut does, working through your components page by page so the same function speaks with one voice. Want to know where your labels drift? Start with a free scan and we’ll show you which repeated controls are out of sync — then fix them for you.