WCAG 3.2.4: Consistent Identification

Why consistent naming matters

Recognition is cheaper than comprehension. Once a user has learned that the disk icon labelled “Save” stores their work, every later encounter costs them nothing — they recognize it and act. Rename it “Store” on the next page and the shortcut breaks: now they must stop, read, and reason about whether this new thing is the old thing. For most users that is friction; for some it is a wall.

Screen reader users are hit hardest, because the accessible name isthe component to them. Searching a page for the “Save” button fails when this template calls it “Store”. Users with cognitive limitations — including people who memorize one term per function, users of symbol-based communication, and people with limited reading vocabulary — depend on stable naming the same way. And users of speech recognition software literally invoke controls by name: “click Search” does nothing if the button is called “Find” here.

There is a corollary the Understanding document calls out: things that do different jobs must notshare a name. If a checkmark icon means “approved” in one view and “task complete” in another, its text alternative must differ to match the function. Consistency binds name to function in both directions.

What must stay consistent

“Identification” is every signal a user might use to recognize the component:

Consistent does not mean robotic. Context-appropriate precision is allowed: a pagination arrow labelled “Go to page 4” on one page and “Go to page 5” on the next identifies the same function the same way. The test is whether a user who learned the component once will recognize it instantly the next time.

Pass and fail examples

Code examples

Inconsistent vs. consistent identification

The same search function, hand-coded per template, drifts into three identities. Pin one label and one icon for the function site-wide.

<!-- ✗ Same function, three different identities -->
<!-- home template -->
<button><svg aria-hidden="true">…magnifier…</svg> Search</button>
<!-- blog template -->
<button><svg aria-hidden="true">…binoculars…</svg> Find</button>
<!-- docs template -->
<button aria-label="Go"><svg aria-hidden="true">…magnifier…</svg></button>

<!-- ✓ One identity everywhere: same icon, same accessible name -->
<button type="submit">
  <svg aria-hidden="true" focusable="false">…magnifier…</svg>
  Search
</button>

Alt text names the function, identically

For repeated image controls, the text alternative is the identification screen reader users rely on. Name the function, and keep the name stable.

<!-- ✗ The same print control drifts between pages -->
<input type="image" src="/icons/print.svg" alt="Print" />      <!-- page A -->
<input type="image" src="/icons/print.svg" alt="Printer" />    <!-- page B -->
<input type="image" src="/icons/print.svg" alt="" />           <!-- page C -->

<!-- ✓ One function, one name, everywhere -->
<input type="image" src="/icons/print.svg" alt="Print this page" />

Enforce consistency with a shared component

The structural fix: define each repeated function as one component with its label and icon baked in, so templates cannot improvise.

// download-button.tsx — the single source of identity
export function DownloadButton({ href }: { href: string }) {
  return (
    <a href={href} download className="btn">
      <DownloadIcon aria-hidden="true" />
      Download PDF
    </a>
  )
}

// Every template renders <DownloadButton /> — the label,
// icon, and accessible name cannot drift between pages.

Common failures

• ✗Synonym drift: the same function labelled 'Search' / 'Find' / 'Go', or 'Download' / 'Get PDF' / 'Save file', on different pages.
• ✗The same icon function with different text alternatives across pages — or alt text that names the image ('Magnifying glass') instead of the function ('Search').
• ✗Different icons for the same function between templates, usually after a partial redesign or a mixed icon library.
• ✗Visible label kept consistent while the accessible name varies (a changing aria-label overriding the same button text), so speech-input and screen reader users get a different identity than sighted users.
• ✗Two different functions sharing one label — e.g. 'Submit' for both 'save draft' and 'publish' — so users cannot distinguish them.
• ✗Teams editing copy per page in a CMS with no shared component or style guide, letting identical functions accumulate different names over time.

How to test for 3.2.4

1. 1

   Inventory the repeated functions

   List functions that recur across pages: search, print, download, save, share, help, cart, next/previous, close. These are the components 3.2.4 audits.

2. 2

   Sample pages from every template

   Pick pages built from each distinct layout — home, listing, detail, blog, docs, account. Naming drift almost always happens between templates and teams, not within one page.

3. 3

   Compare visible labels and icons

   For each function, record its visible text and icon on every sampled page. Any arbitrary variation — synonyms, different icons — is a failure. Contextual precision ('Go to page 4' vs 'Go to page 5') is fine.

4. 4

   Compare accessible names

   Use the browser's accessibility inspector or a screen reader to read each control's accessible name (label, alt, aria-label). The name for the same function must match across pages, and must match what sighted users see.

5. 5

   Check the inverse: different functions, different names

   Scan for distinct functions sharing one identity — the same icon or label doing different jobs in different places. Give each function its own stable name.

Automated tools cannot compare naming across pages, so this is a manual audit — best done once, then locked in with shared components and a content style guide. Fold it into the full WCAG 2.2 checklist.

Frequently asked questions