Navigation order is inconsistent across pages

What is this issue?

A set of navigation items (the same links, appearing as the same repeated component) occurs on more than one page of the site, but their order relative to each other differs between pages. On page one, “Pricing” might come before “Features”; on page two, the same two items appear with “Features” first.

This is a cross-page structural comparison, not a property any single page’s markup reveals on its own. A page can have perfectly valid, well-labeled navigation markup and still fail this rule, because the failure only exists in the relationship between how that navigation is ordered here versus how the same navigation is ordered somewhere else on the same site.

Why does this matter?

Repeated navigation is one of the first structures a user builds a mental map of, often without consciously trying to: after visiting two or three pages, most users know roughly where “Pricing” or “Contact” sits in the menu without having to search for it each time. That spatial memory is a genuine efficiency gain, and it depends entirely on the order staying stable.

When the order shifts between pages, that mental map becomes actively wrong instead of just unused: a user reaches for where an item used to be and finds something else there. For someone navigating by keyboard, counting Tab presses to a familiar item, or a screen reader user who’s learned “the fourth link in the nav is Pricing,” a reordered menu doesn’t just fail to help; it actively misleads.

Who is affected?

• Keyboard users: often learn a navigation menu’s Tab-press count to a frequently used item; a reordered menu breaks that shortcut and forces re-scanning the entire menu on the page where the order changed.
• Screen reader users: build a mental sequence of a repeated navigation region’s contents after encountering it once; a differently-ordered menu on a later page means the item they expect at a given position is no longer there.
• Cognitive disabilities: rely heavily on consistent, predictable page structure to reduce the mental effort of navigating a site; reordered navigation adds re-learning cost on every page where it changes, compounding across a session.
• Low vision: users relying on a magnified, zoomed-in view see only a portion of the page at a time and often navigate by scanning a familiar, memorized position rather than the whole visible menu; a shifted position defeats that shortcut entirely.

What users experience

Renata has ADHD and finds it easier to navigate unfamiliar sites when she can build a quick mental map of the main menu rather than re-reading it on every page. On a government services site, the top navigation reads “Apply, Status, Documents, Help” on the homepage. Two pages deep, into the section for renewing a permit, the same four items appear as “Documents, Apply, Help, Status”: visually identical links, silently reordered. She spends several extra seconds re-scanning a menu she thought she’d already memorized, breaking her flow through a multi-step application process she was trying to complete quickly.

How do I fix it?

Keep every navigation component that repeats across pages (the same set of links, rendered as the same recognizable menu) in the same relative order on every page it appears on. This works because it preserves the spatial memory users build after their first encounter with the menu, so later encounters require zero re-learning instead of a fresh scan.

The most reliable way to guarantee this in practice is to render the navigation from a single shared component or template, rather than hand-authoring it separately on each page or page type. A shared source of truth makes an accidental reorder structurally impossible, instead of relying on every content author to manually keep several independent copies in sync. If a genuinely new item needs adding, add it in the same position across every page at once, rather than inserting it piecemeal as pages happen to get updated.

Code Examples

<!-- Page A -->
<nav>
  <a href="/pricing">Pricing</a>
  <a href="/features">Features</a>
  <a href="/docs">Docs</a>
</nav>

<!-- Page B -->
<nav>
  <a href="/features">Features</a>
  <a href="/pricing">Pricing</a>
  <a href="/docs">Docs</a>
</nav>

<!-- Page A -->
<nav>
  <a href="/features">Features</a>
  <a href="/pricing">Pricing</a>
  <a href="/docs">Docs</a>
</nav>

<!-- Page B: same order, generated from one shared component -->
<nav>
  <a href="/features">Features</a>
  <a href="/pricing">Pricing</a>
  <a href="/docs">Docs</a>
</nav>

The fix isn’t a markup change to either page individually; both pages already had valid, working navigation HTML. The fix is making both pages render from the same ordered list, so “Features, Pricing, Docs” is the one and only order that can ever appear, on any page, because there’s only one place that order is defined.

Framework Examples

The most durable fix for this rule is structural: define the navigation’s item order once, in a single shared component or a layout wrapper every page renders through, rather than letting individual pages or templates each hand-author their own copy of the menu.

// Define the order once, in a shared config or component
const NAV_ITEMS = [
  { label: 'Features', href: '/features' },
  { label: 'Pricing', href: '/pricing' },
  { label: 'Docs', href: '/docs' },
];

function SiteNav() {
  return (
    <nav>
      {NAV_ITEMS.map((item) => (
        <a key={item.href} href={item.href}>{item.label}</a>
      ))}
    </nav>
  );
}

Every page that renders <SiteNav /> gets the exact same order automatically, because the order lives in one array instead of being re-typed by hand in every page’s own markup; the class of bug this rule documents becomes structurally impossible once navigation order has a single source of truth.

Common Mistakes

Mistake: “Each page’s navigation order was set intentionally to highlight what’s most relevant to that page.” Prioritizing different content per page is a reasonable design goal, but reordering a repeated, identically-labeled menu is the wrong tool for it; it breaks the predictability the menu exists to provide. Use a page-specific “you are here” highlight, a separate contextual sidebar, or a distinct in-page callout instead of reordering the shared navigation itself.

Mistake: “This only matters for large navigation menus with many items.” Even a three- or four-item menu builds spatial memory after one or two page visits, and reordering even that small a set produces the same re-scan cost. The size of the menu affects how bad the problem gets, not whether the problem exists at all.

Mistake: “As long as all the same links are present somewhere on every page, the order doesn’t matter.” Presence and order are two different requirements this criterion covers together: having “Pricing” on every page satisfies one half of Consistent Navigation, but reordering it relative to its siblings each time still fails the other half, since the whole benefit depends on relative position staying stable, not just item presence.

How RedFlag Detects This

Guidance only: RedFlag documents this issue but does not currently flag it; verify manually. RedFlag’s own coverage model records this criterion’s evidence as docs_only: comparing navigation structure across multiple pages of a site is not implemented in any of RedFlag’s automated scanning, custom DOM detectors, or manual-check workflows today.

This is a structurally harder check to automate than most rules in this project, because it requires crawling and comparing multiple pages against each other, rather than evaluating a single page in isolation; RedFlag’s scan model, like most single-page accessibility scanners, evaluates one page at a time. There is currently no false-positive or false-negative profile to describe, because there is no automated detection happening at all. Manual step: use the Manual Testing steps below across at least two to three pages that share the same navigation component.

Manual Testing

1. Open two or three pages from different sections of the same site, each of which shares a common navigation component (header menu, footer, or sidebar).
2. Read the order of items in that navigation on the first page, either visually or with a screen reader’s landmark or links-list navigation.
3. Repeat on the second and third pages, comparing the same menu’s item order against what you recorded first.
4. Confirm the relative order of every shared item stays identical across all pages checked: the same items in the same sequence, not necessarily every page having an identical full menu.
5. Flag any page where a repeated navigation component’s item order differs from the others.

Related WCAG Success Criteria

3.2.3 Consistent Navigation: Navigational mechanisms that repeat across multiple pages within a set of pages must occur in the same relative order each time they’re repeated. This rule maps directly to 3.2.3, documenting the specific failure of that criterion: a repeated navigation component whose relative item order shifts between pages.

Related Issues

Help mechanism location is inconsistent across pages is this rule’s closest sibling: the same cross-page consistency principle applied to a help or support mechanism instead of a full navigation menu.

Form field has more than one label is unrelated in mechanism but worth checking on the same audit pass, since navigation and form-structure consistency issues often surface together on sites undergoing redesign.

Page is missing a language declaration commonly gets audited alongside cross-page consistency checks like this one, since both require reviewing more than a single isolated page to assess properly.

HTML lang attribute is not a valid language code shares this rule’s need for a multi-page review pattern during a full site audit, even though the underlying mechanism is unrelated.

References

• W3C Understanding 3.2.3: Consistent Navigation
• W3C Technique G61: Presenting repeated components in the same relative order each time they appear