Accessible navigation determines whether a visitor finds what they are looking for on your website \u2013 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\u2019ll 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. <\/p>\n\n
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 \u2013 mouse, keyboard, touch and voice control. And it must be understandable to assistive technology. <\/p>\n\n
Technically, it all starts with the correct HTML element. A navigation area should be placed within a 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. <\/p>\n\n 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. <\/p>\n\n 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. <\/p>\n\n On top of that, there is a clear business rationale. Anyone who cannot find their way to your content will leave \u2013 before they\u2019ve 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<\/a> audit using real users. <\/p>\n\n A good website offers more than one way to access each page. This is precisely what Success Criterion 2.4.5 \u2018Multiple Paths\u2019 (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. <\/p>\n\n 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 \u2013 such as browsing by category as opposed to a targeted search. <\/p>\n\n There is one exception. Pages that form a single step in a process \u2013 such as a checkout page or an application form \u2013 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. <\/p>\n\n Nothing confuses users more than navigation that changes from page to page. That is why Success Criterion 3.2.3, \u2018Consistent Navigation\u2019 (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. <\/p>\n\n Added to this is the use of consistent terminology. According to criterion 3.2.4, \u2018Consistent Identification\u2019 (Level AA), elements with the same function must be named the same everywhere. So do not call a link \u2018Contact\u2019 on one page and \u2018Contact us\u2019 on the next. <\/p>\n\n 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. <\/p>\n\n 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 The reason becomes clear when the feature is used repeatedly. If a page has several navigation areas \u2013 main navigation, footer navigation and breadcrumb navigation \u2013 they would otherwise all appear in the landmarks list simply as \u2018Navigation\u2019. A blind person would then be unable to tell them apart. With labels such as \u2018Main navigation\u2019 or \u2018Footer\u2019, however, the list becomes immediately usable. <\/p>\n\n There is one rule you should bear in mind. The name should describe the content of the navigation, not its position. And don\u2019t 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<\/a>. Together, they form the map that helps a blind person navigate your site. <\/p>\n\n 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 \u2018Skipping blocks\u2019 (Level A) requires such a mechanism for skipping recurring blocks. <\/p>\n\n Implementation is very straightforward. A \u2018Skip to main content\u2019 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. <\/p>\n\n 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. <\/p>\n\n Drop-down menus are the most common stumbling block in navigation. This is because many only respond to the mouse hovering over them \u2013 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. <\/p>\n\n The so-called \u2018disclosure\u2019 pattern has proven its worth. In this pattern, each sub-menu is opened by a genuine 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 \u2018Content on Hover or Focus\u2019 (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<\/a>. <\/p>\n\n 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 \u2018No keyboard traps\u2019. <\/p>\n\n 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. <\/p>\n\n 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. <\/p>\n\n 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 The state must be audible. The button uses 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<\/a>. After all, for many people, navigation on a smartphone is their very first point of contact with your website. <\/p>\n\n 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. <\/p>\n\n The technical implementation is clearly defined. Enclose the breadcrumbs in a 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 \u2013 consistency is key here too. This gives users a reliable sense of where they are at any given moment. <\/p>\n\n 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, \u2018Multiple Paths\u2019. <\/p>\n\n Two things make it accessible. The input field needs proper labelling, and the search area should be marked up as Don\u2019t 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. <\/p>\n\n 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. <\/p>\n\n 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. <\/p>\n\n There is one principle that applies across all sections. Each additional navigation section requires its own distinctive Users want to know where they are in the menu. You should therefore highlight the current page in the menu using the 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. <\/p>\n\n 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<\/a>. <\/p>\n\n 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 \u2018Link Purpose in Context\u2019 (Level A) requires. <\/p>\n\n 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 \u2018more\u2019 or \u2018here\u2019 five times, it is useless because none of the entries reveals where each link leads. <\/p>\n\n You should therefore make your link text descriptive. Instead of \u2018more\u2019, use \u2018more about our services\u2019; instead of \u2018click here\u2019, use \u2018open the contact form\u2019. This way, every user knows from the link text alone what to expect \u2013 whether in the menu or in the body text. <\/p>\n\n You can carry out the most revealing test of your navigation skills yourself in just one minute.<\/p>\n\n In practice \u2013 the landmarks list:<\/strong> Open your page with a screen reader and access the list of landmarks or sections \u2013 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 \u2018Main Navigation\u2019, \u2018Footer\u2019 and \u2018Breadcrumbs\u2019? Or do you simply see \u2018Navigation\u2019 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 The same patterns recur time and again across many audits. These are the eight I see most frequently \u2013 and they can all be rectified: <\/p>\n\n 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 \u2013 and neither of these detects these problems. A quick test using a keyboard and a screen reader uncovers almost all of them. <\/p>\n\n To round off, here are the questions I come across most frequently in my practice.<\/p>\n\n 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. <\/p>\n\n No. A symbol on its own is meaningless to a screen reader. Give the button a name using visible text or 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 The process begins with measurable shortcomings and ends with the actual user experience. The free Access Score<\/a> 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. <\/p>\n\n 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<\/a>, we test your navigation with real users of assistive technology and issue a legally compliant certificate. <\/p>\n\n 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 \u2018the menu is there, after all\u2019 into a guaranteed \u2018everyone can find their way\u2019. And a page that can only be navigated with a mouse becomes one that serves as a gateway to the content for everyone. <\/p>\n\n\n\n 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.<\/strong><\/p>\n\n\n\n<nav><\/code>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. <\/p>\n\nWho depends on clear navigation<\/h3>\n\n
Several ways to reach your goal: it\u2019s not just about the menu<\/h3>\n\n
Consistency: the same everywhere<\/h3>\n\n
Mark the navigation as a landmark<\/h3>\n\n
aria-label<\/code>attribute. <\/p>\n\nSkip links: skip navigation<\/h3>\n\n
Implementing drop-down menus correctly<\/h3>\n\n
<button><\/code> element, which announces the states via aria-expanded=\"false\"<\/code> and aria-expanded=\"true\"<\/code> and refers back to the menu via aria-controls<\/code>. This pattern is supported more reliably by screen readers than the complex ARIA menu bar pattern and is the better choice for website navigation. <\/p>\n\nMega menus without any pitfalls<\/h3>\n\n
The Hamburg menu on your smartphone<\/h3>\n\n
<button><\/code>element with a clear name \u2013 such as the visible text \u2018Menu\u2019 or a aria-label<\/code> element \u2013 whilst the icon is hidden using aria-hidden=\"true\"<\/code>. <\/p>\n\naria-expanded<\/code>to indicate whether the menu is open or closed, and aria-controls<\/code> 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. <\/p>\n\nBreadcrumbs: show where you are<\/h3>\n\n
<nav aria-label=\"Brotkr\u00fcmel\"><\/code> tag using an ordered list. The current page appears as the last entry and is marked with aria-current=\"page\"<\/code>; use aria-hidden=\"true\"<\/code> to hide the separators. <\/p>\n\nThe search as a second option<\/h3>\n\n
role=\"search\"<\/code> so that a screen reader can recognise it as a landmark. Both can be implemented with minimal effort. <\/p>\n\nFooter and sidebar navigation<\/h3>\n\n
aria-label<\/code> 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. <\/p>\n\nMark the current page<\/h3>\n\n
aria-current=\"page\"<\/code> attribute. This way, the screen reader will announce that this is the page currently open. <\/p>\n\nLink texts that speak for themselves<\/h3>\n\n
The test: open the list of landmarks<\/h3>\n\n
aria-label<\/code> on every <nav><\/code>. 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. <\/p>\n\nCommon mistakes when navigating<\/h3>\n\n
\n
Frequently asked questions about accessible navigation<\/h3>\n\n
Is a menu the only way to access the content?<\/h3>\n\n
Can the hamburger menu consist of just one icon?<\/h3>\n\n
aria-label<\/code> and hide the icon. <\/p>\n\nAre hover-only drop-downs permitted?<\/h3>\n\n
aria-expanded<\/code>. <\/p>\n\nHow to make your navigation accessible<\/h3>\n\n
Approach<\/th> Checks code<\/th> Checks operation<\/th> Evidence<\/th><\/tr><\/thead> Free scanner<\/td> measurable defects<\/td> no<\/td> no<\/td><\/tr> Overlay-Widget<\/td> Covers up, does not fix<\/td> no<\/td> no<\/td><\/tr> Access Ready (ifdb)<\/td> Code and Operation<\/td> yes<\/td> yes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n