Mobile Menu Design: 7 Patterns Developers Can Build This Week

Visible links win when your navigation is short, a persistent tab bar wins when people switch sections constantly, and accordions or curtain patterns win once the information architecture gets deep. A labelled drawer earns its place only when the link list genuinely cannot fit elsewhere. Accessibility and focus management usually decide which pattern survives contact with real users, so this guide pairs a short example gallery with the implementation and testing steps you need to ship something that works with a keyboard and a screen reader, not just a mouse.

TL;DR:

• Show four or fewer top level items as visible links; use tabs for frequent switching, and choose accordion or curtain patterns for deeper content.
• Build navigation with a nav landmark, list, and links; label the trigger button, expose its expanded state, and identify the panel it controls.
• When a menu opens, move focus to its first link or a heading; Escape should close it, and focus should return to the trigger.
• For swipeable drawers, use scroll snap and IntersectionObserver to keep swipe, backdrop, Escape, and programmatic dismissals in one consistent open or closed state.
• Avoid full screen overlays when scroll positions, form entries, or filters must persist, and keep image heavy drawers closed until needed to protect first paint.

Table of Contents

• Mobile menu examples worth borrowing
• When to use each pattern: a decision checklist
• Accessibility rules and semantic markup for navigation
• Building the menu: implementation patterns that hold up
• Testing checklist: keyboard, screen readers and performance
• How I choose between these patterns in practice
• The Super Shoppe: when you would rather commission the build
• FAQ
• Sources

Mobile menu examples worth borrowing

A small set of patterns covers almost every mobile navigation problem you will meet. Each one below comes with a note on what it suits, a caveat worth remembering, and the states your design files should capture.

• Visible compact links: best for sites with four or five top-level items; the caveat is that cramming more in breaks touch targets; capture closed, focused and active states.
• Labelled "Menu" hamburger drawer: best when the list genuinely cannot fit; the caveat is that an unlabelled icon alone hurts discovery; capture closed, open and keyboard-focused states.
• Full-screen overlay: best for marketing sites with a handful of destinations and strong visual branding; the caveat is slower perceived performance if the overlay animates heavily; capture open, scrolled and dismissed states.
• Persistent bottom tab bar: best for apps with frequent switching between a small number of sections, as Apple's Human Interface Guidelines set out; the caveat is that tabs should navigate, never trigger one-off actions; capture each tab's active and inactive states.
• Accordion groups: best for deep, multi-level information architecture; the caveat is nested accordions can hide depth from users who do not scroll; capture collapsed, expanded and nested-expanded states.
• Curtain or side-by-side pattern: best when you want to preserve context behind the menu; the caveat is layout complexity on narrow viewports; capture closed, half-open and fully revealed states.
• Billboard or top-task spotlight: best for highlighting one priority action above a longer link list; the caveat is it competes for attention with the menu trigger itself; capture default and highlighted states.

Smashing Magazine's research on mobile navigation found that accordions, curtain and billboard patterns often outperform slide-in drilldowns for discoverability and speed. When you hand these off, document each state at common mobile viewport widths, label every screenshot with its interaction state, and note focus order alongside the visuals so developers do not have to guess.

When to use each pattern: a decision checklist

Choosing a pattern comes down to four signals: how many top-level items you have, how often people switch between sections, how deep your content hierarchy runs, and whether you need to preserve scroll or form state across views.

1. Count your top-level items. Four or fewer usually fit as visible links; beyond that, consider collapsing.
2. Check switching frequency. If users jump between sections constantly, a persistent tab bar beats a drawer every time, per Apple's guidance.
3. Map your information architecture depth. Two or more nested levels favour accordions or a curtain pattern over a flat drawer list.
4. Decide what state must persist. Scroll position, form entries or filters often rule out full-screen overlays that reset the page.
5. Weigh initial paint cost. A heavy drawer with images can delay first paint on slower connections, so keep its markup lean until opened.

Pro Tip: Label a "Back" control contextually (name the section you are returning to) rather than using a generic arrow, and keep every control single-function so a back button never doubles as a close button.

Accessibility rules and semantic markup for navigation

Default to a nav element containing a list of links. The W3C ARIA Authoring Practices Guide reserves menu and menubar roles for desktop-style application widgets, since those roles impose extra keyboard behaviour that most site navigation does not need.

• Use nav plus ul plus a by default; reach for menu or menubar roles only when building a desktop-style widget.
• Hide a closed menu with display: none or visibility: hidden rather than relying on transforms or opacity, so hidden links drop out of the focus order.
• Give the trigger a native button element with aria-expanded, aria-controls and a clear aria-label describing what it opens.
• Label each nav landmark when a page has more than one, so assistive technology users can tell them apart.
• Move focus deliberately on activation (to the first link or a heading), handle the Escape key to close, and return focus to the trigger afterwards.

One recommendation to anchor your build on: Web states that opacity or translate-based hiding leaves links invisible but still focusable, a trap that catches keyboard users first.

Building the menu: implementation patterns that hold up

Translating the rules above into code means choosing techniques that behave consistently across every dismissal path, not just the one you tested most.

• For swipeable drawers, favour a scroll-driven interaction built on scroll-snap with a scroller and a spacer element, rather than a JavaScript tween, as shown in Chrome's modern navigation drawer guidance.
• Use IntersectionObserver as the single source of truth for open and closed state, since it fires consistently whether the sheet moved by swipe, backdrop tap or code.
• If browser support for the Popover API is limited for your audience, fall back to a fixed-position panel with a backdrop element rather than skipping the backdrop entirely.
• Respect prefers-reduced-motion, unify every dismissal path (swipe, backdrop tap, Escape, programmatic close) to the same state change, and apply an inert or backdrop treatment so background content cannot trap focus.
• Treat a tab bar as navigation, never a toolbar: tabs switch sections and preserve their own state, they do not fire one-off actions, per Apple's Human Interface Guidelines.

Pro Tip: Size mobile drawers with svh units rather than vh so the panel does not jump when the browser chrome shows or hides on scroll.

Testing checklist: keyboard, screen readers and performance

Validate the menu in this order, since each step catches a different class of failure before launch.

1. Tab through the closed state and confirm hidden links are unreachable; a link that is still focusable while hidden is the most common failure.
2. Test with a screen reader to confirm closing the menu removes its links from the accessibility tree, not just from view.
3. Trigger every dismissal path (swipe, backdrop tap, Escape, programmatic close) and confirm they converge on the same closed state, using IntersectionObserver events as the shared source of truth, as Chrome's guidance recommends.
4. Check focus placement after in-app navigation, moving focus to the new page's heading and announcing the change explicitly rather than leaving focus stranded.
5. Measure on a mid or low-end device, watching first input delay and the rasterisation cost of large drawer panels.

How I choose between these patterns in practice

In practice, I start from the four signals in the decision checklist before touching a design file: item count, switching frequency, depth and state. For many custom sites, visible links or a labelled drawer suffice, since navigation tends to stay shallow by design. Case studies and background notes will follow as our portfolio grows.

— Farhan

The Super Shoppe: when you would rather commission the build

If you would rather hand this off than build it yourself, we design and build custom business websites from £499 one-off, with responsive navigation implemented as part of every project rather than bolted on afterwards. Every site we build gets a layout matched to the brand it represents, not a reused template, so the menu structure fits the actual content rather than a generic pattern.

We handle the consultation, the design and the accessible implementation together, including guided support for domain and hosting setup once the site is ready. If you want a working mobile menu without managing the build in-house, get in touch for a scoping conversation about your site.

FAQ

Should I use a hamburger menu or show links directly?

Show links directly when you have four or five top-level items; collapse into a labelled hamburger drawer only once the list no longer fits, as web.dev recommends. A labelled "Menu" button performs better for discovery than an unlabelled icon alone.

Are hamburger menus bad for accessibility?

A hamburger menu is not inherently inaccessible, but it fails when the trigger lacks aria-expanded and aria-controls, or when closed links stay focusable. Following W3C APG and web.dev's hiding guidance avoids both problems.

What is the difference between a tab bar and a drawer menu?

A tab bar stays persistently visible and switches between a small set of top-level sections while preserving each section's state, which Apple's guidelines recommend for apps with frequent switching. A drawer hides behind a trigger and suits longer lists or deeper hierarchies that would not fit in a bar.

How do I make a swipeable mobile drawer accessible?

Build the drawer with semantic markup, explicit focus management and an IntersectionObserver to track open and closed state consistently, as described in Chrome's navigation drawer guidance. Pair that with Escape handling and focus return to the trigger so keyboard users are not left stranded.

Sources

• Web
• Designing navigation for mobile: design patterns and best practices — Smashing Magazine
• Menu and menubar pattern | APG | WAI | W3C