Same menu order on every page and the ADA

Navigation that people can learn once

If the main menu on one page reads Services, Departments, Contact and on the next page reads Departments, Contact, Services, every visit starts with a search. WCAG 2.1 success criterion 3.2.3 (Level AA) says that navigational mechanisms repeated on multiple pages within a set of pages must occur in the same relative order each time, unless the user changes it.

"Relative order" is the key phrase. The mechanism may gain items, sub-menus may expand and secondary navigation may appear on deeper pages. What must stay stable is the order of the items that are repeated. Users can also change the order themselves through adaptive technology or preferences, and that is not a violation.

Who benefits

• Screen reader users who learn that "Pay a bill" is the third link and tab straight there.
• People with low vision who find items by position under magnification.
• People with cognitive disabilities who rely on a predictable layout and on repetition.

The ADA angle: city sites that grew in pieces

Municipal websites are often stitched together from a main site, a permit system, a library catalog and a utility portal, each built by a different team. The header menu is similar but not the same, and the order of items drifts. A resident moving from the city homepage to the "Pay a bill" portal sees a different menu in a different order, and a screen reader user has to relearn the page. WCAG applies within a "set of web pages", and a single agency's services usually count as one set. Where a third-party portal is part of the service you provide, see vendors and third-party content.

Web code: menus, footers, search, sub-navigation

Main menu copied into each template

<!-- home.html -->
<nav><a href="/services">Services</a><a href="/departments">Departments</a><a href="/contact">Contact</a></nav>

<!-- permits.html -->
<nav><a href="/departments">Departments</a><a href="/contact">Contact</a><a href="/services">Services</a></nav>

<!-- layout.html, included by every template -->
<header>{% include "main-nav.html" %}</header>

<!-- main-nav.html -->
<nav aria-label="Main">
  <a href="/services">Services</a>
  <a href="/departments">Departments</a>
  <a href="/contact">Contact</a>
</nav>

Footer links sorted per page in the CMS

footerLinks: ["Privacy", "Accessibility", "Sitemap"]   // page A
footerLinks: ["Sitemap", "Privacy", "Accessibility"]   // page B

// site-config.json, one source for all pages
{ "footerLinks": ["Privacy", "Accessibility", "Sitemap"] }

Sub-navigation that keeps the parent order

<!-- on /departments/parks -->
<nav>
  <a href="/departments/parks/events">Events</a>
  <a href="/contact">Contact</a>
  <a href="/services">Services</a>
</nav>

<!-- on /departments/parks -->
<nav>
  <a href="/services">Services</a>
  <a href="/departments">Departments</a>
  <ul>
    <li><a href="/departments/parks/events">Events</a></li>
  </ul>
  <a href="/contact">Contact</a>
</nav>

Mobile code: tab bars

// SwiftUI: tab order depends on which screen builds it
TabView {
  if isHome { HomeView().tabItem { Label("Home", systemImage: "house") } }
  ReportsView().tabItem { Label("Reports", systemImage: "doc") }
  if !isHome { HomeView().tabItem { Label("Home", systemImage: "house") } }
}

// SwiftUI: one source of order (tab.view and tab.label are app-defined helpers on AppTab)
enum AppTab: CaseIterable { case home, reports, account }

TabView {
  ForEach(AppTab.allCases, id: \.self) { tab in
    tab.view.tabItem { tab.label }
  }
}

// Jetpack Compose: items built separately per screen
NavigationBar {
  if (onHome) NavigationBarItem(...Home...)
  NavigationBarItem(...Reports...)
  if (!onHome) NavigationBarItem(...Home...)
}

// Jetpack Compose
val destinations = listOf(Home, Reports, Account)   // defined once

NavigationBar {
  destinations.forEach { d ->
    NavigationBarItem(
      selected = current == d,
      onClick = { navigate(d) },
      icon = { Icon(d.icon, contentDescription = null) },
      label = { Text(d.label) }
    )
  }
}

Testing it

1. Choose a sample of pages from different templates: home, a service page, a form, a search result, an error page.
2. On each, list the items in each repeated mechanism (header menu, footer, search, language chooser, breadcrumbs) in DOM order and in visual order.
3. Compare the lists. Items that appear on every page must keep the same relative order. Extra items appearing do not fail it.
4. Include subsites and portals that are part of the same service.
5. Tools: a crawler can extract link lists from the nav element on many pages and diff them. Whether the pages form one "set" is a judgment call.

What goes wrong

• Menu items sorted by "most visited" on each page.
• Right-to-left or mobile layouts that reverse the order for one page and not another.
• Different order for the same links in the header on the homepage and on the transaction pages.
• Chat or accessibility widgets that appear first on some pages and last on others.

Ship it when

• One shared source builds each repeated navigation block.
• Items on a deeper page insert into the same order, never reshuffle.
• Related subsites follow the same menu order.

Sources

• Understanding SC 3.2.3: Consistent Navigation (W3C), opens in a new tab
• 28 CFR Part 35, Subpart H: Accessibility of Web Information and Services (eCFR), opens in a new tab

Standard version: WCAG 2.1 (W3C Recommendation, 5 June 2018), as named in the Title II web rule. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official ADA statute and regulations, and ask a lawyer how they apply to you.