Modals, sheets, and drawers: when to interrupt

An overlay is an interruption. Every time you ship one, you're telling the user "stop what you're doing, deal with this". The question isn't whether to use modals, every product needs them, but which kind, and when.

There are four overlay patterns that have settled into modern UI: the dialog, the sheet, the drawer, and the popover. They're not interchangeable, and the wrong choice is what makes a product feel clumsy.

The four overlays

Dialog (centered modal)

A small panel centered over a dimmed page. Used for confirmations ("Delete this project?"), single-question forms, and critical alerts. The page behind is greyed out and uninteractable.

Reach for it when the user must answer before continuing, and the answer is short. Avoid for complex forms or long content, the dialog's small frame fights anything that needs scrolling.

Sheet (side panel)

A panel that slides in from the right (or left, on RTL) and takes up roughly a third of the screen. The page behind stays partially visible. Used for detail views (clicking a row in a table), edit forms, and context that benefits from staying near the page.

Sheets are the most underused pattern in modern web UI. Many teams reach for a dialog for tasks that should be sheets, anything where the user wants to keep one eye on the underlying page, or where the task involves more than 3 form fields.

Drawer (bottom sheet, mobile-first)

A panel that slides up from the bottom of the screen, ergonomically reachable on mobile. iOS uses these everywhere. On web, they're appropriate for mobile-first flows, action menus, and anything that benefits from staying near the user's thumb.

Popover (anchored to a trigger)

A small panel that floats next to the element that triggered it. Used for tooltips, mini-menus, date pickers, color pickers. The popover is not a modal, clicking outside dismisses it without ceremony, and the rest of the page stays interactable.

Use popovers for short, single-purpose interactions tightly bound to a specific UI element. Don't put forms in popovers, they're too small and the dismiss-on-outside-click behavior eats input on mis-clicks.

The decision tree

1. 01Is the answer required to continue? If yes, dialog. If no, one of the others.
2. 02Does the user need to see the underlying page while interacting? If yes, sheet (web) or drawer (mobile). If no, dialog.
3. 03Is it anchored to a specific element? If yes, popover. If no, sheet or dialog.
4. 04Is it on mobile, and would a thumb-reach matter? If yes, drawer. Otherwise, sheet.

The accessibility rules

Overlays are where most products fail accessibility. The rules are well-defined and the libraries (Radix Dialog, headless UI, shadcn/ui) implement them correctly, if you use them. Don't roll your own.

• Focus moves into the overlay on open. First focusable element, usually the close button or first input.
• Focus is trapped inside the overlay while it's open. Tab cycles through interactive elements within the overlay only.
• Escape closes it. Always. Even when there's a close button, power users hit Escape first.
• Focus returns to the trigger on close. If the user clicked a button to open the overlay, focus returns there on close. This is what keyboard-only users rely on to maintain their place.
• The page behind is `aria-hidden` while the overlay is open, so screen readers don't read both layers simultaneously.

The interruption budget

Every overlay in your product costs you a small amount of trust. Users tolerate interruptions when they're useful and rage when they're not. A few patterns burn the budget fastest:

1. 01Newsletter signup modals on entry. The user hasn't seen the product yet, what would they sign up for? Ship after they've shown interest, or not at all.
2. 02Cookie consent dialogs that take five clicks to decline. Required by law in some jurisdictions; required to be reasonable by your users.
3. 03Confirmation modals for non-destructive actions. Don't ask "Are you sure?" when the action is reversible. Reserve confirmations for deletes and irreversible changes.
4. 04Modals that open other modals. If your overlay has a button that opens another overlay, the flow needs to be one surface. Stacked modals are a smell.

Build them well

The modals entry in the directory has the anatomy and tuned prompts for all four overlay patterns. Pair with notifications for the toast/banner alternatives, most things teams ship as modals are actually toasts in disguise.