Bottom Sheet

You’re about to order dinner and tap Delivery time. A panel slides up from the bottom with time slots. You pick 19:30, scroll to see later slots… and the whole panel slides away. Did it save 19:30 or not? You can’t tell. That panel is a bottom sheet, and that moment of doubt is a bug.

Bottom sheets are everywhere on phones: sort and filter options, share menus, maps, music players, checkout choices. They feel natural because they sit where your thumb is. But they mix two gestures in one place (scroll the content, drag the sheet), they have many exits, and they often hold unsaved choices. Let’s learn them properly.

What is a bottom sheet?

A bottom sheet is a surface that slides up from the bottom edge and shows extra content or options related to the current screen. It can usually be dragged to different heights and swiped down to close.

There are two kinds, and testers must know which one they’re looking at:

• Modal bottom sheet: sits on top of the page behind a dim scrim, blocks everything else and must be closed before you continue. It’s a modalModalA window that appears on top of the page and blocks the content behind it until it is closed.Open in glossary → that happens to come from the bottom. Example: Sort by, Share, Choose delivery time.
• Standard (persistent) bottom sheet: lives next to the main content, without a scrim. You can still use the page behind it. Example: the list of places under a map, the mini player in a music app.

Anatomy

How it differs from similar components

Component	Blocks the page?	Can resize?	Typical use
Modal bottom sheet	Yes (scrim)	Often (detents)	Options, filters, a short task
Standard bottom sheet	No	Yes (peek / half / full)	Results under a map, a mini player
iOS action sheet	Yes	No	A few actions about one item, plus Cancel
Dialog	Yes	No	A short decision in the middle of the screen
Full-screen page	Replaces it	No	Long forms and multi-step tasks

Dev note

Apple calls them sheets. They can stop at heights called detents (medium is about half the screen, large is almost full), and the little bar on top is the grabber. The short list of actions with a separate Cancel is an action sheet (now built as a confirmation dialog). Material Design says bottom sheet (modal or standard) and drag handle. On the web you’ll hear bottom sheet, drawer or bottom drawer. In bug reports, use your team’s name and say which kind it is.

Designs & variants

Each demo below is fully working. Open it, drag it, and close it every way you can.

Every demo works. Open each sheet and try every way out: the buttons, tapping outside, Esc, and dragging the handle down. Drag the handles up too.

Flights

FromLisbon

Restaurants

Sort: Recommended

7 cafés nearby

• Café Mila · 4.7 · 200 m
• Bean There · 4.5 · 350 m
• Kaffeehaus · 4.6 · 400 m
• Roastery 9 · 4.8 · 650 m
• Little Cup · 4.3 · 700 m
• Oat & Co · 4.4 · 900 m
• Brew Lab · 4.6 · 1.1 km

Height: peek

Photo

Delete photo…

shop.example.com

T-shirts · 42

Filters

Modal or standard?

Ask one question: can I still use the page behind it?

• If no, it’s modal: there must be a scrim, taps must not reach the page, focus must stay inside, and there must be a clear way out.
• If yes, it’s standard: there’s no scrim, the page behind must keep working (zoom the map, tap a pin), and it usually can’t be dismissed, only collapsed to a “peek” height.

A sheet that dims the page but still lets taps through, or that blocks the page without dimming it, is mixing the two. That’s a bug, or at least a design finding.

When to use it

A bottom sheet is a good choice when:

• The task is short and related to the current screen: pick a sort order, choose a time slot, share a link.
• The user benefits from seeing the screen behind (a map, a product) while choosing.
• There are a few options or one small form that fit comfortably at the first height.
• The content should be within thumb reach on a phone.

Good and bad uses

How a good bottom sheet behaves

Heights and dragging

A sheet opens at a defined height (often medium, or just tall enough for its content) and can snap between a few heights, called detents. Dragging the grabber up expands it; dragging down collapses it to the next height, or closes it from the lowest one. When you let go between heights, it should snap to the nearest one. A fast flick should go one step in the flick’s direction.

It should also reopen at its default height every time, and never show up cut off, empty, or taller than the screen.

Scroll vs drag

This is where most sheet bugs live. A sheet with a long list has two things that move with the same finger movement. The rule real apps follow:

If dragging the list moves the sheet even when it’s scrolled down, users can’t scroll, and they close the sheet when they only wanted to see earlier items.

Every way to close a modal sheet

Exit	Where	What must happen
Cancel / X / Close	Everywhere	Closes, changes nothing
Swipe down	iOS, Android, often mobile web	Same as Cancel
Tap the scrim	Everywhere	Same as Cancel. The tap must not reach the page behind
System Back	Android (button or gesture)	Closes the sheet first, not the screen behind
Esc key	Web; hardware keyboards on phones and tablets	Same as Cancel
Screen reader escape	VoiceOver two-finger Z, TalkBack Back	Same as Cancel
Done / Apply / Confirm	Everywhere	The only exit that saves the choice

The keyboard

When a field inside the sheet gets focus, the keyboard takes up about 40% of the screen. The sheet must move up so the focused field and the main button stay visible. If the sheet is tall, its content should shrink and scroll rather than push the header off the top of the screen. Test in portrait and landscape, where very little space is left.

Small screens, landscape and large text

Test on the smallest supported phone, in landscape, and at the largest text size (Dynamic TypeDynamic TypeThe phone setting that lets users make text bigger or smaller across apps.Open in glossary → on iOS, Font size on Android). The header and the main button must stay reachable, the content must scroll, and the sheet must respect the safe areaSafe areaThe part of the screen not covered by the notch, Dynamic Island, rounded corners or home indicator.Open in glossary → so the home indicator doesn’t cover the last button.

Common bugs

#	Bug	What you see	Typical severity
1	Scroll fights drag	Dragging the list moves the sheet; you can’t scroll, or you close it by accident	High
2	Keyboard covers the field	The text field or Save button is hidden behind the keyboard	High
3	Dismiss loses or saves silently	A swipe throws away a half-filled form, or applies a choice you never confirmed	High
4	Taps go through the scrim	Tapping the dimmed area also presses a button on the page behind	Medium–High
5	Gesture-only closing	No Cancel or X; Esc, Back and screen reader escape don’t work	High (for affected users)
6	Wrong height	Reopens half-collapsed, cut off, or taller than the screen on small phones	Medium
7	Page behind scrolls	Scrolling inside the sheet also scrolls the page under it	Medium
8	Focus stays behind	The screen reader keeps reading the page, not the sheet	High (for affected users)
9	Stuck or jumpy animation	The sheet stops between heights or bounces after a fast flick	Low
10	Double sheets	A double tap opens two sheets, or the sheet reopens after closing	Medium

Try it: the sheet lab

Open the sheet, change the option, then try to get out every way. Drag on the list, not only on the grabber. Tap the note field to bring up the keyboard. Then switch one good behavior off at a time and repeat.

9:41

Checkout

Burger Lab€14.50

DeliveryLeave at the door

Tap “Delivery” to open the sheet.

Open the sheet, change the option, then try to close it every way. Drag the list, not just the grabber. Tap the note field to bring up the keyboard. Then switch a behavior off and repeat.

Scroll before dragDragging the list scrolls it. Only at the top does it move the sheet.Move above the keyboardThe sheet rises so the note field and Save stay visible.Ask before discardingSwipe, tap outside and Cancel ask first if you changed something.

What happened

Clear

• Nothing yet.

Find the bug

This iOS food delivery checkout has a Delivery time sheet with six bugs. Explore it like a tester:

• Open the sheet and drag the list of time slots (with the mouse or your finger).
• Pick a slot, then close the sheet in different ways and check the checkout row each time.
• Tap the dimmed area over the buttons behind the sheet.
• Tap the note field. Try to close it with Esc or the device panel buttons.

🐞 Bug hunt: Delivery time sheet

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

Found0/6

9:41

Checkout

Burger Lab

• Classic burger€9.501
• Sweet potato fries€4.201

• Rua Augusta 12, Lisbon
• ASAP · 25–35 min
• Visa •• 4242

Total incl. delivery€16.19

Place order

Device

Restart app

Esc (hardware keyboard)VoiceOver: 2-finger Z

Event log

• Sheet events appear here…

1. 1

   Hint: Try to scroll the time slots by dragging them.

   Dragging the list drags the sheet instead of scrolling

   Every drag on the list moves the whole sheet: up expands it, down closes it. You can never scroll to later slots by dragging. Expected: the list scrolls first, and only a downward drag at the very top moves the sheet (nested scrolling).

   Reveal answer✓ I found this
2. 2

   Hint: Tap “Note for the courier”.

   The keyboard covers the courier note

   The keyboard slides up over the note field and the Confirm button. The user types blind and can’t confirm without closing the keyboard. Expected: the sheet moves up so the focused field and the main button stay visible.

   Reveal answer✓ I found this
3. 3

   Hint: Pick a different slot, then swipe the sheet down. Check the checkout row. Then do the same but tap outside.

   Swiping down applies a slot you never confirmed

   After a swipe-down, the checkout shows the new slot although the user never pressed Confirm. Tapping outside, on the other hand, discards it. Expected: every exit except Confirm cancels (or the app asks first).

   Reveal answer✓ I found this
4. 4

   Hint: With the sheet open, tap the dimmed + next to an item.

   Taps on the scrim reach the page behind

   The sheet closes, but the tap also lands on the + button behind it and adds another burger to the order (and the total goes up). Expected: the scrim blocks the page; a tap on it only closes the sheet.

   Reveal answer✓ I found this
5. 5

   Hint: Look for a Cancel or close button. Try Esc and the VoiceOver escape gesture in the device panel.

   No way to close the sheet without a swipe

   There is no Cancel or X, and Esc and the VoiceOver two-finger Z do nothing. Users who can’t swipe, or who use a keyboard or switch control, can only escape by choosing a slot. Expected: a visible Cancel / close button, and Esc and the escape gesture close the sheet.

   Reveal answer✓ I found this
6. 6

   Hint: Swipe the sheet down to close it, then open it again.

   After a swipe-down, the sheet reopens cut off

   The sheet comes back at the height where you let go, showing little more than its title. The drag offset is never reset. Expected: the sheet always reopens at its default (medium) height.

   Reveal answer✓ I found this

How to test it

Checklist

Bottom sheet test checklist

0 of 13 checked

Copy

• The sheet opens at its default height every time, fully visible, never cut off
• Dragging the grabber snaps to each height, and a flick moves one step
• Dragging the content scrolls it first; the sheet only moves from the top of the list
• Cancel / X, swipe down, tap outside, Back and Esc all close without saving
• Only Done / Confirm / Apply saves; unsaved form input triggers “Discard changes?”
• Taps on the scrim never reach the page behind, and the page behind does not scroll
• A standard (non-modal) sheet leaves the page behind fully usable
• Fields and the main button stay visible with the keyboard open, in portrait and landscape
• The sheet fits the smallest phone, landscape and the largest text size; content scrolls
• The last button is not covered by the home indicator or navigation bar (safe area)
• Focus moves into the sheet, stays inside, and returns to the trigger on close
• The screen reader announces the sheet and its title, and can close it without gestures
• A double tap on the trigger opens only one sheet

Example test cases

Tools

• iOS Simulator: I/O › Keyboard › Toggle Software Keyboard (Cmd+K) shows the on-screen keyboard. With Connect Hardware Keyboard on, the software keyboard may never appear, so you’d miss bug #2. Turn on VoiceOver in Settings › Accessibility or use the Accessibility Inspector.
• Android Emulator: test Back with the button and with gesture navigation, rotate with the toolbar, and raise Font size and Display size in Settings. Turn on TalkBack from Settings › Accessibility.
• Web: use the device toolbar in DevTools for small viewports, but test the keyboard on a real phone: desktop emulation doesn’t show the virtual keyboard. Check role="dialog", aria-modal and focus in the Accessibility pane.

Accessibility

• Announce it. A modal sheet is a dialog: the screen readerScreen readerSoftware that reads the screen aloud for blind and low-vision users, like VoiceOver or TalkBack.Open in glossary → should say its title and that it’s a dialog when it opens. See Modal for the full set of dialog rules.
  Dev note

  On the web, use role="dialog" with aria-modal="true" and aria-labelledby (or a native <dialog>).
• Focus moves in, stays in, comes back. Focus goes to the sheet when it opens, a focus trapFocus trapKeeping keyboard focus inside an open modal so users can't tab into the hidden page behind it.Open in glossary → keeps Tab inside a modal sheet, and focus returns to the trigger when it closes.
• Never gesture-only. Every gestureGestureA touch action such as tap, long press, swipe, pinch or drag.Open in glossary → needs a non-gesture alternative (see Gestures): a visible Cancel or Close button, Esc, Android Back and the VoiceOver escape gesture. WCAGWCAGThe Web Content Accessibility Guidelines, the main international standard for accessibility.Open in glossary → 2.2 asks that anything done by dragging can also be done with a simple tap or click (success criterion 2.5.7, Dragging Movements), so resizing should also work by tapping or activating the grabber.
• Grabber with a name. If the grabber is focusable, it needs a label and action, e.g. “Sheet grabber, double-tap to expand”. iOS and Material’s drag handles provide this; custom ones often don’t.
• Touch targetsTouch targetThe area of the screen that responds to a tap, which should be large enough for a finger.Open in glossary →: Cancel, X and every option at least 44×44 pt (iOS) / 48×48 dp (Android). A thin grabber alone is hard to hit, so the whole header should be draggable.
• Large text and contrast: content scrolls rather than clips at the biggest text size, text has 4.5:1 contrast and the sheet’s edge stands out from the page (3:1, or a clear scrim).

Mobile vs web

iOSAndroidWeb

• Sheets: rounded card with an optional grabber, swipe down to close.
  Dev note

  UISheetPresentationController / SwiftUI .sheet with .presentationDetents([.medium, .large]).
• Apps can block swipe-to-dismiss when there are unsaved changes and ask first. Test that it’s on where it should be.
  Dev note

  .interactiveDismissDisabled() / isModalInPresentation.
• A sheet can leave the page behind usable at smaller heights (like Maps). Then it behaves like a standard sheet: no dimming, page still works.
• Action sheets (confirmation dialogs) are not draggable and always have Cancel. On iPad, sheets and action sheets look different (centered or as a popover), so test both.

• Material 3 modal bottom sheets have a scrim, rounded 28 dp top corners and a drag handle. They can open partially expanded, then expand fully.
• Standard bottom sheets stay on screen next to the content, often with a peek height.
  Dev note

  Compose: ModalBottomSheet and BottomSheetScaffold.
• System Back (button or gesture) must close a modal sheet first. With predictive back, the sheet should animate along with the Back swipe and only close when you release.
• Test rotation and process death: the sheet may vanish, duplicate or lose its selection. Test TalkBack, Font size and Display size.

• On desktop the sheet is often a side drawer or centered dialog. Test both breakpoints.
  Dev note

  There’s no native “bottom sheet” element. It’s a <dialog> or a custom div styled as a sheet.
• Check Esc, the close button, click outside, the focus trap and scroll lock (the page behind must not scroll, especially on iOS Safari).
• On a real phone, check the virtual keyboard: mobile browsers don’t always resize the page, so a sheet stuck to the bottom can end up behind it.
• Decide what browser Back does while the sheet is open. Either way, it must not lose the user’s input.

Check your understanding

Quick quiz

0/5 answered · 0 correct

1. 1.You picked a new delivery slot in a sheet, then swiped the sheet down without tapping Confirm. What should happen?

   AThe new slot is savedBThe sheet closes and the old slot stays (or the app asks first)CThe sheet expands to full heightDThe app goes back to the previous screen

2. 2.The list in a sheet is scrolled halfway down. You drag down on the list. What should move?

   AThe sheet, down towards closingBThe list, scrolling back upCNothingDThe page behind the sheet

3. 3.Which one is a standard (persistent) bottom sheet?

   AA "Sort by" sheet with a scrimBA list of cafés under a map that you can still pan and zoomCAn iOS "Delete photo?" action sheetDA full-screen "Add card" form

4. 4.A sheet can only be closed by swiping down. Why is that a problem?

   AIt looks old-fashionedBSome users can't swipe: keyboard, switch control and many screen reader users need a button or EscCSwiping is slower than tappingDIt isn't a problem

5. 5.Which test is MOST likely to show that the keyboard covers a field in a sheet?

   ADesktop browser at full widthBSmallest phone in landscape with the software keyboard onCTablet in portrait with a hardware keyboardDChecking the sheet's colors

Key takeaways

• A modal sheet blocks the page with a scrim; a standard sheet sits beside the content and keeps the page usable. Know which one you’re testing.
• Sheets snap between detents. They should always reopen at their default height, fully visible.
• Scroll before drag: the content scrolls first, and the sheet moves only from the top of the list.
• Every exit except Confirm means cancel. Swipes must never silently save a choice or silently throw away a form.
• Always test the keyboard, small screens and landscape, taps on the scrim, and closing without gestures (Cancel, Esc, Back, screen reader).