Modal

Every interface mixes in a few actions that cannot be undone: deleting a document, removing someone from a team, confirming a payment. Those actions are triggered by a button like any other, so a slipped finger or a misread menu executes them exactly as if they were intended.

The first attempt at a fix was warning text in the same screen — a line under the button saying the action can't be reversed. It didn't work well. People are looking at the thing they came to do, not at the sentences around it, and by the time they read anything their hand has already committed to the click.

Pagedeck ran into this. In the document list, the overflow menu put delete directly under rename, and support took eleven deletion complaints in a month, most of them some version of "I meant to rename it." Making the warning heavier and the delete item red barely moved the number, because the problem was never that the warning was hard to see.

A modal picks a different lever: interrupt the flow instead of adding words. It covers the screen behind, leaves one window, and makes everything else unavailable until the person answers yes or no. Blocking is the whole point, which is also why it belongs only where blocking is warranted.

It's two layers stacked over the page — a translucent sheet covering what's behind, and the window itself on top. Five things have to come with them for it to behave.

1. The covering sheet — it darkens the background to pull attention forward and intercepts every click behind it. Darken without intercepting and the user clicks a button they can still see, so two screens respond at once.
2. Focus trapping — keyboard tabbing has to stay inside the window. Without it, each tab press moves focus to a button on the hidden page behind, and someone using a screen reader never learns that a dialog opened at all. This is where modals draw the most accessibility complaints.
3. Ways to close — a close button, the Escape key, and clicking the sheet are the defaults. For an irreversible decision, clicking the sheet is deliberately disabled: if a stray click dismisses the window, the interruption you just built disappears.
4. Locking the page behind — scrolling on the page underneath stops while the modal is open. Leave it unlocked and a swipe over the window scrolls the list behind it, so closing the modal drops the user somewhere they weren't.
5. Returning focus — on close, focus goes back to the button that opened it. That's what keeps a keyboard user from being thrown back to the top of the list and having to tab through forty rows to get where they were.

Three places, and they share one trait: without an answer now, there is no next step.

1. Confirming something irreversible — deleting, removing a member, finalizing a payment. Write what is about to happen into the window. "Delete 12 documents" stops people in a way that "Are you sure?" does not, because the number is the part that doesn't match what they expected.
2. A short input that has to interrupt — naming a new document, inviting a teammate. It fits only while the fields stay at two or three.
3. A block that can't wait — an expired payment card, say, where nothing further works until the person reads this and acts. Here the window often has no close button at all, or closing it returns to the previous screen.

Where not to use one is just as clear. Past about five fields the window starts scrolling and the surrounding context is gone anyway, so a full screen is the better shape. Stacking a modal on top of a modal is also avoided, since people lose track of how many layers deep they are. And a result that's fine to miss belongs in a toast, the notice that appears for a few seconds and disappears without interrupting anything.

"Put a modal in front of delete. There's no undo on it."

Nothing can bring it back, so break the flow before it runs.

"This should be a screen, not a modal. There are nine fields."

Too much content for a window, so the shape is wrong.

"If I open the modal and press tab, focus jumps to a button behind it."

Focus trapping is missing, so for a keyboard user nothing is actually blocked.

After those eleven complaints, Pagedeck put a confirmation modal in front of deletion. Noa wrote the window to carry the document's own title rather than a generic sentence. Someone proposed moving the confirm button to the left, and it was reverted because every other screen puts it on the right. The next month brought two complaints.

Theo added two more things. Clicking the sheet no longer closes the window, and focus does not start on the delete button. Both exist for the person who was holding Enter when the dialog appeared. Focus starts on cancel instead, so an absent-minded Enter does nothing at all.

The common instinct is that anything important should be a modal, since it's the surest way to be seen. The trouble is that people learn a modal as an obstacle rather than as content. Feature announcements, survey requests, and discount notices in sequence teach users to hit dismiss before reading. Once that habit is trained, the delete confirmation that genuinely needed to stop them gets dismissed at the same speed. Modals are rationed because of that effect, not out of politeness — which is why many teams cap informational modals at one per user per week.

Treating a modal as cheaper than a screen is the other frequent mistake. In build effort it usually is. But a modal normally has no address of its own, and several things disappear with it. The browser's back button leaves the page instead of closing the window, a refresh makes the window vanish, and the state can't be sent to anyone as a link. Build your invite flow as a modal and there is no URL to paste when someone asks where to invite people. Anything meant to be shared or returned to doesn't belong in one, and anything a support agent might need to walk a customer into belongs in one even less.