Accessible Navigation: Skip Links, Menus and Focus

When navigation fails, the entire visit fails. A user who cannot open the main menu by keyboard reaches no subpage. A screen reader user who cannot grasp the page structure loses orientation. WCAG therefore treats navigation not as a side topic but distributes the requirements across several success criteria: 2.4.1 Bypass Blocks for skipping blocks, 2.4.3 Focus Order for a meaningful order, 4.1.2 Name, Role, Value for the correct semantics of interactive elements and 2.4.7 Focus Visible for the visible focus indicator.

The scope shows in the statistics of the most common errors. Low text contrast affects 79.1 percent (WebAIM Million 2025) of all home pages, missing alternative text 55.5 percent (WebAIM Million 2025), with 44 percent of those cases involving linked images and thus completely breaking navigation for screen reader users (WebAIM Million 2025). The average home page contained around 1,173 (WebAIM Million 2024) DOM elements in 2024, an increase of 11.8 percent over the previous year (WebAIM Million 2024). As complexity grows, so does the need for mechanisms that allow users to navigate deliberately rather than tabbing linearly through hundreds of elements.

Since June 2025 the European Accessibility Act has been enforceable in the EU and requires, among other things, keyboard-operable websites and support for assistive technologies (Level Access). The governing standard EN 301 549 references WCAG as the minimum benchmark, in the current version Level AA (Acquia). Accessible navigation is therefore not only a matter of usability but a legal requirement whose foundations we describe in detail in our article on the BFSG requirements.

A skip link is the first focusable link on a page. It allows keyboard users to bypass header and navigation and jump directly to the main content. Without a skip link, a keyboard user must tab through all navigation links on every single page before reaching the actual content. With a navigation of 20 entries, that is 20 additional tab presses -- on every page, on every visit. WCAG criterion 2.4.1 Bypass Blocks (Level A) therefore requires a mechanism that makes recurring blocks skippable.

Technically, a skip link is an anchor pointing to the

On extensive pages, several skip links can be useful, for example to content, to search and to the main navigation. They are implemented as a compact list at the page beginning. The data is interesting: according to WebAIM, experienced screen reader users use skip links less often because they jump by headings and landmarks anyway (WebAIM Skip Navigation). For sighted keyboard users without these jump mechanisms, however, skip links remain an essential aid. Our accessible web development therefore implements skip links as a standard building block and complements them with a clean landmark structure.

Screen reader users rarely navigate linearly. According to the WebAIM Screen Reader User Survey, 71.6 percent (WebAIM Survey 2024) of respondents find information on long pages by first jumping through the headings. 88 percent (WebAIM Survey 2024) describe headings as very or somewhat useful. A correct heading hierarchy is therefore itself a navigation instrument: for many users it replaces the visual scanning of a page.

Landmarks complement headings. They structure the page into areas such as header, nav, main, aside and footer. Landmark usage shows a fluctuating course: from 43.8 percent frequent use in 2014 it fell to 25.6 percent by 2021 but rose again in the 2024 survey to 31.8 percent (WebAIM Survey 2024). As a primary method on long pages, only 3.7 percent of respondents rely on landmarks (WebAIM Survey 2024) -- headings and landmarks complement each other but do not replace one another.

If multiple nav elements are used, for example main and service navigation, each should be uniquely labelled with aria-label. This lets screen reader users distinguish between the areas instead of repeatedly encountering an unnamed navigation. How semantic structures are optimally built for screen readers is described in detail in our article on screen reader optimisation.

In practice it pays to treat navigation as a standalone component early in the project rather than fixing it afterwards. Those who plan the skip link, landmark structure and heading hierarchy from the start avoid expensive rework and create a foundation on which further building blocks such as search, breadcrumbs and footer navigation sit without contradiction. This structural clarity pays off not only in accessibility but also improves maintainability and comprehensibility for search engines, which evaluate the same semantic structure.

A common misconception concerns the ARIA role menu. It is not intended for classic website navigation but for application-like menus as in desktop programs, with their own keyboard logic of arrow keys and without tab stops between entries. The WebAIM Million Report 2025 shows the consequences of misuse: 4.5 percent (WebAIM Million 2025) of home pages used an ARIA menu with role="menu", and in 35 percent (WebAIM Million 2025) of these menus barriers arose because the necessary menu markup and interaction were missing.

For the vast majority of website navigations, the disclosure pattern is the more robust choice. A navigation consists of an unordered list of links within a nav element. Submenus are expanded and collapsed via a button with aria-expanded. This approach uses native semantics understood by all screen readers and requires significantly less custom keyboard logic.

An accessible dropdown in the disclosure pattern opens via Enter or Space, signals its state via aria-expanded and can be closed again via Escape. When the submenu closes, focus returns to the triggering button. These patterns are documented in the WAI-ARIA Authoring Practices and form the standard for accessible navigation components (W3C WAI-ARIA APG).

Users must be able to recognise where they are within the navigation. Visually this often happens through a highlight of the active menu item. For screen reader users, however, a purely visual marking is not enough. The attribute aria-current="page" marks the link to the current page programmatically, so the screen reader announces it as the current page.

aria-current has several values depending on context: page for the current page in a navigation, step in a multi-step process, location in a progress indicator and true as a general variant. The combination of visual highlight and programmatic marking ensures that the current position is recognisable for all user groups -- a principle closely related to the correct marking of states via ARIA roles and states.

Every function of the navigation must be reachable and operable via keyboard. This is required by WCAG 2.1.1 Keyboard (Level A). In practice this means: links are activated with Enter, buttons with Enter or Space, submenus open and close via the corresponding keys, and Escape closes an opened menu. During tab navigation, focus follows DOM order, which should correspond to the visual order.

In extensive navigation groups such as mega menus, the roving tabindex pattern can improve operation: only the active element receives tabindex="0", all others tabindex="-1", and arrow keys shift the active index. This reduces the number of tab stops. For most classic navigations, however, the simple disclosure pattern with individual tab stops per link is sufficient and easier to maintain. The complete keyboard patterns for menus, tabs and widgets are covered in our article on keyboard navigation in web development.

Focus is the cursor of keyboard users. It must be visible at all times so the user knows which element is currently active. WCAG 2.4.7 Focus Visible (Level AA) requires a visible focus indicator. The newer criterion 2.4.11 Focus Not Obscured (Level AA) from WCAG 2.2 adds that the focused element must not be fully obscured by other content such as sticky headers (W3C WCAG 2.2).

Many designs remove the default focus ring via outline: none because it is perceived as disruptive. This is only permissible when an equivalent or better replacement exists. The CSS pseudo-class :focus-visible resolves the conflict: it shows focus only on keyboard operation, not on mouse clicks. This keeps the design calm for mouse users while keyboard users receive a clear indication.

During dynamic navigation operations, such as expanding a mega menu or a route change in a single-page application, focus must be actively managed. When a submenu opens, focus should be placed there meaningfully; on closing, it returns to the trigger. In single-page applications, focus is set to the beginning of the new content after a page change so screen reader users notice the change.

On small screens, navigation is often hidden behind a menu button that opens an off-canvas panel. The familiar principles apply here too. The button carries aria-expanded reflecting its state, plus an accessible label such as aria-label="Menu" if it only shows an icon. When the panel opens, focus moves into the panel; when it closes, focus returns to the button.

An open off-canvas menu that overlays the rest of the page behaves similarly to a modal dialog: focus should remain within the menu, and Escape should close it. At the same time, the menu must not create a keyboard trap -- after closing, the user must be able to continue navigating normally. The detailed rules for such overlaying components are described in our article on accessible modals and overlays.

A frequently underestimated aspect is the consistency of navigation across all pages. Keyboard and screen reader users build a mental model of the page structure; if the order of menu items jumps from page to page or the behaviour of submenus changes, this orientation advantage is lost. Consistent, predictable navigation matches the WCAG principle of consistency (3.2.3 Consistent Navigation, Level AA) and reduces cognitive load for all user groups. In implementation this means maintaining the navigation as a central component rather than duplicating it per page.

Besides the main menu, there are further navigation patterns that must be made accessible. A breadcrumb navigation is typically wrapped in a nav element with aria-label="Breadcrumb", implemented as an ordered list, with the current entry marked with aria-current="page". This lets screen reader users recognise their position in the page hierarchy.

A search function should be equipped with a correctly labelled input field and an accessible button; the enclosing form element can be marked with role="search" so screen readers announce it as a search area. When paginating lists or search results, the page numbers are implemented as links, the current page is marked with aria-current="page" and the buttons for next and previous are uniquely labelled.

The most effective test of navigation is the manual keyboard test: put the mouse away and navigate exclusively with Tab, Shift+Tab, Enter, Space, Escape and arrow keys. This systematically checks whether the skip link works, whether every menu item is reachable, whether submenus are accessible, whether focus consistently remains visible and whether there are no keyboard traps.

In addition, a screen reader shows whether landmarks, headings and aria-current are announced correctly. Automated testing tools find basic problems such as missing labels or ARIA errors but do not replace the manual test, as they cannot judge focus flows and complex interactions. Which tools are suitable for which testing step is covered in our overview of accessibility testing tools. A professional WCAG audit combines automated checking, manual keyboard and screen reader tests into a robust evaluation.