presentation form · Dialog and side surfaces
Drawer
A panel that enters from a screen edge, often with touch-friendly drag or snap behavior; modality must be specified separately.
Decisive boundary
Drawer describes presentation. Specify modality, focus, and dismissal instead of relying on the name.
Definition and intent
What is a Drawer UI pattern?
Use the behavior, not the silhouette
A panel that enters from a screen edge, often with touch-friendly drag or snap behavior; modality must be specified separately. The term is used here as a presentation form that describes placement or motion without deciding every semantic behavior. That distinction prevents a visual resemblance from silently deciding focus, keyboard, modality, or dismissal behavior.
Expose a task surface from the edge, especially when gesture behavior is useful. A good implementation preserves that job while making the trigger, open state, close path, and responsive behavior observable to users.
Know when the label is wrong
The fastest way to identify a pattern is often to reject the nearest alternative. For Drawer, the boundary is: Drawer describes presentation. Specify modality, focus, and dismissal instead of relying on the name.
Do not implement it as Dialog when edge motion is irrelevant, and Sheet when a simple fixed side panel is sufficient. If those requirements describe the real task better, use the related pattern page or the full Dialog and side surfaces comparison before writing code.
Decision process
Decide before choosing a component
Record these requirements in plain language. A library component name is not a substitute for the contract.
Confirm the user job
Expose a task surface from the edge, especially when gesture behavior is useful.
Define opening and closing
Button, gesture, or application event. Close action, Escape, outside interaction when allowed, or reverse gesture.
Specify access behavior
Depends on modality; modal drawers contain focus, non-modal drawers do not. Provide a button path and Escape behavior; gestures cannot be the only control.
Reject the near miss
Dialog when edge motion is irrelevant, and Sheet when a simple fixed side panel is sufficient.
Behavior contract
What must survive the build
- trigger
- Button, gesture, or application event.
- dismissal
- Close action, Escape, outside interaction when allowed, or reverse gesture.
- modality
- Can be modal or non-modal; must be declared.
- focus
- Depends on modality; modal drawers contain focus, non-modal drawers do not.
- keyboard
- Provide a button path and Escape behavior; gestures cannot be the only control.
- interactive
- Supports controls and task content.
- persistence
- May remain open while the user works or until dismissed.
- placement
- Enters from a viewport edge, often bottom on mobile.
- mobile
- May support drag, snap points, and larger touch targets.
Failure modes
Common wrong builds
- Making swipe the only close method.
- Leaving modality unspecified.
- Using it for primary navigation without navigation semantics.
Observable checks
Verify the result
- A keyboard trigger exists.
- Modality is explicit.
- Focus matches modality.
- Escape behavior is defined.
- Drag is not the only control.
- Safe areas are respected on mobile.
Coding-agent handoff
Implementation brief template
Pattern: Drawer Purpose: Expose a task surface from the edge, especially when gesture behavior is useful. Trigger: Button, gesture, or application event. Dismissal behavior: Close action, Escape, outside interaction when allowed, or reverse gesture. Modality: Can be modal or non-modal; must be declared. Focus behavior: Depends on modality; modal drawers contain focus, non-modal drawers do not. Keyboard behavior: Provide a button path and Escape behavior; gestures cannot be the only control. Interactive content: Supports controls and task content. Placement: Enters from a viewport edge, often bottom on mobile. Mobile behavior: May support drag, snap points, and larger touch targets. Do not implement as: Dialog when edge motion is irrelevant, and Sheet when a simple fixed side panel is sufficient. Acceptance checks: - A keyboard trigger exists. - Modality is explicit. - Focus matches modality. - Escape behavior is defined. - Drag is not the only control. - Safe areas are respected on mobile.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Drawer UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Drawer in web UI?
A panel that enters from a screen edge, often with touch-friendly drag or snap behavior; modality must be specified separately. In this reference set it is a presentation form that describes placement or motion without deciding every semantic behavior.
When should I use a Drawer?
Expose a task surface from the edge, especially when gesture behavior is useful. The decisive boundary to confirm is this: Drawer describes presentation. Specify modality, focus, and dismissal instead of relying on the name.
What keyboard and focus behavior does a Drawer need?
Provide a button path and Escape behavior; gestures cannot be the only control. Depends on modality; modal drawers contain focus, non-modal drawers do not. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Drawer behave on mobile?
May support drag, snap points, and larger touch targets. Its modality is a separate requirement: Can be modal or non-modal; must be declared.
How do I verify a Drawer implementation?
Start with observable checks: A keyboard trigger exists. Modality is explicit. Focus matches modality. Then verify the remaining checks and compare the result with the linked source guidance.