3.2.4 Consistent Identification
- Level AA
- Understandable
- Since WCAG 2.0
Summary
People who rely on learned patterns are the ones this criterion protects: screen reader users who navigate by familiar names, people with cognitive disabilities who memorise "the Download link" once and expect it to stay recognisable, and screen magnifier users who identify controls from a small visible fragment. If the same function is called "Download" on one page, "Get file" on another, and "Save" on a third, every one of those users has to re-learn the interface on every page. Consistency is what lets a strategy learned on page one keep working on page fifty.
The auditor's mental model: same function, same identification, across the whole set of pages. Identification means everything that tells a user what a component is, so it covers the visible label, the icon, and the accessible name (including alt text and aria-label). Two things it does not require: it does not demand that the label be good (that is descriptiveness, a different criterion), and it does not apply within a single page. You are grading cross-page consistency of repeated components, nothing more.
Official wording
Components that have the same functionality within a set of web pages are identified consistently.
EN 301 549 mapping
- Web pages
- Clause 9.3.2.4
- Software and native apps
- No software requirement: the corresponding chapter 11 clause is void in the standard.
Clause 9.3.2.4 applies this criterion to web pages unchanged. For software the standard declares the corresponding clause void, so native apps carry no mandatory equivalent: the requirement is written for sets of web pages, and equivalent sets of software programs are extremely rare.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Start by building an inventory of repeated functions across the site's templates: search, print, save, download, next and previous, help, share, add to basket. Then open a representative page from each template (home, listing, detail, article, checkout) and record how each repeated function is identified on each one: visible text, icon choice, and accessible name.
For the accessible name, use the accessibility pane in browser developer tools rather than trusting the visible label. This is where the subtle failures live: a download link can say "Download" on every page while one template gives it aria-label="Get file", and to a screen reader user those are two different controls. Names are identification, so visible consistency with inconsistent accessible names still fails the point of the criterion. Check icon text alternatives the same way: a magnifier icon whose alt text is "Search" on one page and "Find" on another is inconsistent identification of the same function.
Consistent does not mean byte-for-byte identical. "Next page" and "Next" can coexist where the shorter form is a reasonable variant in context, and a component may sensibly carry more specific wording on one page ("Download annual report" versus "Download"). What fails is unpredictable variation: three unrelated words, or the same icon meaning different things on different pages. Also confirm the scope before filing: two differently labelled search boxes on the same page are not a 3.2.4 finding, because the criterion is written across a set of pages.
iOS
The European standard declares this criterion void for software: it is written for sets of web pages, and equivalent sets of software programs are extremely rare, so a native iOS app has no mandatory obligation under it. Record it as not applicable in an EN 301 549 audit of a native app.
Auditors still apply the underlying principle as guidance, because inconsistency is just as disorienting in an app. As good practice, sweep the app's screens for repeated functions (search, share, favourite, back to a common hub) and compare their labels, SF Symbols, and accessibility labels using Accessibility Inspector or a VoiceOver pass. A search icon labelled "Search" on one screen and "Find" on another still confuses VoiceOver users even though nothing mandates otherwise; consistent naming across screens is good app craft. File such observations as recommendations, clearly marked as guidance rather than conformance failures.
Android
As on iOS, the European standard declares this criterion void for software, because it targets sets of web pages and equivalent sets of software programs are extremely rare. For a native Android app, grade it not applicable in an EN 301 549 audit.
The good-practice check, offered as guidance, mirrors the web procedure: walk the app's screens with TalkBack running, note repeated functions, and compare their visible labels, icons, and contentDescription values (Layout Inspector or the accessibility tooling in Android Studio will surface these). Watch for the same drawable reused with different content descriptions across screens, or the same action named differently in a bottom bar and an overflow menu. None of this is a conformance failure, but flagging it as a recommendation makes the app more predictable for TalkBack users and is consistent with Material Design's own emphasis on predictable, repeatable patterns.
Pass and fail examples
Passes:
- Every article page in a documentation set offers the same PDF export, labelled "Download PDF" with the same icon and the same accessible name throughout.
- A magnifier icon opens site search from the header on all pages, and its accessible name is "Search" on all of them.
- A checkout flow uses "Continue" on every step's primary button: consistent identification of the same forward action.
- One page says "Download annual report" where others say "Download": a more specific variant of the same consistent identification, not an unpredictable change.
Fails:
- The same file-export function is labelled "Download" on the product page, "Get file" in the resource centre, and "Save" in the account area.
- A printer icon triggers printing on most templates, but one template uses a document icon for print and the printer icon for something else.
- Download links visibly say "Download" everywhere, but one template overrides them with
aria-label="Export": the accessible names identify the same function inconsistently. - An icon-only search button has alt text "Search" on the home page and "Find" on article pages.
Not a fail under this criterion:
- A vague or unhelpful label used consistently on every page: consistency is satisfied, and the descriptiveness complaint belongs to Headings and Labels.
- Navigation links appearing in a different order on different pages: repeated navigation order is Consistent Navigation.
- Two components with the same label doing different things: this criterion only constrains components with the same functionality, so identical labels on different functions fall outside it (see below).
- Inconsistent labels between two controls on the same single page: the criterion applies across a set of web pages, not within one page.
Commonly confused with
- Consistent Navigation, SC 3.2.3. Its sibling at the same level, and the cleanest split in WCAG: 3.2.3 is about the order of repeated navigation mechanisms across pages, 3.2.4 is about the identification of repeated components. A menu whose items shuffle position is 3.2.3; a menu item that keeps its position but changes its name is 3.2.4.
- Headings and Labels, SC 2.4.6. 2.4.6 asks whether a label is descriptive; 3.2.4 asks whether it is consistent. A consistently used bad label passes 3.2.4 and may fail 2.4.6. Grade the two independently.
- The same label on different functions. A subtle gap: 3.2.4 only covers components with the same functionality, so two "Read more" links that go to entirely different things do not fail it. That confusion is a descriptiveness and link-purpose problem, graded under 2.4.6 or SC 2.4.4 Link Purpose (In Context), not here.
- Label in Name, SC 2.5.3. 2.5.3 compares a single control's visible label against its own accessible name; 3.2.4 compares the identification of the same function across pages. A button whose accessible name omits its visible text is a 2.5.3 finding even if every page makes the same mistake consistently.
How AUDITSU tests this
Consistency criteria cannot be graded one screen at a time, so AUDITSU's audit walkthrough handles 3.2.4 as a cross-screen check. As you review each screen, the walkthrough prompts you to log repeated functions (search, download, share, help) with their visible label, icon, and accessible name, captured with the screen reader running so the announced name is part of the evidence. Once several screens are logged, the comparison question asks whether each repeated function is identified consistently across the set, and you record a pass, fail, or not applicable result with the mismatching screens attached as evidence.
For native app audits against EN 301 549, the walkthrough marks the criterion not applicable and offers the naming-consistency check as a best-practice recommendation instead, so the observation is captured without inflating your conformance findings.
For the full guided workflow, see the audit platform.