Accessibility is often treated as a finishing touch, but for navigation, it belongs at the foundation. Menus are how users reach everything else on a site, so a menu that works only with a mouse quietly shuts out anyone who depends on a keyboard, a screen reader, or another form of assistive technology.
In this clip, William Hudson, UX Strategist and Founder of Syntagm Ltd, looks at what it takes to build menus that everyone can operate, and at a few straightforward habits that keep navigation inclusive from the start.
Why Menu Accessibility Matters
Navigation menus are the primary way users move around a website or application. If a menu cannot be operated without a mouse, a significant group of users is effectively locked out: people who use only keyboards, switch access devices, eye-tracking systems, or speech interfaces all depend on menus that respond to inputs other than mouse events.
The Web Content Accessibility Guidelines (WCAG) require that all functionality be operable via keyboard. For menus, this means users must be able to open, navigate, and activate menu items using the Tab key, arrow keys, Enter, and Space, without ever reaching for a mouse.
The Mouse-Only Trap
The video illustrates the problem using an example from an earlier Adobe website: a navigation menu built entirely around mouse events. Keyboard users and assistive technology users simply could not interact with it.
The failure matters beyond keyboard users. A speech interface user who cannot use a keyboard will typically speak the name of a menu item to activate it. If the underlying menu responds only to mouse events and the speech software does not emulate mouse actions, nothing happens. The user is stuck.
The lesson is straightforward: never build navigation that relies solely on mouse interaction. Mouse-triggered behavior should be an enhancement on top of a keyboard-accessible baseline, not a replacement for it.
AI-Generated Navigation Code
This warning has become more pressing as developers rely on AI coding assistants to generate navigation code. Studies through 2025 and 2026 found that AI-generated interface code frequently reproduces the very problems described here: mouse-only event handlers, a clickable div where a real button was needed, missing keyboard support, and focus that moves in a confusing order. The code often looks correct and can even pass an automated checker, while remaining unusable with a keyboard or screen reader. The lesson is unchanged, but worth restating in this context: never ship AI-generated navigation without testing it with a keyboard and assistive technology. The tool accelerates the work; it does not vouch for the result. (See the WebAIM Million Report in the references for more information.)
Start Simple: A Baseline-First Approach
The video recommends a progressive approach to menu implementation. Begin with plain HTML navigation: simple, static links that work in every browser and with every assistive technology. If the page loads successfully and JavaScript is available, more elaborate behaviors such as dropdowns and flyout panels can be layered on top. But the plain HTML navigation remains in place as the fallback.
This approach means that even in the worst case, where a dynamic menu fails to load, or a user’s assistive technology cannot interpret the enhanced version, the core navigation still works.
Local and Secondary Navigation
The video draws attention to secondary or local navigation: the contextual links that appear within a particular section of a site, offering more specific choices once a user has made a top-level selection. The New York Times example shows this clearly: selecting a top-level section brings up a local navigation bar with regional options, making it easy to navigate further without returning to the main menu.
For screen reader users, secondary navigation is particularly valuable because it is typically positioned close to the primary navigation in the page structure. A screen reader user can quickly navigate to it without having to work through the full page content.
Skip Links
A skip link is usually the first focusable element on a page, allowing users to skip repeated navigation and go directly to the main content. It is often hidden, but since it is also useful to sighted readers, this varies from site to site. The video shows an example from the New York Times, where a “Skip to main content” link appears when a keyboard or screen reader user begins navigating the page.
Skip links are a low-cost, high-impact accessibility feature. Any site with a substantial navigation block at the top of every page should have one.
Meaningful Link Text
Link text must be meaningful in isolation. Screen readers can present users with a list of all the links on a page, read out one after another. If every link says “click here,” that list is useless.
Every navigation link should clearly describe its destination so it makes sense when read without any surrounding context. The link text should make the consequences of its action clear and unambiguous.
The Take Away
All navigation must be operable by keyboard. Tab, arrow keys, Enter, and Space are the minimum; never rely on mouse events alone.
Build navigation on a plain HTML baseline first. Dynamic enhancements such as dropdowns should layer on top, not replace, that baseline.
Secondary or local navigation helps users drill down within a section and is especially easy for screen reader users to access when positioned near the primary navigation.
Include a skip link on every page with substantial top-of-page navigation, so keyboard and screen reader users can reach the main content without working through the full navigation block.
Write link text that makes sense in isolation. Screen readers can list all links on a page; “click here” repeated across that list is meaningless.
References and Further Reading
NVDA, the screen reader demonstrated in the video, is free. It is a useful tool for any designer who wants to test keyboard and screen reader behavior without specialist hardware.
For full keyboard accessibility requirements, see the WCAG Understanding Guideline 2.1: Keyboard Accessible.
The WebAIM Million: A 2026 report on the accessibility of the top 1,000,000 home pages.
Hero image: © Interaction Design Foundation, CC BY-SA 4.0
