Consistent Identification

In brief

If one page calls a button "Search" and another calls the same button "Find", users must work out whether they do the same thing. For people with cognitive disabilities, and for screen reader users who rely on names, a different word means a different function.

This criterion requires that components that have the same functionality within a set of web pages are identified consistently.

What does it cover?

• Same functionality: Components that give the same result when used. Components that only look alike but do different things need not share identification.
• What is identified: The label, name and text alternative, for example the visible label, the accessible name, and the alt text of an icon or image that works as a control.
• Not identical labels: Labels can vary to suit the context. "Page 4" on one page and "Previous page" on the next are fine if each is identified consistently for what it does.
• Repeated components: The criterion covers components that recur across the set, such as search, account controls, navigation and footer links. One-off components with a similar purpose are not required to match.
• Functional components only: Consistent naming of non-functional content is good practice, not a requirement.
• Set of web pages: Pages with a common purpose, made by the same author, group or organisation.
• Combine with other criteria: G197 is used together with the techniques for 1.1.1 and 4.1.2 that provide the labels, names and text alternatives.
• Out of scope: Order of repeated navigation is 3.2.3. Meaningful labels are 2.4.6.

Who does it affect?

People with cognitive and learning disabilities, who learn a function once and recognise it elsewhere. Screen reader users, who depend on names to understand what a control does. People who use speech recognition, who say the name of the control. People with low vision who recognise controls by their labels.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Consistent identification is part of "understandable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 3.2.4 by reference and turns it into separate clauses for each kind of ICT.

In EN 301 549 V3.2.1 the software clause did not carry this criterion, because it concerns sets of web pages. Check whether V4.1.1 changes that. Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 3.2.4 is the same in WCAG 2.1 and 2.2. It is a Level AA criterion.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. Two names for the same function

A "Search" button on one page and a "Find" button on another is the failure W3C describes (F31).

<!-- Page A -->
<button>Search</button>
<!-- Page B -->
<button>Find</button>

<!-- Every page -->
<button>Search</button>

2. Icons used as controls

The text alternative of an icon that does the same thing must be the same on every page.

<!-- Page A -->
<a href="/cart"><img src="cart.svg" alt="Cart"></a>
<!-- Page B -->
<a href="/cart"><img src="cart.svg" alt="Shopping basket"></a>

<a href="/cart"><img src="cart.svg" alt="Cart"></a>

3. Names that follow context

A label can change when the context changes, as long as the same function has the same name. "Next page" can be "Go to page 5".

<!-- Page 4 -->
<a href="?p=5">Next</a>
<!-- Page 5 -->
<a href="?p=6">Forward</a>

<a href="?p=5">Go to page 5</a> <!-- context-specific but consistent for its function -->

4. Accessible names match visible labels

When the visible label is consistent, keep the accessible name consistent too.

<!-- Page A --><button aria-label="Download PDF">Download</button>
<!-- Page B --><button aria-label="Get file">Download</button>

<button aria-label="Download PDF">Download</button>

5. Use shared components

Reusing one component for the same function keeps labels aligned without extra effort (G197).

<!-- Each team writes its own "Contact" button -->

<!-- components/ContactLink.html used on every page -->
<a class="contact" href="/contact">Contact us</a>

6. Different functions can differ

Components that do different things need not match, even if they look alike.

<button>Save</button> <!-- saves a draft on one page, publishes on another -->

<button>Save draft</button>
<button>Publish</button>

Code examples for mobile

Apps repeat the same controls across screens: back, search, share, profile. Use the same label and the same accessibility name for the same function throughout the app.

iOS (SwiftUI)

import SwiftUI

// One shared view, so the label and accessibility name never drift apart
struct ShareButton: View {
    var action: () -> Void

    var body: some View {
        Button(action: action) {
            Image(systemName: "square.and.arrow.up")
        }
        .accessibilityLabel("Share")
    }
}

Android (Jetpack Compose)

import androidx.compose.material.icons.Icons
import androidx.compose.material.icons.filled.Share
import androidx.compose.material3.Icon
import androidx.compose.material3.IconButton
import androidx.compose.runtime.Composable

// One shared composable, so the name is the same on every screen
@Composable
fun ShareButton(onShare: () -> Unit) {
    IconButton(onClick = onShare) {
        Icon(Icons.Filled.Share, contentDescription = "Share")
    }
}

How to test

• List repeated components: Find search, cart, account, share, print, download, contact and navigation controls that appear on many pages.
• Compare their labels: Is the visible label the same wherever the component appears?
• Compare their names and alternatives: Check the accessible name and the alt text of icons that work as controls. Are they the same?
• Check function, not look: Group by what the component does. Components that do the same thing should be named the same.
• Check different page types: Compare labels in the header, footer, product pages, forms and error pages.
• Check the exceptions: Is a label different because the context really changed, and still consistent for its function?
• Use a checker as a starting point: Automated tools cannot compare the same function across pages. A person must review the labels.

Common mistakes

• Two labels for one function: The failure W3C describes (F31).
• Icon alt text that differs between pages: "Cart" on one page and "Basket" on another.
• Visible labels that match but accessible names do not: The aria-label differs between pages.
• Separate teams, separate wording: No shared components or content guidelines.
• Translated inconsistently: The same function translated with different words in the same language.
• Wording changed by A/B tests: Variants that rename a control on some pages only.
• Same name for different functions: A "Save" button that does two different things.
• Treating it as identical pages: Only components with the same function must match.

Sources

• Understanding SC 3.2.4: Consistent Identification (W3C), opens in a new tab
• G197: Using labels, names, and text alternatives consistently for content that has the same functionality (W3C), opens in a new tab
• F31: Failure of Success Criterion 3.2.4 due to using two different labels for the same function on different web pages within a set of web pages (W3C), opens in a new tab
• Directive (EU) 2019/882, European Accessibility Act (EUR-Lex), opens in a new tab
• EN 301 549 V4.1.1 (ETSI), opens in a new tab
• The European accessibility standard EN 301 549 has been updated (AccessibleEU), opens in a new tab

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.