The 2025 TestParty Guide to WCAG 3.2.4 – Consistent Identification (Level AA)

Why did the search icon break up with the magnifying glass emoji? Because on one page it was labeled "Search," on another "Find," and on the homepage "Look stuff up"—talk about commitment issues!

WCAG 3.2.4 requires that components with the same function are identified the same way across your entire website. If your search button is labeled "Search" on one page, it can't be "Find" on another and "Lookup" on a third. This consistency helps users—especially those with cognitive disabilities or using assistive technology—build a mental model of your interface and navigate confidently.

Table of Contents

• What WCAG 3.2.4 Requires
• Why This Matters
• Quick Implementation Guide
• Common Mistakes to Avoid
• How to Test for WCAG 3.2.4
• How TestParty Helps
• FAQs

What WCAG 3.2.4 Requires

WCAG 3.2.4 Consistent Identification mandates that components performing the same function must use consistent labels, names, and text alternatives throughout your site.

Key points:

• Same function = same identification: If a magnifying glass icon triggers search on every page, it needs the same accessible name everywhere (e.g., "Search" in the aria-label or button text).
• Applies to labels, alt text, ARIA names, and visible text: The requirement covers all forms of identification—visible button labels, alt attributes on icons, aria-label values, and programmatic names.
• Scoped to a "set of web pages": This typically means your entire website or web application, not just a single page.
• Visual consistency helps but isn't required: While using the same icon or styling aids usability, WCAG 3.2.4 focuses on functional identification—the accessible name and role.

What's exempt:

• Components that look similar but perform different functions can have different labels (e.g., a "Next" button in a carousel vs. a "Next" button in a multi-step form—context matters).
• Variations in wording are acceptable if the function differs (e.g., "Save Draft" vs. "Publish" are different actions).

Affected components:

• Navigation elements (menus, breadcrumbs, skip links)
• Form controls (submit buttons, search fields, filters)
• Icons and icon buttons (search, cart, user profile, close/dismiss)
• Links with the same destination or purpose
• Interactive widgets (accordions, modals, tooltips)

Why This Matters

Users with cognitive disabilities, learning disabilities, or limited working memory rely on predictable patterns to navigate websites. When a "shopping cart" icon is labeled "Cart" on one page, "Basket" on another, and "Your Items" on a third, users must relearn the interface on every page—creating confusion and cognitive load.

Screen reader users hear the accessible name of each element. Inconsistent naming forces them to guess whether "Find" and "Search" do the same thing, slowing navigation and eroding trust.

Legal and compliance context:

WCAG 3.2.4 is a Level AA requirement, making it mandatory for ADA Title II and Title III compliance, Section 508 conformance, EN 301 549 (European public sector procurement), and the European Accessibility Act. Inconsistent identification has been cited in accessibility lawsuits and can trigger complaints from users who rely on assistive technology.

Business benefits:

Consistent labeling reduces support tickets ("Where's the search box?"), improves task completion rates, and strengthens brand trust. It also simplifies maintenance—design systems with standardized component names are easier to scale and update.

Quick Implementation Guide

1. Audit your component library

Inventory all interactive components across your site. Document the function of each (e.g., "triggers site-wide search") and the labels currently in use.

2. Standardize accessible names

Choose one label per function and apply it everywhere. Use the same text for visible labels, aria-label, aria-labelledby, and alt attributes.

Example: Consistent search button

<!-- Good: Same accessible name on every page -->
<button aria-label="Search">
  <svg><!-- magnifying glass icon --></svg>
</button>

<!-- Also good: Visible text label -->
<button>Search</button>

<!-- Bad: Different labels for the same function -->
<!-- Page 1 -->
<button aria-label="Search">...</button>
<!-- Page 2 -->
<button aria-label="Find">...</button>
<!-- Page 3 -->
<button aria-label="Lookup">...</button>

3. Document naming conventions

Create a style guide or design system entry for each reusable component. Specify the exact accessible name, ARIA attributes, and any contextual variations.

4. Enforce consistency in templates and components

Use shared component libraries (React, Vue, Web Components) to centralize labels. Avoid hard-coding labels in individual page templates.

5. Test with assistive technology

Navigate your site with a screen reader (NVDA, JAWS, VoiceOver) and verify that identical functions announce the same name.

Relevant WCAG techniques:

• G197: Using labels, names, and text alternatives consistently for content that has the same functionality

Common Mistakes to Avoid

Using synonyms for the same function

Labeling a shopping cart icon as "Cart," "Basket," "Bag," and "Your Items" across different pages violates 3.2.4. Pick one term and stick with it.

Inconsistent icon alt text

An icon that opens a user profile menu might have alt="Profile" on the homepage but alt="Account" on a settings page. Screen reader users hear two different names for the same action.

Mixing visible and hidden labels

One page shows a visible "Search" label; another hides the text and uses aria-label="Find". Even if the icon looks the same, the accessible names differ.

Forgetting about ARIA attributes

Two buttons with the same visible text ("Submit") might have different aria-label values (aria-label="Submit form" vs. aria-label="Send message"). If they perform the same function, the ARIA labels must match.

How to Test for WCAG 3.2.4

Manual review (primary method):

• Navigate through multiple pages of your site.
• Identify components that appear to have the same function (e.g., all "close" buttons, all "add to cart" buttons).
• Use browser DevTools to inspect the accessible name (Accessibility panel in Chrome/Edge/Firefox).
• Verify that identical functions have identical accessible names.

Screen reader testing:

• Use NVDA (Windows), JAWS (Windows), or VoiceOver (macOS/iOS) to tab through interactive elements.
• Listen to how each component is announced. Identical functions should announce the same name.

Automated scanning (limited):

• Automated tools can flag potential inconsistencies by comparing accessible names across pages, but they struggle with context (e.g., distinguishing "Next" in a carousel from "Next" in a form).
• Tools like axe DevTools, WAVE, and Lighthouse can surface naming patterns but require human review to confirm whether functions are truly identical.

Checklist:

• [ ] All search buttons/fields use the same accessible name site-wide
• [ ] Navigation icons (home, menu, close) have consistent labels
• [ ] Form submit buttons with the same purpose use identical text
• [ ] Icons performing the same action (e.g., "Edit," "Delete") are labeled consistently
• [ ] Links to the same destination or performing the same action use the same link text or accessible name

How TestParty Helps

TestParty's AI-powered platform automates the detection of inconsistent identification across your site and integrates remediation directly into your development workflow.

What TestParty detects:

TestParty scans your entire site—crawling pages, analyzing the DOM, and extracting the accessible name (computed from visible text, aria-label, aria-labelledby, alt, and title attributes) for every interactive component. It then clusters components by function using semantic analysis and flags inconsistencies.

For example, TestParty identifies all buttons with a search icon or search-related functionality and compares their accessible names. If it finds "Search" on 47 pages but "Find" on 3 pages and "Lookup" on 1 page, it surfaces this as a WCAG 3.2.4 violation with a detailed report showing each variant and its location.

TestParty also detects:

• Icons with inconsistent alt text across pages
• Form labels that vary for the same input type (e.g., "Email" vs. "Email Address" for newsletter signups)
• Navigation elements (breadcrumbs, skip links) with differing accessible names
• ARIA attributes that introduce naming inconsistencies even when visible text matches

How TestParty suggests fixes:

Once inconsistencies are detected, TestParty generates AI-powered remediation suggestions. For a search button labeled inconsistently, TestParty might recommend:

<!-- Suggested fix: Standardize to "Search" -->
<button aria-label="Search">
  <svg><!-- icon --></svg>
</button>

TestParty analyzes usage frequency across your site and suggests the most common label as the standard, but developers review and approve the final choice. For template-based sites (Shopify, WordPress, React component libraries), TestParty generates diffs that update the shared component or template, cascading the fix across all instances.

TestParty also provides context-aware guidance: if two components look similar but perform different functions, it flags them for human review rather than auto-suggesting a merge.

Developer workflow integration:

TestParty integrates into CI/CD pipelines and pull request workflows, catching inconsistent identification before code reaches production. When a developer introduces a new button with a label that conflicts with an existing pattern, TestParty annotates the PR with a warning:

> ⚠️ WCAG 3.2.4 Violation: This button is labeled "Find" but 47 other search buttons use "Search." Consider updating to maintain consistency.

This shift-left approach prevents regressions and educates developers in real time. TestParty also integrates with IDEs, surfacing naming conventions from your design system as inline suggestions.

Ongoing monitoring:

TestParty continuously monitors your site for new pages, components, and updates. Its dashboard tracks consistency metrics over time, showing the percentage of components with standardized naming and flagging drift (e.g., a new landing page template that introduces a variant label).

Audit-ready reports document all instances of each component, their accessible names, and remediation history—critical for demonstrating compliance during legal reviews or procurement audits.

TestParty's embedded guidance explains why consistent identification matters, linking to WCAG documentation and real-world user impact stories. This helps teams build accessibility knowledge and make informed decisions when edge cases arise.

FAQs About WCAG 3.2.4

What is WCAG 3.2.4 in plain language?

WCAG 3.2.4 requires that if a button, link, icon, or other component does the same thing across multiple pages, it must have the same label or accessible name everywhere. This helps users—especially those with cognitive disabilities or using screen readers—recognize and predict how your interface works.

Is WCAG 3.2.4 required for ADA compliance?

Yes. WCAG 3.2.4 is a Level AA success criterion, and ADA Title II and Title III compliance generally require conformance to WCAG 2.1 or 2.2 Level AA. Inconsistent identification has been cited in accessibility lawsuits and can create barriers for users with disabilities.

Does WCAG 3.2.4 apply to mobile apps?

While WCAG is written for web content, the principle of consistent identification applies to mobile apps as well. EN 301 549 and Section 508 extend WCAG requirements to native apps, and platforms like iOS and Android emphasize consistent labeling in their accessibility guidelines.

Can I use different labels if the context is different?

Yes, if the function differs, the label can differ. For example, a "Next" button in an image carousel and a "Next" button in a checkout flow perform different actions, so they can have different accessible names (e.g., "Next image" vs. "Continue to payment"). The key is functional equivalence, not visual similarity.

How do I handle icons that serve multiple purposes?

If an icon performs different functions in different contexts (e.g., a "+" icon that adds items to a cart in one place and expands an accordion in another), it should have different accessible names that reflect each function ("Add to cart" vs. "Expand section"). WCAG 3.2.4 requires consistency for the same function, not the same visual appearance.

What if my site is multilingual?

Consistent identification applies within each language. The English version should use consistent English labels, the Spanish version consistent Spanish labels, and so on. Translations don't need to be literal matches across languages, but they should be consistent within each language.

Some TestParty features described in this article are currently under development. Visit TestParty.ai to learn more about our current capabilities and roadmap, or book a demo at TestParty.ai/book-a-demo to see TestParty in action.

Disclaimer: Some of this article was generated with Large Language Models (LLMs) and Artificial Intelligence (AI). There may be some errors and we advise you to consult with human professionals for detailed questions.