WCAG 3.2.4: Consistent Identification

What This Rule Means

WCAG Success Criterion 3.2.4 — Consistent Identification — states that components which have the same functionality within a set of web pages must be identified consistently. This means that whenever an interactive element or image performs the same function, it should carry the same accessible name or label each time it appears across the site.

The term "identified" in this context refers to how a component is presented to assistive technologies and users. This includes the visible label text, the aria-label or aria-labelledby attribute, the alt text on an image, the title attribute, or the accessible name computed by the browser's accessibility tree. If a search button appears on every page of a site, it must always be called "Search" — not "Search" on the homepage, "Find" on the product listing page, and "Go" on the checkout page.

This criterion applies to a set of web pages, which WCAG defines as a collection of pages sharing a common purpose and produced by the same author. This covers an entire website, a web application, or a multi-step form spanning several URLs. Components that are merely visually similar but serve different functions are not required to share the same name — the requirement is specifically tied to identical functionality.

What counts as a pass: A navigation icon that opens a hamburger menu is consistently labelled "Open navigation menu" (or equivalent) across all pages. A shopping cart icon always has the alt text or accessible name "Shopping cart". A logout button is always labelled "Log out". Variation in wording for the same function constitutes a failure.

What counts as a fail: A submit button labelled "Submit" on the registration form but labelled "Send" on the contact form when both buttons serve the same functional purpose of transmitting user-entered data. An icon button showing a magnifying glass labelled "Search" on most pages but "Ara" on a single translated sub-page without a consistent language strategy in place.

Official exception: WCAG explicitly notes that it is acceptable to have two components with the same accessible name if they perform different functions — in that case, the different function itself disambiguates them. The criterion only fires when function is identical but naming is inconsistent.

Why It Matters

Inconsistent identification creates a disproportionate burden on users who rely on non-visual or pattern-based navigation strategies. The groups most severely affected include screen reader users, users with cognitive disabilities, and users with motor impairments who rely on voice control software.

Screen reader users build a mental model of a website by listening to element names as they tab through or browse by landmark. When a button that performed the same function on the previous page now has a different name, the user must stop, investigate, and re-orient — a time-consuming and frustrating experience. According to the World Health Organization, approximately 2.2 billion people globally have some form of vision impairment. Even a fraction of that population interacting with an inconsistently labelled site will encounter significant barriers.

Users with cognitive disabilities, including those with dyslexia, attention deficit disorders, or memory impairments, depend heavily on predictable naming to reduce cognitive load. Encountering a familiar icon or control under a different name forces re-learning and causes anxiety. Consistent labelling reduces the effort needed to build procedural memory when using a site regularly.

Voice control users (using tools like Dragon NaturallySpeaking or Apple's Voice Control) speak the name of a control to activate it. If the accessible name of a button differs from what they expect based on prior experience with the site, their spoken command will fail silently — the software simply will not find a match. This makes the interface effectively unusable at that moment.

A concrete real-world scenario: Consider a Turkish e-commerce platform that sells clothing. On the product grid page, each item has a button with a heart icon whose accessible name is "Add to favourites". On the product detail page, the same heart icon's accessible name is "Kaydet" (Turkish for "Save"). A screen reader user who learned to activate the heart button by name on the grid page now cannot find the equivalent control on the detail page without exhaustive exploration. They may abandon the site entirely.

Beyond accessibility, consistent labelling benefits SEO. Search engines parse accessible names and link text to understand page content. Inconsistent labelling for functionally identical links (e.g., "Read more", "Continue reading", "Learn more" all pointing to article detail pages) dilutes keyword signals and makes it harder for crawlers to understand site structure.

Related Axe-core Rules

WCAG 3.2.4 requires manual testing because automated tools cannot determine semantic intent across pages or know that two differently-named components perform the same function. No axe-core rule maps directly to this criterion. Here is why automation falls short and what testers must do instead:

• Manual testing required — cross-page consistency: Axe-core evaluates a single page in isolation. It has no mechanism to compare the accessible name of a "Search" button on the homepage with a "Find" button on a product page, because it does not maintain a cross-page inventory of component names. A human tester must catalogue repeated functional elements and verify their naming is uniform across all pages where they appear.
• Manual testing required — icon and image alt text consistency: Automated tools can detect missing alt text (via the image-alt rule) but cannot determine whether two images serving the same purpose carry the same alt text across different pages. For example, a printer icon on a receipts page and the same printer icon on an invoice page may both have alt text — but if one reads "Print" and the other reads "Print this page", a human must judge whether this constitutes an inconsistency under 3.2.4.
• Manual testing required — ARIA label consistency: Axe-core checks that ARIA labels are present and non-empty, but it does not audit whether aria-label values for the same component type are consistent across the full set of pages. A tester must inspect the accessibility tree on multiple pages and compare names for functionally identical controls.
• Manual testing required — form control labels: Automated rules like label verify that inputs are associated with labels, but they do not check whether a "Username" field on the login page is also labelled "Username" (rather than "Email" or "User ID") on the account recovery page when both fields accept the same type of input and serve the same functional role.

How to Test

1. Automated pre-scan: Run axe DevTools or Lighthouse on each page to surface any related violations such as missing accessible names (image-alt, button-name, link-name). Resolve these first — you cannot assess naming consistency if names are absent. Note the accessible names reported for repeated components across your scan results.
2. Create a component inventory: Manually list all functional components that repeat across pages — navigation menus, search inputs, submit buttons, icon buttons, breadcrumb links, social media links, print/share buttons, and pagination controls. Record the accessible name of each instance using your browser's Accessibility panel (Chrome DevTools > Elements > Accessibility, or Firefox Accessibility Inspector).
3. Compare names across pages: For each component type in your inventory, verify that every instance carries the same accessible name. Flag any discrepancy. Pay particular attention to components that appear in page headers, footers, and sidebars, as these are most likely to be inconsistently labelled across templates.
4. Screen reader testing with NVDA + Firefox: Navigate to the homepage, then use NVDA's element list (Insert + F7) to open the buttons and links list. Note the names of repeated controls. Then navigate to three or four other representative pages and repeat. Listen for any name variation on functionally identical controls.
5. Screen reader testing with VoiceOver + Safari (macOS/iOS): Use the Rotor (VO + U) to bring up the buttons or links list on each page. Compare names of repeated elements. On iOS, swipe through interactive elements on equivalent pages and note any naming differences.
6. Screen reader testing with JAWS + Chrome: Use the JAWS virtual cursor and the list of form fields (Insert + F5) and links (Insert + F7) across multiple pages. Confirm that identical controls share identical names throughout the site.
7. Voice control test: Using Windows Voice Access or Dragon NaturallySpeaking, speak the name of a repeated control on one page (e.g., "Click Search"). Navigate to another page and speak the same command. If it fails, the names are inconsistent from a functional standpoint.

How to Fix

Search button with inconsistent labels — Incorrect

<!-- Homepage -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Product listing page -->
<button type='submit' aria-label='Find products'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Blog page -->
<button type='submit' aria-label='Go'>
  <svg aria-hidden='true'>...</svg>
</button>

Search button with inconsistent labels — Correct

<!-- Homepage, product listing page, and blog page all use the same label -->
<!-- Consistent aria-label across all pages ensures assistive technologies
     always announce the same name for this functionally identical button -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

Icon image used for the same action with differing alt text — Incorrect

<!-- Order history page -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print order' />
</a>

<!-- Invoice page -->
<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print this document' />
</a>

<!-- Receipt page -->
<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Yazdir' />
</a>

Icon image used for the same action with differing alt text — Correct

<!-- All print links across the site share the same alt text.
     The destination URL differentiates which document is printed;
     the control's accessible name remains consistent. -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Print' />
</a>

Navigation close button inconsistently named — Incorrect

<!-- Mobile menu on homepage -->
<button aria-label='Close menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Mobile menu on product page (different developer implemented it) -->
<button aria-label='Dismiss navigation' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Navigation close button inconsistently named — Correct

<!-- A shared component/template ensures the label is identical everywhere.
     Using a single reusable component or design token for the label
     eliminates the risk of developer-introduced inconsistencies. -->
<button aria-label='Close navigation menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Social sharing links with varying names — Incorrect

<!-- Article page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

<!-- Video page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Tweet this'>
  <svg aria-hidden='true'>...</svg>
</a>

Social sharing links with varying names — Correct

<!-- Both pages use the same accessible name for the functionally
     identical sharing action. The URL parameter carries the context;
     the control name stays uniform. -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

Common Mistakes

• Using different aria-label values in different templates for the same component: When separate developers build page templates independently without a shared component library, icon buttons such as close, search, and cart frequently receive ad-hoc labels. Establish a design system token or shared component for every repeated interactive element so the accessible name is defined once and reused everywhere.
• Translating accessible names inconsistently across multilingual pages: A site may correctly label a search button "Search" in English but then use an inconsistent Turkish equivalent — sometimes "Ara", sometimes "Arama Yap" — depending on which page template was localised first. Maintain a single translation key per component label and enforce it across all locale files.
• Appending context-specific suffixes to otherwise identical controls: Labelling buttons "Add to cart — Blue T-Shirt", "Add to cart — Red Dress" etc. when the core function (add to cart) is the same is not an automatic 3.2.4 failure — WCAG permits disambiguation — but doing so inconsistently (sometimes with suffix, sometimes without) creates confusion. Choose one pattern and apply it uniformly.
• Relying on the visible text label to carry consistency while aria-label overrides differ: When a button visually reads "Search" but one template adds aria-label='Search the site' and another has no aria-label (so the accessible name is derived from visible text alone), screen readers will announce different names even though the button looks the same. Audit the full accessible name computation, not just the visible label.
• Letting CMS editors freely change button text without accessibility governance: Content management systems that expose button labels as editable fields allow editors to rename "Submit" to "Send" or "Gönder" based on personal preference. Restrict label editing for functional UI components or add validation that warns editors when a proposed label diverges from the established standard.
• Failing to audit third-party widgets or embedded components: Chat widgets, cookie consent banners, and payment iframes injected by third parties often contain buttons labelled differently from the host site's conventions. Review and, where possible, configure third-party accessible names to align with your naming conventions, or document the deviation as a known exception.
• Using tooltip text (title attribute) as the sole accessible name on some instances but aria-label on others: The title attribute is not reliably announced by all assistive technologies and is considered a weak accessible name source. If some instances of a repeated component use title and others use aria-label, the computed names may differ due to browser and screen reader handling differences.
• Assuming pagination controls are exempt because their numbers differ: "Next page" and "Previous page" controls, even when they carry a page number in their label (e.g., "Go to page 3"), must apply a consistent pattern. Mixing "Next" on some pages with "Next page" or "İleri" on others for the same pagination control fails 3.2.4.
• Not testing header and footer components on every distinct page template: Sites often have multiple page templates (homepage, category page, article page, checkout). Header and footer components may render slightly differently across templates. Testers who only check one or two templates may miss inconsistencies introduced by template-specific overrides.
• Confusing 3.2.4 with 3.2.3 (Consistent Navigation): Teams sometimes believe that if navigation order is consistent (3.2.3), naming must be too — but these are separate requirements. A navigation bar in the same location on every page (3.2.3 compliance) can still fail 3.2.4 if its links are labelled differently across pages. Address both criteria explicitly in your QA process.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes binding accessibility requirements for a wide range of public and private digital services. The Circular mandates conformance with internationally recognised accessibility standards — in practice aligning with WCAG 2.2 Level AA — and ties this conformance to the Accessibility Logo (Erişilebilirlik Logosu) issued by the Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 3.2.4 Consistent Identification is a Level AA criterion, meaning it is a mandatory requirement — not an advisory recommendation — for organisations seeking to obtain or retain the Erişilebilirlik Logosu. Failure to implement consistent identification across a digital service will prevent full AA conformance and, consequently, eligibility for the logo.

The Circular explicitly covers the following entity types, all of which must address WCAG 3.2.4 in their web and mobile interfaces: public institutions and government agencies; banks and financial service providers; hospitals and healthcare platforms; telecommunications operators with 200,000 or more subscribers; e-commerce platforms; travel agencies and booking services; private transportation companies; and private schools authorised by the Ministry of National Education (Milli Eğitim Bakanlığı).

For these organisations, the practical implication is significant. Large institutional websites — such as a bank's internet banking portal, a hospital's appointment booking system, or a university's student information system — typically span hundreds of pages and are built by multiple development teams over many years. Inconsistent labelling of repeated controls (account action buttons, search bars, navigation icons) across these pages is a common and easily overlooked failure mode. Compliance programmes must include cross-page consistency audits as a dedicated testing phase, not merely single-page automated scans.

Turkish organisations pursuing the Erişilebilirlik Logosu should integrate WCAG 3.2.4 checks into their design system governance, content management workflows, and QA pipelines. Specifically, every reusable UI component should have its accessible name defined as a non-editable constant at the design system level, with translation keys managed centrally to ensure Turkish and any other language variants remain consistent across all pages and templates where the component appears.