Components

Modals & Dialogs

Overlays that demand user attention. When to use them, how to design them, and how to avoid the most common modal mistakes.

#modal#dialog#overlay#popup#sheet#confirmation#drawer

What is it?

A modal (or dialog) is an overlay that appears above the main content, blocking interaction with the rest of the page until it is dismissed. It is used to display critical information, require a decision, or complete a short task without navigating away. Modals interrupt the user's flow — this interruption must be justified.

Why it matters

Modals are frequently overused. Because they interrupt user flow, they create friction and frustration when misapplied. But when used correctly — for confirmation dialogs, quick-add forms, media previews — they are highly effective. The key is that the interruption must be worth the cost.

Best Practices

Use modals only when the action requires user focus and cannot be completed inline.
Always provide a clear way to dismiss: X button, clicking the overlay, and the Escape key.
Modal content should require minimal scrolling — if the content is long, use a dedicated page or slide-over.
Confirmation dialogs must describe the specific action, not just "Are you sure?"
For destructive confirmations: the confirm button is labeled with the action ("Delete Account") and the cancel is the safer default.
Modals should trap focus — keyboard users should not be able to tab out of the modal into the background.
Do not use modals for: routine interactions, long forms, content that needs sharing via URL, or as a first-load popup.
On mobile, consider bottom sheets (slide-up panels) over traditional modals — they feel more native.
Return focus to the triggering element when the modal is closed.
Provide a modal title — screen readers announce the title when a dialog opens.

Common Mistakes

Modals on first page load — the highest-friction UX pattern. Immediately destroys trust.
Modals without Escape key support — traps keyboard users.
Confirmation dialogs with "Yes/No" — "Yes" to what? "No" to what?
Modals for long forms — should be a page or slide-over instead.
Not returning focus to the trigger element on close.
Multiple stacked modals — modal within a modal. Always a design failure.
No overlay click-to-close — users expect clicking outside a modal to close it.

Checklist

Modal use is justified — the interruption is worth the friction

Closed via: X button, overlay click, and Escape key

Focus is trapped within the modal while open

Focus returns to the trigger element on close

Modal has a clear title (for screen readers and visual clarity)

Destructive confirmations have specific action labels ("Delete Account") not "Yes/No"

Content fits without scrolling (or uses appropriate scroll pattern)

Mobile uses bottom sheet pattern where appropriate

Never used as a first-load popup

No nested modals

Research & Theory

ARIA Dialog Pattern (W3C)

The WAI-ARIA Authoring Practices define the correct accessibility implementation for modal dialogs: role="dialog", aria-modal="true", focus trapping, focus return.

Why it's relevant

Custom modals that don't follow the ARIA pattern are inaccessible to screen reader users. Follow the spec exactly.

Modal vs. Non-Modal Research (Nielsen Norman Group)

NN/g research shows that modals used appropriately improve task completion but modals used inappropriately (especially as first-load popups) significantly increase bounce rates.

Why it's relevant

The question to ask before every modal: "Could this be inline? Could this be a separate page? Does it require immediate interruption?"

Real-World Examples

Linear

New Issue dialog is a modal — short, focused, the right scope. Full issue editing is a dedicated page. The distinction is correct.

Stripe

Payment confirmation modal: specific, clear, destructive action labeled precisely ("Confirm $249 payment"), safe cancel on the left.

GitHub

Repository deletion: type the repo name to confirm. Focus trap enforced. Escape closes it. Delete button stays red/destructive, never becomes primary.