Consistent Navigation and Consistent Identification: What WCAG SC 3.2.3 and 3.2.4 Require

A store runs an A/B test that reorders the header nav for half its traffic. A redesign ships the cart icon as a shopping bag on the homepage template and a shopping cart on the checkout template, with different aria-label text on each. A mobile nav drawer lists “Sale” before “New Arrivals”; the desktop header lists them the other way. None of this is visually broken — every page still works on its own. But a screen reader user who’s learned where things live on one page, or what a label means, loses that knowledge every time it changes for no reason they triggered.

Quick answer: WCAG SC 3.2.3 Consistent Navigation (Level AA) requires that navigation mechanisms repeated across a set of pages appear in the same relative order each time, unless the user themselves changes it. WCAG SC 3.2.4 Consistent Identification (Level AA) requires that components with the same function — including icon-only buttons — use the same accessible name everywhere that function repeats. Neither bans redesigns, personalization, or having different labels for different functions. Both fail when the same function gets a different order or a different name across pages, with no action from the user causing it.

This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA is a technical-practice standard, not a legal determination — consult qualified counsel for legal risk questions.

SC 3.2.3: order, not position

The normative text is narrow: “Navigational mechanisms that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.” The Understanding document’s own Intent section explains who this serves and why: screen magnifier users rely on “visual cues and page boundaries to quickly locate repeated content,” sighted users build “spatial memory,” and users who navigate sequentially with a screen reader “benefit from having navigational mechanisms occur in a consistent order relative to the overall source order and structure of the page.”

The doc is explicit about what this doesn’t forbid: “the use of the phrase ‘same order’ in this section is not meant to imply that sub-navigation menus cannot be used or that blocks of secondary navigation or page structure cannot be used.” Its own worked example is an expanding menu — seven top-level nav items, and selecting one inserts a sub-navigation list into the top-level menu without that being a violation. The criterion is about the relative order of the repeated pieces, not a frozen layout. And the exception is real — the doc’s own words: “Users may initiate a change in the order by using adaptive user agents or by setting preferences so that the information is presented in a way that is most useful to them.” A user re-arranging their own nav isn’t a failure. A server-side experiment silently reordering the same nav for the same user, with no action on their part, is different — the user-initiated exception doesn’t apply to a change the user never asked for.

SC 3.2.4: same function, same name

The companion criterion is about labels, not position: “Components that have the same functionality within a set of web pages are identified consistently.” The Understanding doc’s Intent section explains the mechanism plainly: screen reader users “rely heavily on their familiarity with functions that may appear on different web pages,” and inconsistent labels for the same function make a site “considerably more difficult to use,” adding cognitive load along the way. This extends past visible text to non-text content, in the doc’s own words: “If icons or other non-text items have the same functionality, then their text alternatives should be consistent as well.”

The doc’s own worked examples land almost exactly on e-commerce UI, including one that names the industry directly: “An e-commerce application uses a printer icon button that allows the user to print receipts and invoices. In one part of the application, the printer icon button is labeled ‘Print receipt’ and is used to print receipts, while in another part it is labeled ‘Print invoice’ and is used to print invoices. The labeling is consistent (‘Print x’), but the labels are different to reflect the different functions of the icons.” That example passes — because the underlying function differs (printing a receipt vs. an invoice), a different label is correct, not a violation. The named failure example is a closer match to a real bug: “A submit ‘search’ button on one web page and a ‘find’ button on another web page both have a field to enter a term and list topics in the website related to the term submitted. In this case, the buttons have the same functionality but are not labeled consistently.”

That distinction — same function needs the same name; different functions can validly have different names — is the entire criterion in practice. It’s easy to violate by accident on a templated site where the header component gets copy-edited on one template and not the others.

Where templated e-commerce sites actually break these

A/B tests and personalization that reorder navigation server-side. The most common SC 3.2.3 failure isn’t a redesign — it’s an experiment. A header nav showing “New Arrivals, Sale, Clearance” to one cohort and “Sale, New Arrivals, Clearance” to another, assigned server-side rather than by anything the visitor did, changes a repeated mechanism’s relative order with no user-initiated trigger. The criterion doesn’t object to personalization generally — it objects to a repeated mechanism’s order shifting for reasons the user had no part in.

Icon-only cart, wishlist, and account buttons with drifting aria-label text. A cart icon labeled aria-label="Cart" on category pages and aria-label="Shopping bag" on the checkout template is the same failure shape as the doc’s own search/find example, just moved to an icon. The glyph looking identical doesn’t help — SC 3.2.4 is about the accessible name, and a screen reader user encountering the second label has no way to know it’s the same control used a page ago. Quietramp’s wishlist button article covers getting a single toggle’s name right; this criterion is about that same name staying identical everywhere the toggle repeats, not just being correct on one page.

Mobile and desktop nav built as separately maintained components. A responsive site frequently ships two nav implementations — desktop header and mobile drawer — edited by different people at different times. Category order silently drifting between them over successive edits is the most common real-world way this gets violated, without anyone intending an inconsistency.

Support/help links that move. Quietramp’s Consistent Help article covers a related but narrower WCAG 2.2 criterion scoped specifically to help mechanisms (contact links, chat launchers, FAQ links). SC 3.2.3 is the broader rule: any repeated navigational mechanism, not just a help link, has to hold its relative position.

The fix

For SC 3.2.3, the sufficient technique is G61 — presenting repeated components in the same relative order each time they appear, in both visual layout and source order. In practice: build the header/footer nav as a single shared component referenced by every template rather than re-implemented per page, and if an experiment changes nav order, scope it to something the user actually opted into (a “customize your menu” control), not a silent server-side split.

For SC 3.2.4, the sufficient technique is G197 — using labels, names, and text alternatives consistently for content with the same functionality. Concretely: keep a single source of truth for icon-button aria-label strings — a shared component or a constants file — instead of letting each template author its own copy for what should be an identical control. If a design system already centralizes icon components, this is usually a small fix: make sure the accessible name is a prop passed from one canonical value, not hand-typed at each call site.

What a scanner can’t catch here

This pair of criteria is a clean example of why automated scanning alone misses real issues. axe-core and Lighthouse both evaluate one page at a time — neither has a concept of “the same component on a different page” to compare against, so a nav that reorders between two templates, or a cart icon with two different labels on two pages, produces zero automated findings on either page individually. Catching this takes someone actually clicking through a site’s templates and checking whether the same nav and the same icon labels hold up page to page — the same kind of manual, cross-page pass Quietramp’s screen-reader testing guide covers for other components.

FAQ

Does an A/B test automatically fail SC 3.2.3? Not automatically — it fails when a repeated navigational mechanism’s relative order changes for a given user with no action from them. A test on button color, hero copy, or product-grid layout doesn’t touch this criterion at all; a test that reorders the nav itself does.

Can a mobile menu list items in a different order than desktop? The Understanding document doesn’t carve out a breakpoint exception the way SC 3.2.6’s own Understanding doc does for help mechanisms. The safest reading is to keep the same relative order across breakpoints where the same items repeat, treating a reordering between mobile and desktop as a real risk rather than an assumed pass.

Do two icon buttons with the same icon but different functions need the same label? No — the Understanding document’s own printer-icon example confirms this: if the function is genuinely different (printing a receipt vs. an invoice), a different label reflecting that difference is correct, not a violation. The rule only bites when the function is the same and the label isn’t.

Get your site’s nav and labels checked across pages, not just one

Quietramp’s $890 audits include a manual pass across a site’s templates — checking whether the same nav holds its order and the same icon buttons keep the same accessible name from category pages through checkout, not just scanning each page in isolation. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.

---

This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA does not resolve ADA or any other legal compliance question, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.

This article was drafted with AI assistance and reviewed by a person for accuracy before publication.