Drawer / Hamburger Menu

You’re on a clothing shop’s website on your phone. You tap ☰, pick Sale, and… the page behind changes, but the menu is still covering it. You close it by hand. Then you scroll the menu and the page behind it scrolls too. Each of these is small, but together they make the shop feel broken, and some shoppers simply leave.

Three short lines (☰) hide a whole navigation system. A drawer has to open and close in many ways, move focus correctly, lock the page behind, show where you are, and stay out of the way of the system’s own gestures. Let’s learn how a good one behaves.

What is a drawer?

A navigation drawer is a panel of destinations that slides in from the side of the screen (the left in left-to-right languages, the right in Arabic or Hebrew). It’s usually opened by the menu button, the three-line icon people call the hamburger (☰). On the web the same thing is called a hamburger menu, side menu or off-canvas menu.

It holds destinations that don’t fit in, or don’t deserve, a permanent spot on screen: all the categories of a shop, mail folders and labels, Settings, Help, Legal.

Anatomy

Modal or standard?

Type	Where	How it behaves
Modal drawer	Phones, small windows	Slides over the page with a scrim. Must be closed before you can use the page again. Like a modal.
Standard (permanent) drawer	Tablets, desktops	Sits next to the content, no scrim. Often collapsible to a narrow rail of icons.

Many apps switch between the two at a breakpointBreakpointA screen width where a responsive layout changes, for example from one column to two.Open in glossary →: a modal drawer on a phone, a standard drawer on a tablet in landscape. Test both sides of the breakpoint, and what happens when you rotate or resize while the drawer is open.

How it differs from similar components

Component	Best for	Visible?
Drawer	Many or secondary destinations	Hidden until opened (modal)
Bottom bar	3–5 main areas, used often	Always on screen
Tabs	Sections of one screen	Always on screen
Bottom sheet	Actions or options for the current task	Opened on demand

Designs & variants

Open and close each drawer in every way you can think of: tap, swipe, Esc, keyboard only.

Inbox

• Anna · Flight to Lisbon
• Shop · Your parcel is on its way
• Mila · Lunch Friday?
• Bank · Statement ready
• Gym · New class times
• Leo · Photos from Sunday

Mail

• Inbox24 unread
• Starred
• Sent
• Drafts2 unread
• Trash
• More

  Settings
• Help & feedback

shop.example.com/

Threadline

Home

Dashboard

When to use it

• There are many destinations (more than five), like the categories of a shop or the folders of a mail app.
• The destinations are secondary or used rarely: Settings, Help, Legal, account switching.
• On wide screens, as a standard drawer that’s always visible.
• On mobile websites, where the desktop’s top navigation doesn’t fit.

Good and bad uses

The hamburger debate

Hiding navigation saves space, but people use what they can see. A well-known Nielsen Norman Group study (2016) found that people used hidden navigation much less often than visible navigation, found things more slowly, and rated the tasks as harder. The effect was strongest on desktop, where hiding the menu wasn’t even necessary.

There’s another side, and you should know it too:

• Today almost everyone recognizes ☰ as “menu”. The problem is out of sight, out of mind, not confusion.
• A drawer is a reasonable home for secondary destinations, as long as the main ones are visible.
• On a small phone, a long list of shop categories simply has to go somewhere.

The usual middle ground: keep the 3–5 most important destinations visible (a bottom bar or tabs) and put the rest behind ☰.

How a good drawer behaves

Opening

• The menu button must have a name (“Menu” or “Open navigation menu”).

  Dev note

  On the web it’s a real <button> with aria-expanded that switches between false and true, and aria-controls pointing to the menu.

• Edge swipe. Some apps let you pull the drawer out from the edge of the screen. That edge is shared with the system:

  • iOS: the left edge swipe means Back. If a drawer also listens to it, one of the two loses. The safe rule: edge swipe opens the drawer only on the first screen of the app, where there’s nothing to go back to.
  • Android (gesture navigation): a swipe from either side edge is system Back. Since Android 10, a drawer can still be pulled out by pressing and holding at the edge, then dragging. A quick swipe must stay Back.

  See Gestures › Edge swipes belong to the system for the details.

• Focus moves into the drawer, usually to the current destination or the first link, so keyboard and screen readerScreen readerSoftware that reads the screen aloud for blind and low-vision users, like VoiceOver or TalkBack.Open in glossary → users know it opened.

Closing

Exit	Where	What must happen
Choose a destination	Everywhere	Navigate and close the drawer
Tap the scrim	Modal drawers	Close. The tap must not reach the page behind
Swipe the drawer away	iOS, Android, mobile web	Close
Close button (✕) / ☰ again	Web, often apps	Close
Esc	Web, hardware keyboards	Close
System Back	Android	Close the drawer first, not the screen behind
Route change	Web (single-page apps)	Close, even when the page changed some other way (a link inside the page, browser Back)

After closing, focus returns to the menu button. Otherwise keyboard users are thrown back to the top of the page, or into nothing.

While it’s open

A modal drawer is a dialog, so the rules from Modal apply:

• Focus is trapped inside the drawer (focus trapFocus trapKeeping keyboard focus inside an open modal so users can't tab into the hidden page behind it.Open in glossary →). Tab must not wander through the links hidden behind the scrimScrimThe dimmed layer behind a modal or bottom sheet that blocks the page underneath.Open in glossary →.
• Scroll lock: the page behind must not scroll when you scroll the drawer or swipe on the scrim. A long drawer scrolls on its own; when it reaches the end, the page behind stays still. See Modal › Scroll lock.
• The screen reader must not read the page behind.
  Dev note

  On the web: aria-modal="true" or inert on the rest of the page.

Showing where you are

The current destination is highlighted (Material: a pill-shaped indicator) and, on the web, marked with aria-current="page". Test it on every page, including pages reached without the drawer: from a link in the page, a deep link, a search result or browser Back. A classic web bug: matching the URL with “starts with”, so Home (/) matches every page.

Common bugs

#	Bug	What you see	Typical severity
1	Nameless menu button	Screen reader says “button”; aria-expanded stays false	High (for affected users)
2	Stays open after navigating	The page changes behind the still-open menu	Medium
3	Page behind scrolls	Scrolling the menu or the scrim moves the page	Medium
4	Wrong item highlighted	“Home” is marked on every page, or nothing is	Low–Medium
5	Focus escapes	Tab goes to links behind the scrim; Esc does nothing	High (for affected users)
6	Focus lost on close	After closing, focus jumps to the top of the page	Medium
7	Back swipe opens the drawer	On iOS, swiping back from a detail screen pulls the drawer instead	Medium–High
8	Back closes the app	Android system Back closes the app instead of the drawer	High
9	Taps go through the scrim	Tapping the dimmed area also presses a button behind it	Medium
10	Broken at the breakpoint	Rotating with the drawer open leaves a scrim with no drawer, or two menus	Medium

Try it: the drawer lab

Open the drawer with ☰ and from the edge. Close it every way: scrim, swipe, Esc, System Back, choosing a folder. Then open a message and swipe from the left edge on both platforms. Switch Edge swipe opens the drawer to Every screen and try again.

9:41

Inbox

• AAnnaFlight to Lisbon
• TTravellyYour booking is confirmed
• BBankStatement ready
• MMilaLunch Friday?
• SShopParcel on its way
• GGymNew class times
• LLeoPhotos from Sunday
• PPizza RomaYour receipt
• LLandlordRent reminder
• NNewsletterWeekly digest
• DDadCall me later
• TTeamSprint notes

Mail

• Inbox12 unread
• Starred
• Sent
• Drafts2 unread
• Trash
• More

  Settings
• Help

Platform

AndroidiOS

Edge swipe opens the drawer

OffFirst screen onlyEvery screen

System Back Restart

The shaded strip is the edge zone. Drag from it to the right with your finger or mouse. On Android with gesture navigation, a quick swipe from the edge is system Back. Press and hold at the edge first, then drag, to pull the drawer out. Also try Tab and Esc while the drawer is open.

Event log

• Opens, closes, swipes and Back presses appear here…

Find the bug

This mobile clothing shop has a hamburger menu with five bugs. Explore it like a tester:

• Open the menu and pick a page. Look at the menu and at what’s highlighted.
• Scroll with the menu open (mouse wheel or finger over the menu and the dimmed area). Watch Page scroll in the inspector.
• Use only the keyboard: Tab to the menu button, Enter, then Tab and Esc.
• Watch the accessibility inspector below the shop: what is focused, its name and its state.

🐞 Bug hunt: Threadline mobile shop

This demo has 5 hidden bugs. Explore it like a tester, then check your findings.

Found0/5

shop.example.com/

Threadline2

Autumn is here

Warm layers, soft knits and rain-ready jackets.

Shop the sale: up to 30% off →

• Wool scarf
• Rain jacket
• Knit beanie
• Canvas tote
• Linen shirt
• Chelsea boots

Accessibility inspector

Reload

Focused

Click into the shop and press Tab…

Name

–

State

–

Visible

–

Page scroll

0px

1. 1

   Hint: Tab to the ☰ button and read the inspector, before and after opening the menu.

   Menu button has no name and aria-expanded never changes

   The button contains only an icon, so the inspector shows (no name): a screen reader just says “button”. Its state stays collapsed (aria-expanded="false") even while the menu is open. Expected: a name like “Menu” and aria-expanded switching to true.

   Reveal answer✓ I found this
2. 2

   Hint: Open the menu and tap “Women”.

   Menu stays open after choosing a page

   The page and the URL change behind the scrim, but the menu stays open and must be closed by hand. The app swaps content without closing the menu on route change. Expected: choosing a destination navigates and closes the menu.

   Reveal answer✓ I found this
3. 3

   Hint: Open the menu and scroll over the menu or the dimmed area.

   Page behind scrolls while the menu is open

   The product list behind moves and Page scroll in the inspector changes. There’s no scroll lock. Expected: the page stays still while the menu is open.

   Reveal answer✓ I found this
4. 4

   Hint: Go to Sale or My orders, then open the menu.

   “Home” is highlighted on every page

   The current item is found with “URL starts with”, and every path starts with /, so Home is always marked (and has aria-current="page"). Expected: the item for the current page, e.g. Sale on /sale.

   Reveal answer✓ I found this
5. 5

   Hint: Open the menu with Enter, then press Tab a few times, then Esc.

   Esc doesn’t close the menu and focus goes to the page behind

   Focus stays on ☰ when the menu opens, and Tab walks through the basket and product links behind the open menu before it reaches the menu. Esc does nothing. Expected: focus moves into the menu, stays there (focus trap), Esc closes it, and focus returns to ☰.

   Reveal answer✓ I found this

How to test it

Checklist

Drawer test checklist

0 of 14 checked

Copy

• The menu button has a name and is at least 44 pt / 48 dp; on the web aria-expanded switches false/true
• Opening moves focus into the drawer; the screen reader announces it
• Tab and Shift+Tab stay inside an open modal drawer
• Scrim tap, swipe, ✕, Esc and Android system Back all close it, without side effects
• Choosing a destination navigates and closes the drawer
• After closing, focus returns to the menu button
• The page behind does not scroll and cannot be tapped while the drawer is open
• The current destination is highlighted on every page, also when reached without the drawer
• Badges in the drawer (e.g. unread counts) are correct and update
• iOS: the left edge swipe still goes back on deeper screens
• Android: a quick edge swipe is system Back; the drawer opens only by button or press-and-hold
• Long labels, translations and large text fit or wrap; a long drawer scrolls on its own
• Rotating or resizing across the breakpoint with the drawer open leaves a sane state
• Right-to-left languages open the drawer from the right edge

Example test cases

Tools

• Web: in DevTools, use the device toolbar for phone widths, check aria-expanded live in the Elements panel, and use the Accessibility pane to see each element’s name and role. Type document.activeElement in the Console to see where focus really is.
• Screen readers: VoiceOver on Mac (Cmd+F5) and iPhone, TalkBack on Android, NVDA on Windows.
• Android Emulator: test system Back in gesture and 3-button navigation (Settings › System › Gestures › System navigation), rotate with the toolbar, and switch the language to Arabic to check the right-to-left drawer.
• iOS Simulator: drag from the very left edge with the mouse to test the back swipe on every screen that has a drawer.

Accessibility

• Button: a real button with a name (“Menu”, “Open navigation menu”) and an expanded state that reflects the drawer. Changing the label to “Close menu” while open is fine too.
  Dev note

  aria-expanded reflects the state and aria-controls points to the menu.
• Focus: moves into the drawer on open, stays inside while open, returns to the button on close.
  Dev note

  On the web, the rest of the page gets inert or the drawer is a role="dialog" with aria-modal="true".
• Landmark: the list of links is a navigation landmark with a label, and the current link is announced as the current page.
  Dev note

  A <nav> with a label (e.g. aria-label="Main"); the current link has aria-current="page".
• Not gesture-only: every drawer opened by a swipe also has a visible button, and every drawer closed by a swipe also has ✕, Esc and Back. WCAGWCAGThe Web Content Accessibility Guidelines, the main international standard for accessibility.Open in glossary → 2.5.7 (Dragging Movements) asks that dragging always has a simple tap alternative.
• Touch targetsTouch targetThe area of the screen that responds to a tap, which should be large enough for a finger.Open in glossary →: ☰ and each item at least 44×44 pt / 48×48 dp. Destination rows in Material drawers are 56 dp tall.
• Visible focus on every item, and enough contrast for the current-page indicator (3:1) and labels (4.5:1).

Mobile vs web

iOSAndroidWeb

• No native hamburger on iPhone. If an app has one, it’s custom: test the left edge back swipe on every screen, VoiceOver, and the Dynamic Type sizes.
• iPad: a sidebar works like a standard drawer and can be shown or hidden. Test it in Split View and Slide Over, where the window is narrow.
  Dev note

  UISplitViewController, SwiftUI NavigationSplitView.

• Material modal and standard navigation drawers, or a navigation rail on bigger screens.
  Dev note

  ModalNavigationDrawer, DismissibleNavigationDrawer, PermanentNavigationDrawer in Compose.
• System Back must close the drawer first. With predictive back, the drawer should slide along with the gesture and only close on release.
• Gesture navigation reserves both edges for Back: the drawer opens by button, or press-and-hold at the edge.

• Usually a <button> plus a <nav> panel, built by hand or with a UI library. Inspect aria-expanded, aria-controls, focus, inert and scroll lock.
• Single-page apps: check that every route change (menu link, in-page link, browser Back) closes the menu.
• Responsive: the hamburger appears below a breakpointBreakpointA screen width where a responsive layout changes, for example from one column to two.Open in glossary →. Resize across it with the menu open, and check that desktop navigation and the hamburger never show at the same time.
• Mobile Safari: check that the page behind doesn’t scroll when you swipe on the scrim, and that the menu isn’t hidden behind the browser toolbar.

Check your understanding

Quick quiz

0/5 answered · 0 correct

1. 1.A user picks "Sale" in the hamburger menu. The Sale page loads behind, but the menu stays open. What is it?

   ACorrect, users close menus themselvesBA bug: choosing a destination should also close the menuCA performance issueDA screen reader setting

2. 2.Which situation fits a drawer best?

   AHome, Search, Cart and Account used all dayB25 shop categories plus Help and SettingsCOverview, Specs and Reviews of a productDChoosing a delivery time

3. 3.On iOS, on a message detail screen, you swipe from the left edge and the drawer opens. Why is that a problem?

   AIt is not, swipes can do anythingBOn iOS the left edge swipe means Back, so users can't go back the way they expectCDrawers must only open from the rightDIt uses too much memory

4. 4.On a website, the hamburger button's aria-expanded is "false" while the menu is open. Who is affected?

   ANobody, it is invisibleBScreen reader users, who are told the menu is collapsedCOnly mouse usersDSearch engines only

5. 5.The drawer is open. You press Tab and focus lands on a product link behind the dimmed area. What is missing?

   AA focus trapBA bigger scrimCA badgeDA loading state

Key takeaways

• A modal drawer slides over the page with a scrim; a standard drawer sits next to the content on wide screens.
• Hidden navigation gets used less. Keep the main destinations visible and put secondary or many destinations in the drawer.
• Closing must work every way: choosing a destination, scrim, swipe, ✕, Esc, Android Back, and every route change on the web.
• While open: focus moves in and is trapped, the page behind doesn’t scroll, and on close focus returns to ☰.
• The current page is highlighted correctly on every page, and the ☰ button has a name and a live aria-expanded.
• Edge swipes compete with iOS back swipe and Android system Back. The system gesture must win on deeper screens.