Navigational mechanisms repeated across a set of pages must occur in the same relative order each time, unless the user initiates a change (WCAG 2.2 SC 3.2.3, Level AA).
3.2.3 Consistent Navigation
In Plain Language
WCAG 2.2 SC 3.2.3 Consistent Navigation (Level AA) requires that any navigational mechanism repeated across a set of pages -- header nav, breadcrumb, sidebar, footer link list, utility nav -- occur in the same relative order every time it is rendered[1]. Inserting or removing items between existing ones is allowed; what is not allowed is reshuffling the items that are shared across pages.
The exception is a change the user initiates: if the user sorts, filters, or personalises the nav, the reordered state is their chosen state and does not fail the criterion. A server-side rule that promotes the current page to the first slot, or reorders the menu by popularity between page loads, is not user-initiated and does fail.
Why It Matters
- Screen-reader users build a mental map of nav order across pages. When the items arrive in a different sequence on the next page, that map is invalidated and the user has to re-read the entire list to re-locate a target link -- every page transition pays the cost.
- Users with cognitive and learning disabilities rely on positional consistency to reduce working-memory load. Moving a link from the third slot to the fifth slot between pages forces re-learning the layout on each visit, which is exactly the barrier SC 3.2.3 exists to prevent[1].
- Low-vision users running screen magnification only see a slice of the viewport at a time -- often one or two nav items. A stable order lets them pan to the expected coordinates instead of scanning the whole menu to find a moved link.
- Keyboard users Tabbing through nav build muscle memory for "four Tabs to Contact." Reordering the DOM breaks that count and sends focus to the wrong destination.
- Order-of-items is the rule; visual presentation can still vary by breakpoint. A hamburger on mobile and a horizontal bar on desktop is fine as long as the items appear in the same source order in both layouts.
Examples
Home page:
Products page:
✔ Same four links in the same order on both pages
<!-- Home page -->
<nav aria-label="Main">
<a href="/" aria-current="page">Home</a>
<a href="/products">Products</a>
<a href="/about">About</a>
<a href="/contact">Contact</a>
</nav>
<!-- Products page -- same order -->
<nav aria-label="Main">
<a href="/">Home</a>
<a href="/products" aria-current="page">Products</a>
<a href="/about">About</a>
<a href="/contact">Contact</a>
</nav>Home page:
Products page:
✘ Links are reordered -- About and Contact have swapped, and Home moved
<!-- Home page -->
<nav>Home | Products | About | Contact</nav>
<!-- Products page -- FAILS: order changed -->
<nav>Products | Home | Contact | About</nav>
<!-- "About" moved from 3rd to 4th, "Contact" from 4th to 3rd -->Before redesign:
After redesign:
✔ Blog was added between Products and About -- existing items kept their relative order
<!-- Before: Home, Products, About, Contact -->
<nav aria-label="Main">
<a href="/">Home</a>
<a href="/products">Products</a>
<a href="/about">About</a>
<a href="/contact">Contact</a>
</nav>
<!-- After: Blog added -- existing order preserved -->
<nav aria-label="Main">
<a href="/">Home</a>
<a href="/products">Products</a>
<a href="/blog">Blog</a>
<a href="/about">About</a>
<a href="/contact">Contact</a>
</nav>On the About page:
On the Contact page:
✘ Current page is always moved to position 1 -- the order is different on every page
<!-- FAILS: current page is always first -->
<!-- About page -->
<nav>About | Home | Products | Contact</nav>
<!-- Contact page -->
<nav>Contact | Home | Products | About</nav>
<!-- Order changes on every page visit -->How to Fix It
- Render shared nav from a shared template or component. Main nav, breadcrumb, sidebar, footer link list, and utility nav should each come from a single include, layout partial, or component -- never hand-coded per page. A single source of truth is the structural fix; per-page markup is the root cause of drift.
- Sort children by a stable key. When the template iterates a list of nav items, order them alphabetically, by a fixed priority field, or by a logical sequence that does not change between requests. Do not sort by recency, popularity, A/B bucket, or current page -- those keys change, and the order changes with them.
- Mark the current page without moving it. Use
aria-current="page"plus visual styling (weight, underline, background) to indicate the active item. Keep it in its original slot. - When you add a new section, insert without shuffling. Place the new link at a logical position and leave every pre-existing link in its prior relative order. Inserting between items is allowed by SC 3.2.3; reordering them is not[1].
- Hold sub-navigation to the same rule. A section sidebar (e.g. "Products" sub-pages) is itself a repeated navigational mechanism across the pages in that section and must also render in a consistent order.
- Verify across layouts, not just pages. If the mobile layout is hand-maintained separately from the desktop layout, the two can drift. Drive both breakpoints from the same source list and let CSS handle presentation.
- Audit by diffing rendered nav source. Load two or more pages, extract the serialized nav markup, and compare. Any shared link whose position relative to the other shared links has changed is a failure.
References
- [1] W3C (2023). Understanding Success Criterion 3.2.3: Consistent Navigation. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/consistent-navigation.html ↩ ↩ ↩