WCAG 3.2.3: Consistent Navigation
Users learn where things are. The search box top right, the skip link first, Home before Products before Pricing. This criterion protects that learning: navigation repeated across pages must keep the same relative order on every page. Items can be added or dropped — but the ones that repeat must never be shuffled, unless the user reorders them.
The success criterion, in full
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.
Three scoping notes. It applies to repeated mechanisms (headers, footers, sidebars, search, skip links) within a set of pages — a single standalone page conforms automatically. It demands the same relative order, not identical menus. And user-initiated changes are explicitly allowed.
Why consistency matters
Predictability is an accessibility feature. A screen magnifier user at high zoom sees perhaps a tenth of the page at once; after a few pages they stop scanning and go straight to where the search box was last time. A screen reader user learns that the fourth link in the header is Pricing and jumps there by count. A user with a cognitive disability builds a routine: skip link, menu, content. Every one of these strategies depends on the page behaving the same way each time.
When a template reshuffles between sections — search moves from header to sidebar, the footer link order changes, the menu is alphabetized on some pages and by popularity on others — those users pay the full cost of learning the layout again on every page. For someone who reads slowly, navigates by memory, or fatigues quickly, that cost can make the site effectively unusable.
Consistent order also compounds with other criteria: a skip link that is always first (2.4.1 Bypass Blocks), a logical focus order (2.4.3 Focus Order), and consistent naming (3.2.4 Consistent Identification) together make a site feel learnable instead of hostile.
What “same relative order” means
The phrase is precise: relative order, not identical content. Repeated items must keep their sequence with respect to each other; the set of items may vary between pages.
Allowed between pages
- Adding items: a section inserts local sub-navigation.
- Removing items: pages omit links that do not apply to them.
- Expanding or collapsing: the current section’s sub-menu is open, others closed.
- User-initiated changes: the user pins, sorts, or customizes the navigation.
Not allowed between pages
- Reordering repeated links: Home–Products–Pricing on one page, Pricing–Home–Products on another.
- Relocating repeated mechanisms in the reading order: search before the menu here, after it there.
- Different sort logic per template: alphabetical menu on blog pages, popularity-sorted elsewhere.
- Skip link first on some pages, buried mid-header on others.
Order here means DOM and reading order, not just visual layout. A responsive design may present the same list as a horizontal bar on desktop and a hamburger drawer on mobile without failing — provided the sequence of the repeated items, as encountered by keyboard and screen reader, stays the same.
Pass and fail examples
Shared layout component on every page(passes)
A site renders header, navigation, and footer from one layout template, so every page presents skip link, logo, menu, and search in the same sequence. Passes.
Section adds a local sub-menu(passes)
The Docs section shows an extra sidebar of doc pages that other sections lack. The repeated global navigation keeps its order; the addition is fine. Passes.
User pins favorite items to the top(passes)
A dashboard lets each user pin their most-used sections to the top of the navigation. The change is initiated by the user, so the exception applies. Passes.
Search moves between templates(fails)
On the homepage the search field is the last element in the header; on article pages it precedes the menu in the reading order. A repeated mechanism changes relative position. Fails.
Footer links shuffled per page(fails)
The footer lists About, Careers, Privacy, Terms — but each template hard-codes its own copy in a different order. Repeated links reordered between pages. Fails.
Code examples
Per-page markup vs. one shared layout
The most reliable technique is structural: render repeated navigation from a single shared template or component, so it cannot drift between pages.
<!-- ✗ Each page hand-codes its own header — order drifts -->
<!-- home.html -->
<header>
<nav><a href="/">Home</a> <a href="/pricing">Pricing</a>
<a href="/products">Products</a></nav>
</header>
<!-- about.html -->
<header>
<nav><a href="/products">Products</a> <a href="/">Home</a>
<a href="/pricing">Pricing</a></nav>
</header>
<!-- ✓ One layout component renders navigation everywhere -->
// app/layout.tsx (Next.js)
export default function RootLayout({ children }) {
return (
<html lang="en">
<body>
<a href="#main" className="skip-link">Skip to content</a>
<SiteHeader /> {/* same order on every page */}
<main id="main">{children}</main>
<SiteFooter /> {/* same order on every page */}
</body>
</html>
)
}Navigation data as a single source of truth
Drive menus and footers from one ordered data structure. Pages may filter items out, but never re-sort them — filtering preserves relative order; sorting destroys it.
// nav-items.ts — one canonical order for the whole site
export const NAV_ITEMS = [
{ href: "/", label: "Home" },
{ href: "/products", label: "Products" },
{ href: "/docs", label: "Docs" },
{ href: "/pricing", label: "Pricing" },
{ href: "/admin", label: "Admin", requires: "admin" },
]
// ✓ Filtering keeps relative order — Admin simply disappears
const visible = NAV_ITEMS.filter(
(item) => !item.requires || user.roles.includes(item.requires)
)
// ✗ Re-sorting per page breaks 3.2.3
const broken = [...NAV_ITEMS].sort((a, b) =>
pageViews[b.href] - pageViews[a.href] // "popular first" on some pages
)User-initiated reordering is allowed
Offering the user an explicit control that reorders navigation is fine — the exception in the normative text covers exactly this.
<!-- ✓ The user chooses the order; the site persists their choice -->
<nav aria-label="Your workspaces">
<label for="nav-sort">Sort workspaces</label>
<select id="nav-sort" name="nav-sort">
<option value="default">Default order</option>
<option value="alpha">Alphabetical</option>
<option value="recent">Recently used</option>
</select>
<ul id="workspace-list">…</ul>
</nav>Common failures
- Hand-coded headers or footers per template that list the same links in different orders on different pages.
- Auto-sorting repeated navigation differently per context — alphabetical here, most-popular there — without the user asking for it.
- Moving a repeated mechanism to a different position in the reading order between templates: search before the menu on one page, after it on another.
- A skip link that is the first focusable element on most pages but missing or placed mid-header on others.
- Redesigning one section's navigation in isolation, so half the site uses the new order and half the old.
- DOM order that contradicts visual order on some templates only — CSS keeps things looking consistent while keyboard and screen reader order silently changes.
How to test for 3.2.3
- 1
List the repeated navigational mechanisms
Identify everything that recurs across pages: skip links, header menu, search, breadcrumbs, sidebar navigation, footer link groups, 'back to top' controls.
- 2
Sample pages from every template
Pick pages built from each distinct template or layout — homepage, listing pages, detail pages, blog, docs, account area. Inconsistencies live between templates, not within one.
- 3
Compare the order of repeated items
For each mechanism, note the sequence of its items on each sampled page and compare. Added or removed items are fine; any change in the relative order of the repeated items is a failure.
- 4
Verify the reading order, not just the pixels
Tab through each sampled page and, with a screen reader, walk the header and footer. The keyboard/announcement order is what must be consistent — CSS can make different DOM orders look identical.
- 5
Attribute any differences
Where order does differ, check whether the user initiated it via an explicit preference or control. If the site changed it unilaterally, 3.2.3 fails.
Like the other Predictable criteria, this is a cross-page, manual comparison that automated single-page scanners cannot perform. Fold it into your template review and the full WCAG 2.2 checklist.
Frequently asked questions
What does WCAG 3.2.3 Consistent Navigation require?
It requires that navigational mechanisms 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. In plain terms: if your header menu, footer links, sidebar, search box, and skip link appear on many pages, they must appear in the same order on all of them. It is a Level AA success criterion under Guideline 3.2 Predictable, introduced in WCAG 2.0 and unchanged in 2.1 and 2.2.
What does 'same relative order' actually mean?
Relative order is about sequence, not identity. Items may be added or removed between pages — a 'Admin' item that only appears for admins, or a sub-menu that expands in the current section — as long as the items that do repeat stay in the same order relative to each other. If the menu is Home, Products, Pricing, Contact on one page, it must not become Products, Home, Contact, Pricing on another. Inserting 'Docs' between Products and Pricing on some pages is fine.
Who benefits from consistent navigation?
Users with cognitive limitations, low vision, and blindness benefit most. People who rely on spatial memory or muscle memory — including screen magnifier users who only see a small part of the page — learn where controls live and go there without re-scanning. Screen reader users build a mental model of the page structure and use shortcuts based on it. People with cognitive disabilities avoid the heavy cost of re-learning each page's layout. When navigation reshuffles between pages, all of that learned efficiency is destroyed.
Can I add or remove menu items on some pages without failing 3.2.3?
Yes. The criterion governs the order of repeated items, not their presence. A page may omit items that are irrelevant to it, and a section may add local sub-navigation. What fails is reordering: the repeated items must keep the same sequence relative to one another everywhere they appear. Note that how those items are named is a separate criterion — 3.2.4 Consistent Identification requires components with the same function to be labelled consistently.
What does 'unless a change is initiated by the user' mean?
If the user themselves reorders the navigation — choosing a different sort order, pinning favorite items to the top, switching to a compact layout, or otherwise customizing via a mechanism the site provides — that is not a failure. The criterion targets changes the site makes unilaterally between pages. A preference the user set and can unset keeps the experience predictable, because the change was their own choice.
How is 3.2.3 different from 3.2.4 Consistent Identification?
They are sibling criteria under Guideline 3.2 Predictable, both Level AA, and they cover different dimensions of consistency. 3.2.3 is about position and order: repeated navigational mechanisms keep the same relative order across pages. 3.2.4 is about naming: components with the same functionality are identified the same way (same labels, same icons, same alt text) across pages. A menu that keeps its order but renames 'Search' to 'Find' on half the pages passes 3.2.3 and fails 3.2.4 — and vice versa.
Related Success Criteria
When a component receives focus, it does not initiate a change of context.
Changing settings of a component does not automatically cause context changes.
Components with the same functionality are identified consistently.
Changes of context are initiated only by user request.
Help mechanisms appear in the same relative order across pages.