3.2.3 Consistent Navigation
- Level AA
- Understandable
- Since WCAG 2.0
Summary
People who use screen readers, screen magnifiers, or who have memory and attention difficulties navigate by position as much as by reading. A screen magnifier user who knows the search field sits at the top right of every page pans straight there; a screen reader user who knows "Contact" is the last item in the header menu tabs to it without listening to the whole list. When a site reshuffles its navigation between pages, that learned map breaks and every page becomes a fresh orientation exercise. This criterion, at Level AA since WCAG 2.0, protects that learned map.
The auditor's mental model: for any navigational mechanism repeated across a set of web pages (header menus, footers, sidebars, breadcrumb trails, search fields, skip links), the items must appear in the same relative order on every page where the mechanism recurs. Relative order is the key word: items may be added or removed between pages, and other content may be inserted between them, but the surviving items must not swap places. A change the user initiates themselves (a "customise menu" feature, a pinned-favourites reorder) is explicitly exempt. The criterion only applies to a set of web pages sharing a common purpose and created by the same author or organisation; a single standalone page cannot fail it.
Official wording
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.
EN 301 549 mapping
- Web pages
- Clause 9.3.2.3
- Software and native apps
- No software requirement: the corresponding chapter 11 clause is void in the standard.
Clause 9.3.2.3 applies this criterion to web pages unchanged. For software the standard declares the corresponding clause void, so native apps carry no mandatory equivalent: the requirement is written for sets of web pages, and equivalent sets of software programs are extremely rare.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Test by comparing templates, not by staring at one page. Pick a representative page for each template the site uses: the home page, a standard content page, a listing or search results page, a checkout or form step, an account or dashboard page, and an error page if you can reach one. For each repeated navigational mechanism, record the order of its items on the first page, then check that order against every other template.
Work through each mechanism separately: the header menu (including any dropdown items that repeat), the footer link columns, any sidebar navigation, the breadcrumb trail's position relative to the other mechanisms, the search field, and the skip link. Keyboard testing doubles as an order check: tab through the header on two templates and note whether the focus order through the repeated items matches. In browser developer tools, comparing the DOM order of the nav landmarks on two templates catches cases where CSS visually reorders items on one page only, which affects some users' reading order even when the pixels look similar.
Apply the relative-order rule precisely. A checkout page that drops "Blog" and "Careers" from the header passes, because removal is allowed. A checkout page that keeps the same items but moves "Basket" from last to first fails, because surviving items swapped places. Compare like with like: judge the mobile layout against other pages in the mobile layout and desktop against desktop, since a hamburger menu ordering its items differently from the desktop bar is a comparison across presentations, not across pages. The common failure spots are checkout and funnel pages built on a separate template, logged-in areas bolted on later with a rearranged header, and legacy sections of large sites that never adopted the current navigation order.
iOS
The European standard declares this criterion void for software: it is written for sets of web pages, and equivalent sets of software programs are extremely rare, so a native iOS app cannot fail it under that standard. Record it as not applicable for native screens. Web content rendered inside the app that belongs to a set of web pages is still web content, and you grade that under the Web procedure above.
As guidance, the underlying need matters just as much in an app, so auditors typically still review it and report issues as best-practice recommendations rather than conformance failures. Check that the tab bar keeps the same items in the same order on every screen where it appears, that navigation bar buttons sit in consistent positions (back on the left, primary action on the right) across screens, and that any repeated toolbar or segmented control keeps its order. VoiceOver users who swipe through the tab bar, and Switch Control users stepping through items sequentially, memorise these positions; an app that shuffles them imposes exactly the cost this criterion exists to prevent, even though no WCAG failure is recorded.
Android
The position is the same as iOS: the European standard declares this criterion void for software because it targets sets of web pages, and equivalent sets of software programs are extremely rare. Native Android screens are graded not applicable. WebView content that forms part of a set of web pages is graded as web content under the Web procedure.
As guidance, still review consistency of repeated navigation and report findings as recommendations. Check that the bottom navigation bar keeps its item order on every screen that shows it, that the navigation drawer lists its entries in a stable order however it is opened, and that repeated app bar actions and overflow menu items keep their placement across screens. TalkBack users navigating by swipe order, and keyboard or D-pad users on larger devices, rely on these positions in the same way web users rely on a stable header, so a reshuffled drawer or bottom bar is worth flagging even without a conformance impact.
Pass and fail examples
Passes:
- A header menu reading Home, Products, Pricing, Contact on every template of the site, even though the checkout template drops Products and Pricing: items were removed, and the survivors kept their relative order.
- A documentation site that inserts a version picker between the logo and the search field on docs pages only: a new item was added, and the repeated items around it did not swap places.
- A dashboard whose sidebar order changes after the user drags entries into a custom order in settings: the change was initiated by the user, so it is exempt.
- A footer with four link columns in the same order site-wide, while individual columns gain or lose links per section.
Fails:
- A site whose header reads Home, About, Services, Contact on most pages, but Services, Home, Contact, About on the blog template: the same items appear in a different relative order.
- A checkout flow that moves the search field from the header into the footer while the rest of the site keeps it in the header: a repeated mechanism relocated relative to the others without user initiation.
- A skip link that is the first focusable element on most pages but placed after the full header menu on the account pages: the repeated navigational mechanism occurs in a different relative order in the focus sequence.
- A footer whose legal links appear as Privacy, Terms, Cookies on marketing pages and Cookies, Privacy, Terms on support pages.
Not a fail under this criterion:
- The same menu item labelled "Contact" on one page and "Get in touch" on another, in the same position: inconsistent naming of the same function belongs to SC 3.2.4 Consistent Identification, not here.
- A help link present on some pages and absent on others, or moved relative to other help mechanisms: placement of help mechanisms specifically is graded under SC 3.2.6 Consistent Help.
- A site that offers only one route to reach its pages: how many ways exist to find a page is SC 2.4.5 Multiple Ways; this criterion only asks that repeated mechanisms keep their order.
- Content within a single page reading in a confusing sequence: within-page order is SC 1.3.2 Meaningful Sequence; this criterion compares across pages.
- A native app whose tab bar order changes between screens: report it as a best-practice recommendation, since the European standard declares the criterion void for software.
Commonly confused with
- Consistent Identification, SC 3.2.4. The two are constant companions and constantly swapped. 3.2.3 is about order: the same repeated mechanisms in the same relative sequence. 3.2.4 is about identity: the same function carrying the same name and icon wherever it appears. A menu whose items swap positions files here; a search button labelled "Search" on one page and "Find" on another files under 3.2.4.
- Consistent Help, SC 3.2.6. Added in WCAG 2.2 at Level A, this is effectively a targeted subset: it requires help mechanisms (contact details, chat, help links) to keep the same relative placement across a set of pages. File help-placement findings there; file everything else that reshuffles under 3.2.3.
- Multiple Ways, SC 2.4.5. Both sit in an audit's navigation review, but 2.4.5 asks whether more than one way exists to locate a page (menu, search, sitemap), while 3.2.3 asks whether the ways that repeat stay in a stable order. A site can offer five ways to find a page and still fail 3.2.3 by shuffling them.
- Within-page reading order, SC 1.3.2 Meaningful Sequence. 1.3.2 grades the sequence of content inside one page; 3.2.3 grades the sequence of repeated mechanisms across pages. A confusing DOM order on a single page is not a consistent-navigation finding.
How AUDITSU tests this
Consistency criteria cannot be graded one screen at a time, so AUDITSU's audit walkthrough handles this one across the set. As you review each page, the walkthrough prompts you to record the repeated navigational mechanisms and their item order; on subsequent pages it asks you to confirm the order against what you have already captured, so a reshuffled header or relocated search field surfaces as soon as the second template is reviewed. Each check records a pass, fail, or not applicable result per screen with evidence attached, and a fail cites the two pages whose orders diverge.
For native app audits, the walkthrough reflects the European standard's position that the criterion is void for software: native screens are recorded as not applicable, while tab bar, drawer, and toolbar consistency is captured as best-practice guidance in the report rather than as a conformance failure. Web content inside the app is graded against the criterion as normal.
For the full guided workflow, see the audit platform.