F31: When 'Search' and 'Find' Are the Same Button

For most users, the difference between a button labeled "Search" and one labeled "Find" is invisible. They click, results appear, done. For users who navigate by landmark, who build mental maps of interfaces, who rely on consistent language to orient themselves across pages — that inconsistency is a wall. Same function, different label, different cognitive experience.

This is WCAG 2.1 Failure F31 (opens in new window). It's one of the quieter failures in the catalog, which is part of why it persists.

The Failure

F31 describes a specific violation of Success Criterion 3.2.4: Consistent Identification (opens in new window). The rule: components that perform the same function across a set of web pages must be identified consistently.

The W3C's own examples are deliberately mundane — and that's the point:

Example 1 — A search button labeled differently across pages:

<!-- Page A -->
<button type="submit">Search</button>
<!-- Page B — same function, different label -->
<button type="submit">Find</button>

Example 2 — A save action with inconsistent labeling:

<!-- Page A -->
<button type="submit">Save page</button>
<!-- Page B — same function, shorter label -->
<button type="submit">Save</button>

These aren't edge cases. They're the kind of inconsistencies that accumulate naturally over time — different developers, different sprints, different designers making local decisions without a shared vocabulary. The result is an interface that quietly undermines predictability for the users who need it most.

One clarification the W3C makes explicitly: "consistent" doesn't mean "identical." A navigation arrow labeled "Go to page 4" on page 4 and "Go to page 5" on page 5 is consistent — the pattern holds even though the text changes. What F31 targets is arbitrary inconsistency, not contextual variation.

Why This Matters

SC 3.2.4 is a Level AA requirement. That means it's not optional for most organizations operating under Title II (opens in new window) or Title III of the ADA, or subject to Section 508.

The users most affected by F31 failures:

• Screen reader users who build spatial and linguistic maps of interfaces. When the same function has two names, they may not recognize it as the same function — leading to redundant searching or missed functionality.
• Users with cognitive disabilities who rely on consistent language as a navigation anchor. Predictability isn't a preference; it's an access requirement.
• Users with low vision using zoom or magnification who see only portions of a page at a time. Consistent labels reduce cognitive load when context is already constrained.
• Returning users of any disability type who have learned an interface. Label drift breaks learned patterns without warning.

The harm here is subtle but cumulative. No single inconsistency is catastrophic. But across a multi-page application — a government portal, an e-commerce checkout, an educational platform — inconsistent labeling erodes trust and usability in ways that disproportionately affect disabled users.

The Fix

The corrected pattern is straightforward:

<!-- Page A -->
<button type="submit">Search</button>
<!-- Page B — same function, same label -->
<button type="submit">Search</button>

For icon-based controls, the fix lives in the accessible name:

<!-- Inconsistent: -->
<button aria-label="Search">[icon]</button>  !-- Page A -->
<button aria-label="Find content">[icon]</button>  !-- Page B -->
<!-- Consistent: -->
<button aria-label="Search">[icon]</button>  !-- Page A -->
<button aria-label="Search">[icon]</button>  !-- Page B -->

The mechanism — visible text, aria-label, aria-labelledby, alt text — doesn't matter as long as the accessible name is consistent across pages for the same function.

Applying This

F31 failures are almost entirely invisible to automated testing tools. A tool can flag a missing label; it cannot know that "Search" on page A and "Find" on page B represent the same function. This is precisely the gap our research paper Beyond Detection: Why Context Separates Automated Testing from Manual Audits documents — automated tools capture at most 37% of real accessibility failures, and cross-page consistency issues fall squarely in the manual-only category.

Practical catches for development teams:

In design systems: Establish a component vocabulary. If a function exists in your design system, it has one name. "Search" is search everywhere. Document it. Enforce it in design reviews.

In code review: When reviewing a component that appears on multiple pages, ask: what is this called elsewhere? A simple grep for button text or aria-label values across templates can surface inconsistencies before they ship.

In content audits: F31 often hides in CMS-driven content where different editors have named the same widget differently. A cross-page label audit — even a manual spreadsheet — catches this.

In QA: Add a cross-page consistency check to your accessibility test protocol. For each repeated functional component (search, save, submit, navigation), verify the accessible name matches across every page it appears.

For teams managing large-scale applications, the Compliance Framework Paradox research is worth reading — it documents how organizational fragmentation (multiple teams, multiple standards, no shared vocabulary) is precisely the environment where F31 failures breed.

CORS Perspective

Through an Operational Capacity lens, F31 is a design system governance problem more than a code problem. Organizations that have invested in a shared component library and a controlled vocabulary — where "Search" is defined once and used everywhere — are structurally protected against this failure. Organizations without that infrastructure are structurally exposed, because individual developers and content editors will make local naming decisions in the absence of centralized guidance. The fix isn't a single code change; it's a process change: establish the vocabulary, document it, and build it into review workflows. That's sustainable. Chasing label inconsistencies page by page, sprint by sprint, is not.