Mobile navigation: from opening a menu to finding a page
Design mobile menus with clear labels, comfortable targets, predictable states and checks for keyboard use, small screens and zoom.
Updated: · AI-generated editorial illustration
Mobile navigation is a wayfinding tool. An attractive icon that is difficult to activate, a submenu that disappears during interaction or an overlay that cannot be closed can block the visitor's task. Optimisation starts with the pages people need and the way they return to the content, rather than with a slide animation.
This guide uses a service website with website services, marketing, articles and contact sections. Apply the same review method to a shop, with additional attention to categories, search and the cart. The examples are design scenarios, not measurements of behaviour on your own website.
1. Choose the structure before the animation
List the main tasks and give each destination a predictable label. Website services is clearer than an internal department name. Individual articles usually belong in the article catalogue rather than the primary menu. When there are two levels, make it clear which item expands a submenu and which opens a page.
A service group can have a submenu control and a separate link to all website services. This avoids making one label both expand and navigate depending on where someone taps. Before implementation, show the structure to someone outside the project and ask where they would look for a specific task. Their answer can expose unclear grouping early.
2. Distinguish controls from destinations
Use buttons to change interface state and links to reach resources. A menu button needs a clear accessible name, an expanded state and a relationship to the navigation region. A clickable div without keyboard handling is an incomplete substitute. The W3C WAI menus tutorial is a useful reference for structure and accessible operation.
When the menu opens, visitors need orientation and a predictable exit. A modal overlay requires dialog-style focus and background handling. Navigation expanding within a header should not automatically trap focus as though it were a modal. Choose one model and test its behaviour consistently rather than combining pieces of several patterns.
3. Leave room for touch and long labels
A touch target should not be limited to the visible icon. Add padding and separation where adjacent controls could be confused. WCAG 2.2 includes a target-size criterion with specific conditions and exceptions; use the quick reference instead of treating every design recommendation as the same requirement. A practical interface can aim for approximately 44px targets where the layout allows.
Do not test only one familiar phone. Longer Vietnamese labels, enlarged text, landscape orientation and short viewports can exceed the available height. Let the menu content scroll when needed, keep the closing control discoverable and prevent submenus from extending beyond the viewport.
4. Complete the state and navigation behaviour
Opening the menu, expanding a group, switching groups, closing, clicking outside and pressing Escape are different states. Decide each one rather than letting incidental event-handler behaviour define the experience. On desktop, preserve the hover path between a label and its panel so a small gap does not close it immediately. On touch devices, remove any dependence on hovering.
After choosing a destination, the menu should close. For same-page anchors, preserve the intended scroll target and account for the sticky header. Check browser back navigation and scroll restoration so an old menu state does not cover returned content. Reduced-motion settings should change the transition while preserving every operation.
5. Test a complete task rather than a screenshot
Use a task sequence: locate a service, open it, return, switch language and reach contact. Complete it with a pointer, keyboard and touch. Try Tab, Shift+Tab, Enter, Space and Escape where they apply. Check visible focus, accurate control names and unobscured interactive elements.
Record viewport, language, action and failure. At 320px the marketing label extends outside the panel after text enlargement is more actionable than mobile looks wrong. The accessibility guide connects menu review to reading and operating the full page.
After a fix, repeat the affected task and neighbouring states. Repeated screenshots alone are not a useful test loop. The evidence should show that visitors can complete the journey the menu is intended to support, including failure and exit paths.
Frequently asked questions
Should every screen use a hamburger menu?
Not necessarily. When a larger screen has sufficient room, visible links can make destinations easier to discover. Choose the breakpoint based on actual labels and tasks rather than a device name.
References and further reading
To apply this to your current website, explore the website service or contact Dean Vu to define a scope around your existing site and actual evidence.