WCAG 3.2.3 Consistent Navigation requires that navigation repeated across a set of pages — your header menu, footer links, sidebar, or search field — appears in the same relative order on every page where it shows up, unless the user changes that order themselves. It is a Level AA rule about predictability, not pixel-perfect placement.
What WCAG 3.2.3 means in plain language
The official W3C wording is precise: “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” (W3C, Understanding 3.2.3).
Two phrases carry the weight. “Relative order” means the sequence of the repeated links must stay stable — not that the menu lives at the same coordinates on every page. The W3C is explicit that “items are considered to be in the same relative order even if other items are inserted or removed from the original order.” So you may add a section-specific link or expand a sub-menu; you may not swap Home and About between pages. “Unless a change is initiated by the user” means a person can reorder things themselves — through a preference setting or an adaptive browser extension — without breaking the rule.
Note also the scope: 3.2.3 only governs navigation that is repeated on multiple pages. A one-off landing page has nothing to be inconsistent with. The rule lives under the Predictable guideline, part of the Understandable pillar of the POUR principles.
Who inconsistent navigation hurts
This is a cognitive-load criterion, and the people it protects are specific:
- Screen reader users (JAWS, NVDA, VoiceOver). Many users build muscle memory — “the cart is the fifth link in the banner.” When templates reorder the menu, that memory becomes a trap, and every page forces a fresh, slow re-exploration of the link list.
- Screen-magnifier users. At 400% zoom a person sees a small window of the screen. They learn that the menu sits top-right and pan straight to it. Move or reorder it per page and they hunt blindly each time. The W3C names low-vision and magnifier users as primary beneficiaries.
- People with cognitive, memory, or intellectual disabilities. Predictable layout is the whole point. Reshuffling navigation between pages multiplies the effort of an already taxing task.
For sighted, mouse-using visitors, a reordered menu is a minor annoyance. For these users it can be the difference between completing a checkout and giving up.
Concrete failures — and the fix
The named failure is F66: presenting navigation links in a different relative order on different pages (W3C, Understanding 3.2.3). Here is where small businesses actually trip it:
1. Mismatched templates between sections. The blog uses one header partial, the shop uses another, and the link order differs:
<!-- /about page header -->
<nav aria-label="Primary">
<a href="/">Home</a> · <a href="/shop">Shop</a> ·
<a href="/about">About</a> · <a href="/contact">Contact</a>
</nav>
<!-- /shop page header — Contact and About swapped: FAILS F66 -->
<nav aria-label="Primary">
<a href="/">Home</a> · <a href="/shop">Shop</a> ·
<a href="/contact">Contact</a> · <a href="/about">About</a>
</nav>
The fix: render one shared navigation component and include it everywhere. The order then can’t drift, because there is only one source:
<!-- nav.partial.html — included by EVERY template -->
<nav aria-label="Primary">
<a href="/">Home</a> · <a href="/shop">Shop</a> ·
<a href="/about">About</a> · <a href="/contact">Contact</a>
</nav>
2. CMS-injected links in a different sequence. WordPress, Shopify, and similar platforms often build menus from category or collection data. If one template sorts categories alphabetically and another by date, the repeated links land in a different order. Lock the menu to a single, manually ordered menu object rather than letting each page re-sort it.
3. A reordered footer. Footers count as repeated navigation. A “sitemap” footer that lists columns in one order on the homepage and another order on interior pages is a textbook F66.
4. The skip link drifting. The W3C lists a “skip navigation” link as the first link on every page as a model of consistency. If it appears first on some pages and third on others, you’ve undermined the very mechanism keyboard and screen reader users depend on. Keep it the first focusable element site-wide — which ties directly to keyboard navigation and focus visibility.
What does not fail 3.2.3: adding a section-specific sub-menu, expanding a dropdown, or inserting a single page-relevant link into an otherwise stable bar. Insertion and removal are explicitly allowed — only reordering the shared items is the violation. The sufficient technique is simply G61: presenting repeated components in the same relative order each time they appear.
How to test for consistent navigation
You cannot fully automate this one — scanners check a page in isolation, and 3.2.3 is about the relationship between pages. Test it like a person would:
- List your repeated navigation regions: primary header menu, utility nav, footer, any persistent sidebar, and the search field.
- Open three or four different page types — homepage, a product or service page, a blog post, the contact page — in separate tabs.
- Read the link order top to bottom in each repeated region and compare. The sequence of the shared links must match. Inserted or removed page-specific items are fine; reordered shared items are a fail.
- Tab through with the keyboard only. Confirm the focus order through the menu is identical on each page and that the skip link is consistently first.
- Check it with a screen reader’s links list (NVDA’s
Insert+F7, VoiceOver’s rotor). If the same links appear in a different sequence per page, that’s the violation a tester will document.
Because this is template-level, fixing one shared component usually fixes the whole site at once — which is why it’s a high-leverage item in any accessibility audit. Related predictability checks live across the full success-criteria index, and proper headings and landmarks make your consistent structure machine-discoverable.
Why this matters legally
Digital accessibility litigation is not slowing down. UsableNet’s tracking found more than 5,000 digital accessibility lawsuits filed in 2025, continuing a multi-year pattern of over 4,000 federal and state filings annually (UsableNet 2025 Year-End Report). Courts in private ADA Title III matters routinely treat WCAG 2.1 AA — the level 3.2.3 sits at — as the practical conformance benchmark, a point the W3C/WAI standards underpin.
Consistent navigation rarely headlines a demand letter the way missing alt text or failing color contrast does, because those are trivially caught by automated scans. But 3.2.3 surfaces in thorough manual audits and in the kind of remediation a settlement or VPAT requires — and it’s exactly the sort of inconsistency a serial-plaintiff tester notices when navigating your whole site by keyboard. It’s cheap to get right and awkward to explain after the fact.
This is general information, not legal advice. For your specific exposure, consult a qualified accessibility attorney.
Fixing it the right way
The durable fix is structural: one navigation component, included everywhere, with a single ordered source of truth. That is hands-on template work — not something an accessibility widget can do. Overlay scripts inject their own controls on top of your page; they cannot reconcile two templates that emit links in a different order, because the order is baked into your code before the overlay ever runs. (More on why overlays don’t work and how manual remediation compares.)
Curbcut is deliberately anti-overlay. Our [EXPERT_NAME] team consolidates your repeated navigation into shared partials, verifies the relative order with a keyboard and screen reader across page types, and documents conformance. If you’d like to see where your menus drift today, start with a free scan — or have us remediate it for you so every page stays predictable.