Accessible navigation: so that everyone can find their way

Accessible navigation determines whether a visitor finds what they are looking for on your website – or gets stuck at the very first menu and leaves. After all, for many people, navigation is the only way to access your content: for blind people who use a keyboard to navigate through the menus, as well as for users with motor or cognitive impairments. In this guide, I’ll draw on practical audit experience to show you which WCAG criteria apply, how to design menus, drop-downs, the hamburger menu and breadcrumb trails to be accessible, and which simple test will immediately reveal whether your navigation is suitable for screen readers.

What is accessible navigation?

Accessible navigation refers to the totality of all menus, links and pathways through which every user can access your content. It must work with all input methods – mouse, keyboard, touch and voice control. And it must be understandable to assistive technology.

Technically, it all starts with the correct HTML element. A navigation area should be placed within a <nav>element, and the menu items should be listed within a list. This way, a screen reader recognises the area as navigation and even announces how many items the menu contains.

It is important to look beyond mere aesthetics. A menu that looks good when navigated with a mouse may be completely unusable when accessed via a keyboard. It is precisely this gap between appearance and usability that determines whether navigation is accessible or not. That is why we never test navigation using just a mouse, but always use a keyboard and a screen reader as well.

Who depends on clear navigation

Clear navigation benefits far more people than just screen reader users. This is because each method of input has its own specific requirements. Those who use only the keyboard need accessible menu items and a visible focus. And those who cannot control a mouse precisely need targets that are large enough.

The cognitive aspect matters too. People with concentration or memory difficulties rely on consistent patterns and a search function that is easy to find. For them, predictable navigation is the difference between succeeding and giving up.

On top of that, there is a clear business rationale. Anyone who cannot find their way to your content will leave – before they’ve even seen what you have to offer. Accessible navigation therefore reduces the bounce rate for all users. It is precisely this interaction that we test in an Access Ready audit using real users.

Several ways to reach your goal: it’s not just about the menu

A good website offers more than one way to access each page. This is precisely what Success Criterion 2.4.5 ‘Multiple Paths’ (Level AA) requires: there must be at least two different methods of accessing each page. Typical examples include a menu, a search function, a sitemap and breadcrumbs.

The key factor here is variety. Two identical menus in the header and footer are often counted as a single route because they follow the same approach. Genuine alternatives offer different ways of accessing content – such as browsing by category as opposed to a targeted search.

There is one exception. Pages that form a single step in a process – such as a checkout page or an application form – do not require this multi-path approach. For all other content pages, however, the following applies: if you offer only one route, you exclude those who find that single route difficult to follow. And you miss out on potential reach, because different people search in different ways.

Consistency: the same everywhere

Nothing confuses users more than navigation that changes from page to page. That is why Success Criterion 3.2.3, ‘Consistent Navigation’ (Level AA), requires that recurring navigation elements always appear in the same order. This means that the menu remains in the same place throughout the site.

Added to this is the use of consistent terminology. According to criterion 3.2.4, ‘Consistent Identification’ (Level AA), elements with the same function must be named the same everywhere. So do not call a link ‘Contact’ on one page and ‘Contact us’ on the next.

The benefits are endless. Consistent patterns form a reliable mental model that makes it easier to find your way around. People with cognitive impairments benefit from this in particular, as they do not have to find their bearings anew on every page. And sighted people, too, can find what they already know more quickly.

Mark the navigation as a landmark

Screen reader users navigate through a page not only by skipping to headings, but also by skipping to landmarks. The navigation area is one such landmark. To be useful, every navigation area needs a unique name specified via the aria-labelattribute.

The reason becomes clear when the feature is used repeatedly. If a page has several navigation areas – main navigation, footer navigation and breadcrumb navigation – they would otherwise all appear in the landmarks list simply as ‘Navigation’. A blind person would then be unable to tell them apart. With labels such as ‘Main navigation’ or ‘Footer’, however, the list becomes immediately usable.

There is one rule you should bear in mind. The name should describe the content of the navigation, not its position. And don’t go overboard with the number of sections, as too many landmarks will make the list confusing again. I explore how landmarks and headings work together in more detail in the guide to heading structure. Together, they form the map that helps a blind person navigate your site.

Skip links: skip navigation

Otherwise, keyboard users would have to tab through the entire navigation on every page before reaching the content. This is precisely what a skip link prevents. Success criterion 2.4.1 ‘Skipping blocks’ (Level A) requires such a mechanism for skipping recurring blocks.

Implementation is very straightforward. A ‘Skip to main content’ link is the first focusable element on the page. It only becomes visible when the user navigates to it using the keyboard; otherwise, it remains hidden. Clicking on it then takes the user directly to the main content.

The benefits are considerable and the effort required is minimal. This is because the jump link helps not only blind people, but everyone who navigates using a keyboard. It can be implemented in just a few lines of code and should feature on every page with extensive navigation.

Implementing drop-down menus correctly

Drop-down menus are the most common stumbling block in navigation. This is because many only respond to the mouse hovering over them – and that is precisely what does not work when using a keyboard or a touchscreen. You should therefore never rely solely on a hover effect for a sub-menu. After all, for many users, anything that cannot be clicked or tapped simply does not exist.

The so-called ‘disclosure’ pattern has proven its worth. In this pattern, each sub-menu is opened by a genuine <button> element, which announces the states via aria-expanded="false" and aria-expanded="true" and refers back to the menu via aria-controls. This pattern is supported more reliably by screen readers than the complex ARIA menu bar pattern and is the better choice for website navigation.

Three rules round this off. The sub-menu must be able to be closed using the Escape key; focus must then return to the button that triggered it; and the menu must not open automatically simply because the focus hovers over it. Furthermore, Criterion 1.4.13 ‘Content on Hover or Focus’ (Level AA) requires that expandable content be closable, scrollable and persistent. I go into more detail about the keyboard controls involved in the guide to keyboard navigation.

Mega menus without any pitfalls

Mega menus display many links in several columns at once. This is powerful, but prone to errors. This is precisely where keyboard traps often occur, causing the focus to get stuck and breaching criterion 2.1.2 ‘No keyboard traps’.

The typical problems are well known. The menu opens automatically when you hover over it, the focus ends up on invisible elements, or the numerous items are impossible to take in without a clear structure. You should therefore organise the columns using clear headings and control the focus deliberately.

On small screens, the mega menu reaches its limits. Alternatives work better here: an accordion-style drop-down menu, a tabbed structure or a full-screen overlay with enough space for navigation. It is important that keyboard navigation remains equally reliable across all screen sizes. If in doubt, a simple, easy-to-use menu is better than an impressive one that nobody can navigate using the keyboard.

The Hamburg menu on your smartphone

On a smartphone, the navigation menu is usually accessed via the hamburger icon. However, this icon alone has no meaning for a screen reader. The trigger must therefore be a genuine <button>element with a clear name – such as the visible text ‘Menu’ or a aria-label element – whilst the icon is hidden using aria-hidden="true".

The state must be audible. The button uses aria-expandedto indicate whether the menu is open or closed, and aria-controls refers to the menu area. If the menu opens as an overlay, the focus moves into it and remains there until the Escape key closes it again and returns the focus.

Two guidelines from WCAG 2.2 are important here. Control elements should be at least 24 by 24 pixels in size (2.5.8 Minimum Target Size), or better still 44 pixels for comfortable tapping. And the menu must remain usable even at high zoom levels (1.4.10 Reflow). Find out more in the guide to mobile accessibility. After all, for many people, navigation on a smartphone is their very first point of contact with your website.

Breadcrumbs: show where you are

Breadcrumbs tell the user where they are within the website. They show the path from the home page to the current page, thereby supporting success criterion 2.4.8: Position (Level AAA). They are particularly helpful on deeply nested pages.

The technical implementation is clearly defined. Enclose the breadcrumbs in a <nav aria-label="Brotkrümel"> tag using an ordered list. The current page appears as the last entry and is marked with aria-current="page"; use aria-hidden="true" to hide the separators.

This creates a clear, audible path. A screen reader user hears the individual steps and, by the end, knows which page they are currently on. The key thing is to provide breadcrumbs on all similar pages – consistency is key here too. This gives users a reliable sense of where they are at any given moment.

The search as a second option

Search is often the second most important way to access your content. After all, anyone who struggles with nested menus would rather enter a keyword. A good search function therefore fulfils a large part of the requirement set out in criterion 2.4.5, ‘Multiple Paths’.

Two things make it accessible. The input field needs proper labelling, and the search area should be marked up as role="search" so that a screen reader can recognise it as a landmark. Both can be implemented with minimal effort.

Don’t hide the search function. An ambiguous magnifying glass icon without a label prevents many users from finding it in the first place. A visible, clearly labelled search function is a real boon, particularly for people with cognitive impairments. Many older users, too, prefer to use the search function rather than navigate through a convoluted menu.

Footer and sidebar navigation

In addition to the main navigation, other sections often help users find their way around. These, too, require clear guidelines. Footer navigation, for example, should avoid using drop-downs, as sub-menus that open there tend to be more of a hindrance than a help.

A sidebar follows its own guidelines. Where there are many subpages, it can group deeper levels into accordions to prevent the list from becoming endless. Ideally, the sidebar should be positioned on the right and, in the source code, after the content, so that a jump link leads directly to the main heading.

There is one principle that applies across all sections. Each additional navigation section requires its own distinctive aria-label and must be used consistently throughout the website. This ensures that users can find their way around, rather than getting lost in a maze of extra menus.

Mark the current page

Users want to know where they are in the menu. You should therefore highlight the current page in the menu using the aria-current="page" attribute. This way, the screen reader will announce that this is the page currently open.

It is important to use dual labelling. The technical marking alone is not sufficient; it must also have a visible counterpart. Highlight the active item visually, not just by colour, but also, for example, by font weight or a marker.

The effect is noticeable. A clearly marked current location provides guidance and reduces the feeling of being lost. This makes the navigation seem reliable, rather than leaving the user in the dark. I explain more about colour-independent labelling in the guide to colours and contrasts.

Link texts that speak for themselves

A menu is only as good as the text of its links. This is because link text must be understandable even when taken out of context. This is precisely what Success Criterion 2.4.4 ‘Link Purpose in Context’ (Level A) requires.

The reason lies in the way screen readers work. Many users call up a list of all the links on a page, similar to the list of landmarks. If that list contains ‘more’ or ‘here’ five times, it is useless because none of the entries reveals where each link leads.

You should therefore make your link text descriptive. Instead of ‘more’, use ‘more about our services’; instead of ‘click here’, use ‘open the contact form’. This way, every user knows from the link text alone what to expect – whether in the menu or in the body text.

The test: open the list of landmarks

You can carry out the most revealing test of your navigation skills yourself in just one minute.

In practice – the landmarks list: Open your page with a screen reader and access the list of landmarks or sections – in NVDA via the element list, and in VoiceOver via the Rotor. What do you see there? Do your navigation areas appear as clearly labelled entries such as ‘Main Navigation’, ‘Footer’ and ‘Breadcrumbs’? Or do you simply see ‘Navigation’ listed three or four times in a row? In the latter case, the list is of no use to a blind person, as they cannot distinguish between the different areas. The solution costs one line per section: a meaningful aria-label on every <nav>. Then tab through each menu once and check whether every drop-down can be opened, closed and exited using the Escape key. These two simple steps will reveal most navigation barriers.

Common mistakes when navigating

The same patterns recur time and again across many audits. These are the eight I see most frequently – and they can all be rectified:

• Unlabelled hamburgers: an icon button that the screen reader does not name.
• Hover drop-downs that do not work when using the keyboard or touchscreen.
• No skip link to skip the navigation.
• The order or labelling varies from page to page
• Just one way to reach your destination, with no search function or sitemap.
• Targets that are too small and almost impossible to hit on the touchscreen.
• Unnamed nav areas, all of which have the same name in the list of landmarks.
• The current page is not clearly marked.

One thing stands out here. Almost no errors arise from malicious intent. Rather, they arise because the navigation has only been tested using a mouse and the eyes – and neither of these detects these problems. A quick test using a keyboard and a screen reader uncovers almost all of them.

Frequently asked questions about accessible navigation

To round off, here are the questions I come across most frequently in my practice.

Is a menu the only way to access the content?

No. Criterion 2.4.5 requires at least two different methods, such as a menu and a search function. An exception applies only to pages within a single process.

Can the hamburger menu consist of just one icon?

No. A symbol on its own is meaningless to a screen reader. Give the button a name using visible text or aria-label and hide the icon.

Are hover-only drop-downs permitted?

Practically not. This is because you cannot hover over elements using the keyboard or on the touchscreen. Use the disclosure pattern with a real button and aria-expanded.

How to make your navigation accessible

The process begins with measurable shortcomings and ends with the actual user experience. The free Access Score provides a quick overview in a matter of minutes. It automatically identifies what can be measured: a missing jump link, unnamed navigation sections or targets that are too small.

However, it is only when the menus are actually used that it becomes clear whether they are truly accessible. Can every drop-down menu be opened using the keyboard? Can a blind person find their way around using the landmarks? Is the navigation the same on every page? A scanner alone cannot assess this. With Access Ready, we test your navigation with real users of assistive technology and issue a legally compliant certificate.

The difference lies in our approach. Others check whether a menu is present in the code and leave the rest up to you. We check whether a person can actually achieve their goal using any method of input. This turns ‘the menu is there, after all’ into a guaranteed ‘everyone can find their way’. And a page that can only be navigated with a mouse becomes one that serves as a gateway to the content for everyone.

Want to know what digital accessibility means for your organisation? In 30 minutes, we will go through your requirements and the most sensible next steps with you.