Accessible navigation patterns

Why navigation is a structural accessibility issue

Accessibility can end up treated as a finishing step: check contrast, add alt text, fix what an automated tool flags. Navigation does not fit that pattern. Whether menus stay in the same place, whether there is more than one route to a page and whether help is easy to find are decisions made when the structure is planned. Getting them right then costs little; changing them after launch means reworking templates.

The WCAG 2.2 criteria that shape navigation

WCAG 2.2 became a W3C Recommendation on 5 October 2023. Several of its success criteria bear directly on navigation.

3.2.3 Consistent Navigation (level AA). "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." In practice, the main menu, search box and footer links keep their order across templates. People who use screen magnifiers, who see only part of the page at a time, depend on this.

2.4.5 Multiple Ways (level AA). "More than one way is available to locate a web page within a set of web pages except where the web page is the result of, or a step in, a process." W3C lists techniques including related links, a table of contents, a site map, search and links to all pages from the home page. Menus plus search, or menus plus a site map, satisfy it.

3.2.6 Consistent Help (level A, new in 2.2). If pages offer help such as "human contact details", a contact mechanism, a self-help option or an automated contact mechanism, and these are repeated across pages, they appear in the same order relative to other page content. A contact link that sits in the header on some templates and the footer on others fails this.

2.4.1 Bypass Blocks (level A). A mechanism to skip repeated content, such as a "skip to main content" link as the first focusable item.

2.5.8 Target Size Minimum (level AA, new in 2.2). Targets such as menu links need enough size or spacing to be activated reliably.

2.4.11 Focus Not Obscured Minimum (level AA, new in 2.2). A focused item must not be entirely hidden, for example behind a sticky header or an open menu.

Dropdown menus: use disclosure, not the menu role

ARIA includes menu and menubar roles, and it is tempting to use them for website navigation. The W3C ARIA Authoring Practices Guide recommends against this for ordinary sites. Its disclosure navigation example "does not use the WAI-ARIA menu role", explaining that ordinary site navigation does not need the full set of menu and menubar keyboard interactions. The menu role tells screen readers to expect application-style behaviour, with arrow keys moving between items, which is not what a list of website links needs.

The disclosure pattern is simpler:

• Each top-level item that opens a dropdown is a <button> with aria-expanded set to true or false.
• The dropdown is a plain list of links, shown or hidden by the button.
• Tab and Shift+Tab move through buttons and links in order.
• Enter or Space on a button toggles its dropdown.
• Escape closes an open dropdown and returns focus to its button.
• Arrow keys and Home/End are optional extras.

If a top-level item is both a link to a section page and a dropdown, the APG's hybrid example pairs a link with a separate button. Do not make a single element do both jobs.

Mobile menus

The same disclosure logic applies to a "Menu" button on small screens. The button should say what it does, expose its state with aria-expanded, and move logically into the opened menu. Keep the mobile and desktop menus to the same set of links; a mobile menu that leaves out sections breaks the consistency people rely on.

Skip links and landmarks

Put a "Skip to main content" link first in the page, visible when focused. Wrap the main menu in a <nav> element with a label such as "Main", and wrap other navigation blocks in their own labelled <nav> elements: "Breadcrumb", "Footer", "In this section". Screen reader users can then jump between landmarks instead of tabbing through every link.

Labels and link text

Accessible navigation depends on the words as much as the code. Menu labels should be specific and distinct, because a screen reader user may hear them as a list without the surrounding layout. Avoid two items that start with the same word, such as "Services for business" and "Services for residents", which are hard to tell apart when heard in a list. Link text inside content should describe the destination on its own.

Showing where people are

Mark the current page in the menu with aria-current="page" and a visible style that does not rely on colour alone. Breadcrumbs, covered in the breadcrumbs guide, give a second signal of location.

The Australian legal context

The Disability Discrimination Act 1992 makes it unlawful to discriminate on the basis of disability in providing goods, services and facilities. The Australian Human Rights Commission's Guidelines on equal access to digital goods and services, published in April 2025, are intended to "assist organisations to meet their obligations under the Disability Discrimination Act" when they provide digital goods and services. They point to WCAG as the relevant standard and advise meeting the latest published version. Commonwealth agencies must also meet the Digital Service Standard, whose criterion "Leave no one behind" calls for compliance with the latest version of WCAG. We are not lawyers; if you need a view on your legal obligations, ask one.

Search as a second route

Site search is one of the techniques W3C lists for Multiple Ways, and it matters to people who find menus hard to use. Make the search box reachable from every page in the same place, give it a visible label, and make sure results pages have clear headings and link text. A search that returns three versions of the same document is a structure problem, not a search problem; the taxonomy guide explains how labels and duplicates affect results.

A quick self-check

1. Unplug your mouse and reach every menu item with the keyboard.
2. Check that the first Tab press shows a skip link.
3. Open and close each dropdown with Enter and Escape.
4. Compare the order of header and footer links across three different templates.
5. Zoom to 400 per cent and check the menu still works without horizontal scrolling.
6. Confirm the contact link sits in the same place on every page.

The internal linking checklist covers related navigation checks. For a full plan, see navigation design.

Sources checked 4 November 2026 for accessible navigation patterns

1. Consistent Help (3.2.6), W3C
2. Digital access guidelines, AHRC
3. Digital Service Standard, DTA
4. WCAG 2.2 changes, W3C
5. Multiple Ways (2.4.5), W3C
6. Consistent Navigation (3.2.3), W3C
7. Disclosure menu, W3C