How to make a site navigation menu work by keyboard and touch

Choose navigation before choosing interaction

A customer uses site navigation to find a destination, not to operate a desktop application menu. Start by listing the actual destinations and deciding which links deserve top-level prominence. If the site is small, a plain visible list of links may be clearer than a collapsed system. If groups are useful, decide whether a parent label links to an overview page or only opens a set of child links. That decision determines whether one control is enough or whether the parent link needs a separate disclosure button. W3C guidance says a typical site navigation disclosure does not need the complex menu and menubar roles that imply application-style keyboard behavior. Do not add those roles merely because the design calls the component a menu.

Keep the destination hierarchy consistent across desktop and mobile. A compact layout can hide some groups behind a labelled control, but the wording, order, and target pages should remain recognizable. W3C’s menu structure tutorial recommends consistent structure across screen sizes. Give users another route to important child pages, such as a useful parent overview, when a fly-out may be difficult to operate. The goal is to let someone reach the desired page despite limited dexterity, magnification, a narrow viewport, or a missed tap. These choices should be made with the content owner, because a technically operable control cannot repair confusing category names or a destination that is absent.

Use links for destinations and buttons for disclosure

A link should navigate; a button should change the visibility of child links. When the parent also has a landing page, keep its link and place a separately named button beside it to open the submenu. W3C’s fly-out guidance describes this case directly. The button should expose whether the controlled group is expanded, using aria-expanded that changes with the visible state. Put child links in an ordinary list nested under the relevant parent, within a named navigation region where that helps identify the landmark. Do not leave collapsed links keyboard-focusable while visually hidden. The underlying HTML should still make sense if styling changes, and any scripted state change must keep visual and announced states in sync.

Avoid relying on hover as the only way to expose children. Hover assumes a pointer and can fail for touch, keyboard, and people whose pointer movements are imprecise. W3C recommends alternatives for fly-out destinations and describes activation methods for keyboard users. A disclosure button should respond to Enter and Space through its native button behavior. After it opens, Tab can move through the visible links; when it closes, the next Tab stop should be the next useful control, not a hidden child. Escape can close an open group and return focus to its control in the W3C disclosure example, but test that behavior in the actual site rather than copying example code without adaptation.

Keep focus, state, and destination understandable

The visible focus indicator must remain clear against the navigation background and must not disappear behind a sticky header or open panel. Test both forward and reverse Tab order from a fresh page load, after opening a group, and after following a child link back to the site. If the current page is represented in the navigation, use a consistent visual cue and an appropriate current-page indication; W3C discusses aria-current for this purpose. Keep the label of an expandable control specific enough for a screen reader user to know which group it opens. A generic “more” repeated several times forces the reader to infer the missing context.

Decide what happens when a user opens a second group or leaves the navigation. Closing the first group can reduce clutter, but do not move focus unexpectedly to a distant control. If the open panel overlays page content, ensure it does not obscure the focused link at the tested zoom and viewport sizes. If a mobile drawer opens, its relationship to the page requires its own focus and closing design; do not assume the desktop dropdown behavior covers it automatically. The W3C examples are illustrative and warn that assistive-technology support should be checked in the target browser combinations. A design review should therefore include real keyboard and screen-reader trials, not only a static accessibility scanner.

Test a real search for a destination

Imagine a fictional Hong Kong repair shop with top-level links for Services, Prices, and Contact. Services also has a landing page and child links for home repairs and business maintenance. On desktop, a keyboard user reaches the Services link, then a clearly named “Show Services links” button. Activating the link opens the overview; activating the button reveals the two child links. The user can Tab into either child, follow it, or close the group and continue to Prices. On a narrow phone, the same destinations appear in the same order behind a clearly labelled navigation control. This scenario specifies expected behavior, not a claim about an observed customer.

Give a tester three tasks instead of saying “test the menu”: find the business maintenance page without a mouse, return and find Prices using only touch, and locate Contact with a screen reader at a narrow zoomed viewport. Watch where they expect the parent link to go, whether the disclosure state is announced, whether visible focus follows keyboard focus, and whether the panel can be dismissed without losing place. A failed task may indicate poor labels or hierarchy rather than broken JavaScript. Write the failure in terms of the destination the person could not reach, then decide whether to change structure, wording, interaction, or all three.

Verify the same destinations across input methods

A release check should cover every top-level item and at least one child in each group on both wide and narrow layouts. Confirm that links navigate to the intended URL, buttons only disclose, state announcements match the display, hidden items leave the Tab sequence, and focus is neither lost nor concealed. Test Enter, Space, Tab, Shift+Tab, Escape where implemented, pointer click, and touch. Optional arrow-key behavior in the W3C disclosure example supplements ordinary Tab movement; do not make arrows the sole route to the links. Compare the published destinations with the approved site map so a technically accessible control does not quietly omit a key service page.

Keep a small decision record for later content changes: which top-level labels exist, whether each parent is a destination or a disclosure, and who approves new child links. When a new service arrives, adding another nested level is not automatically the best answer. Reconsider whether the parent overview, page content, or search offers a simpler route. Review the menu after translation changes too; a Chinese label may wrap differently or need a more specific accessible name. The next action for the business owner is to nominate three high-value destination tasks, observe a real keyboard and touch pass, and fix any point where the visitor loses the route.

A useful design checkpoint is to compare the menu against a real visitor question before polishing animation. If a customer wants to know whether the repair shop handles office equipment, can they predict which top-level label contains that answer? A vague category can force repeated opening and closing even when the buttons work perfectly. Ask the content owner to name each group from the visitor’s perspective and limit overlapping destinations. Check that the same destination is not described differently in the page heading, parent overview, and navigation link without good reason. For a bilingual site, review both language editions with their own line lengths and reading expectations, not a mechanical translation of one menu. A short label may be convenient for layout but too cryptic when announced out of context. When labels or hierarchy change, repeat the three destination tasks and preserve the previously reachable route until the replacement has been verified.

Test the control with content that resembles the real site. Placeholder labels all of similar length can conceal a problem that appears when a long Chinese service name wraps or when an English category contains several words. At the tested zoom level, check that the expanded group remains visually attached to its controlling button, its links are not clipped by a container, and its close action is discoverable. If the design switches from horizontal links to a mobile drawer, record the viewport where that happens and test around the boundary, not only on a very wide monitor and a small phone. A visitor can also rotate a device or enlarge text after opening the navigation; verify that the state remains understandable and that the destination still works. These tests connect interface mechanics to the real decision the visitor is trying to make.

After release, treat navigation complaints as task evidence. Ask which page the visitor wanted, what label they chose, and where they lost the route. Avoid counting clicks alone as success: repeated opening of several groups may be a sign that labels are unclear. Use those observations to revise the structure and then rerun the same tasks.