VOL. III · CH. 3.27 · COMPONENT
Modals & Dialogs
The most overused component in modern UI — powerful when it interrupts for a reason, damaging when it interrupts from habit.
1 min read · 172 words
3.27.1Definition
A modal appears above the page, blocks interaction with everything behind it, and demands a decision before the user returns to what they were doing. The defining trait is the interruption and focus lock — if the background is still interactive, it isn't a true modal.
| Use a modal when… | Avoid when… |
|---|---|
| A destructive action needs explicit confirmation | Content is purely informational |
| A short task must not lose the user's page position | The task is long or multi-step (use a page instead) |
3.27.2Common Mistakes
- Non-dismissible modals without genuine legal/safety justification.
- Modal stacking — opening a second modal atop the first.
- Broken focus management, leaving keyboard/screen-reader users able to interact with the "blocked" background.
3.27.3Best Practices
- Trap focus, restore it to the trigger element on close, support Escape-to-close for non-destructive dialogs.
- Keep destructive-action modals to one sentence of consequence plus a clear confirm/cancel.
ExampleGitHub's "Delete repository" flow requires typing the repository name to confirm — high friction reserved specifically for an irreversible action, not used for routine confirmations.