01

Start with semantics and accessible names

The menu trigger should be a button with a clear name and expanded state. An icon cannot be the only instruction; assistive technology needs to identify the control and whether the menu is open.

Use aria-current for the active page. Do not simulate buttons with non-focusable div elements or leave both hidden desktop and mobile links in the Tab order.

02

Complete navigation with a keyboard

Tab from the browser chrome and verify logical focus order, a visible focus indicator and activation by Enter or Space. When a drawer opens, focus should move sensibly; after closing, it should return to the trigger.

  • Escape closes a drawer or submenu
  • Focus does not move behind the overlay
  • A skip link reaches the main content
  • Submenus do not depend on hover
03

Review touch targets and edge placement

Icon buttons need a generous interactive area and separation even when the visible glyph is small. Test screen edges, safe-area insets and positions that are prone to accidental taps during one-handed use.

04

Repeat at 200% and 400% zoom

Zoom can force a desktop page into its compact breakpoint. Brand text, language selection, sign-in and the primary action must not collide, and users should not need two-dimensional scrolling to locate the menu.

Allow the header to grow when text is enlarged or translations are longer instead of shrinking labels below a readable size.

05

Test scroll, history and route changes

A sticky header should not cover an anchor target. Open the menu, then use browser history, switch language and navigate to another route; scroll locking and overlays should reset predictably.