presentation form · Dialog and side surfaces
Sheet
A panel presented over the page from a defined side, commonly composed with dialog behavior and explicit close controls.
Decisive boundary
Sheet is an ecosystem presentation term, not a complete accessibility contract.
Definition and intent
What is a Sheet UI pattern?
Use the behavior, not the silhouette
A panel presented over the page from a defined side, commonly composed with dialog behavior and explicit close controls. 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.
Present a secondary task in a predictable edge-aligned panel. 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 Sheet, the boundary is: Sheet is an ecosystem presentation term, not a complete accessibility contract.
Do not implement it as Drawer when drag and snap behavior are required, or centered Dialog when side placement adds no value. 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
Present a secondary task in a predictable edge-aligned panel.
Define opening and closing
Explicit action or application event. Close action, Escape, and optionally outside interaction.
Specify access behavior
Follows the chosen modal or non-modal dialog behavior. Trigger and close are keyboard operable; Escape follows the declared rule.
Reject the near miss
Drawer when drag and snap behavior are required, or centered Dialog when side placement adds no value.
Behavior contract
What must survive the build
- trigger
- Explicit action or application event.
- dismissal
- Close action, Escape, and optionally outside interaction.
- modality
- Often modal in component libraries, but must be specified.
- focus
- Follows the chosen modal or non-modal dialog behavior.
- keyboard
- Trigger and close are keyboard operable; Escape follows the declared rule.
- interactive
- Supports forms, details, and secondary tasks.
- persistence
- Remains until closed or task completion.
- placement
- Attached to a chosen viewport side.
- mobile
- May occupy most or all of the viewport.
Failure modes
Common wrong builds
- Assuming all sheets are modal.
- Omitting an accessible title.
- Keeping a narrow desktop width on mobile.
Observable checks
Verify the result
- The side and width are intentional.
- The panel has an accessible name.
- Modality is explicit.
- Focus and Escape match modality.
- Mobile layout remains usable.
Coding-agent handoff
Implementation brief template
Pattern: Sheet Purpose: Present a secondary task in a predictable edge-aligned panel. Trigger: Explicit action or application event. Dismissal behavior: Close action, Escape, and optionally outside interaction. Modality: Often modal in component libraries, but must be specified. Focus behavior: Follows the chosen modal or non-modal dialog behavior. Keyboard behavior: Trigger and close are keyboard operable; Escape follows the declared rule. Interactive content: Supports forms, details, and secondary tasks. Placement: Attached to a chosen viewport side. Mobile behavior: May occupy most or all of the viewport. Do not implement as: Drawer when drag and snap behavior are required, or centered Dialog when side placement adds no value. Acceptance checks: - The side and width are intentional. - The panel has an accessible name. - Modality is explicit. - Focus and Escape match modality. - Mobile layout remains usable.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Sheet UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Sheet in web UI?
A panel presented over the page from a defined side, commonly composed with dialog behavior and explicit close controls. In this reference set it is a presentation form that describes placement or motion without deciding every semantic behavior.
When should I use a Sheet?
Present a secondary task in a predictable edge-aligned panel. The decisive boundary to confirm is this: Sheet is an ecosystem presentation term, not a complete accessibility contract.
What keyboard and focus behavior does a Sheet need?
Trigger and close are keyboard operable; Escape follows the declared rule. Follows the chosen modal or non-modal dialog behavior. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Sheet behave on mobile?
May occupy most or all of the viewport. Its modality is a separate requirement: Often modal in component libraries, but must be specified.
How do I verify a Sheet implementation?
Start with observable checks: The side and width are intentional. The panel has an accessible name. Modality is explicit. Then verify the remaining checks and compare the result with the linked source guidance.