Drawer

A drawer is what a modal turns into once you decide the page behind it still matters. Filtering a table, inspecting a row, editing something you want to compare against the list it came from: all of it is easier with the original context still on screen.

Anatomy of a drawer

The handle only shows up on a bottom sheet. A side panel doesn't need one, because the edge it slides from is already the affordance.

Here it is working. Open it, then close it by clicking outside, pressing Escape, or using the close control.

Variants

Right. The default for a details panel or a form tied to a row or a card. Reading direction in most languages moves left to right, so a panel from the right reads as an addition to what you were already looking at.

Left. Reserved for navigation, the same place a fixed sidebar would live if there were room for one permanently.

Bottom. The mobile pattern. Opens with a downward-flick gesture to close, sits within thumb's reach, and never has to travel the full width of the screen the way a side panel would.

States

The dragging state only applies to a touch-driven bottom sheet. A side panel on desktop has no equivalent, it opens and closes on a fixed transition with nothing to drag.

How a drawer behaves

Slides from a screen edge, rather than scaling up from the centre the way a modal does. The direction of motion is what tells someone where it came from and where closing it will send it back to.

The page behind it stays visible, dimmed by a backdrop but not replaced by one. Someone can still see the list a filter drawer is about to change.

Focus moves into the drawer on open, the same rule a modal follows, landing on the first focusable element or the heading.

Focus is trapped while it's open, when the drawer has a backdrop and blocks the page behind it, which is the common case. Tab cycles inside the panel only.

Escape and a backdrop click both close it, unless the content has unsaved changes worth confirming first, the same exception a modal makes.

Dragging a bottom sheet follows the gesture in real time. Releasing past roughly a third of the panel's height closes it. Releasing before that snaps it back open. A drawer that ignores the gesture entirely and only responds to a dedicated close button feels stuck on a touchscreen.

Only one drawer opens at a time. Opening a second closes whatever was already open, same as a modal.

Drawer accessibility

Keyboard

The rest

• Role and state. role="dialog" with aria-modal="true" when it blocks the page, the same pattern a modal uses. A non-modal drawer that leaves the page interactive should drop aria-modal entirely rather than set it to false, since some assistive tech ignores the false value.
• Name it. aria-labelledby pointing at the drawer's own heading.
• Background inert while modal. The same inert treatment a modal needs on everything outside the panel.
• Contrast. The panel needs to read as a distinct surface against the dimmed page behind it, and any text inside needs 4.5:1 against the panel background (WCAG 1.4.3).
• Target size. The drag handle and close control both need 24 by 24 CSS pixels at minimum (WCAG 2.5.8), more on a touch-first bottom sheet, where 44 by 44 points is the safer target.

What a drawer should say

Title names what's inside, not the mechanism. "Filter results" beats "Filters panel", because the second one describes the component instead of the task.

Keep the primary action within reach without scrolling on a bottom sheet. Someone dragging a sheet up on a small phone shouldn't have to hunt for the button that finishes the job.

Empty states inside a drawer still need a next step. A filter drawer with no matches should say so and suggest clearing a filter, not just render a blank list underneath.

Common drawer mistakes

The most common failure looks identical to a broken modal, because most drawer bugs are modal bugs wearing a different animation.

1. No visible way to close it. Relying on a backdrop click or a swipe gesture alone leaves out anyone who doesn't discover either.

2. Backdrop click silently discards a form. The same rule a modal follows: confirm first, or hold off on backdrop dismissal, when there's unsaved input.

3. No focus trap on a modal drawer. Tab walks straight into the page behind it while the drawer is still open and still blocking clicks, which is a worse mismatch than a modal makes because the page is visibly right there, inviting the attempt.

4. A side drawer used for a destructive confirmation. Keeping the page visible undersells how serious the action is. Reach for a modal instead.

5. A bottom sheet that ignores the drag gesture. Feels broken on a touchscreen the first time someone tries the obvious swipe and nothing happens.

6. Content taller than the panel with no internal scroll. A drawer that just runs off the bottom of the screen, with no way to reach what's below, loses everything past the fold.

How to build a drawer

<div class="drawer-backdrop"></div>
<div role="dialog" aria-modal="true" aria-labelledby="drawer-title" class="drawer drawer--right">
  <h2 id="drawer-title">Filter results</h2>
  <button aria-label="Close">×</button>
  <!-- drawer content -->
</div>

const drawer = document.querySelector(".drawer");
const backdrop = document.querySelector(".drawer-backdrop");

function open() {
  drawer.classList.add("is-open");
  backdrop.classList.add("is-open");
  drawer.querySelector("button, [href], input, select, textarea").focus();
}

function close() {
  drawer.classList.remove("is-open");
  backdrop.classList.remove("is-open");
  trigger.focus();
}

backdrop.addEventListener("click", close);
drawer.addEventListener("keydown", (e) => e.key === "Escape" && close());

That's the shape of it. What it leaves out, focus trapping inside the panel, the drag-to-dismiss gesture on a bottom sheet, and the position-aware slide transition, is most of the actual difficulty. Vaul, the library behind this site's own drawer, and Radix's dialog primitive underneath it, handle all three. Reach for one of those before building this by hand.

Edge cases

A drawer taller than the viewport. Scroll inside the panel body, with a fixed header and footer, the same pattern a modal uses for long content.

Resizing while open, say rotating a phone from portrait to landscape. Recalculate the panel's height rather than leaving a bottom sheet sized for the orientation it opened in.

A drawer opened from inside a modal. Close the modal first. Two overlays with two separate focus traps competing for the same Tab key is not a supported combination in any major implementation.

Reduced motion. Respect prefers-reduced-motion and drop the slide to a plain fade, or remove the transition entirely.

Nested scrollable regions. A bottom sheet containing its own scrollable list needs the drag gesture and the list's scroll to not fight each other, usually resolved by only starting the drag when the list is already scrolled to its top.

Drawers in real products

Linear opens a side panel from the right when you click into an issue from a list, keeping the list scrollable and visible behind it so switching between issues doesn't cost a full navigation.

Google Maps uses a bottom sheet on mobile for place details, letting someone drag it up for the full description or down to see more of the map underneath.

Notion slides a comments panel in from the right on a page, next to the content it's commenting on rather than over it, which is the clearest case for why a drawer exists instead of a modal.