A modal blocks the main flow and belongs only on matters that must be answered

What it is

A modal dialog locks the main surface until the dialog is answered or cancelled. Modality as flow interruption is the only honest reason to do that: without this decision the main task cannot, and should not, continue — leave with unsaved work, missing permission, a destructive confirm. Previews, filters, help, and secondary settings are not must-respond matters; a modal only locks someone into a panel that could have run in parallel. Focus handling and keyboard dismissal come later. The first question is whether the main flow ought to stop.

Why it happens

People walk one task path at a time. A modal cuts that path with a scrim and an untappable main surface, and forces working memory to hang on the question in the dialog. If that question is truly a precondition for further action, the cut prevents invalid next steps (clicking around a page with no permission, walking off unsaved edits). If the question is only “have a look,” the cut steals the task: coming back means rebuilding position, selection, and unfinished thought. Modals also carry a social urgency; used often they devalue, and when a real block arrives people dismiss it by habit. “Must respond” is not a stern tone. It is a logical precondition — until the question is answered, the main surface has no lawful next step.

Studying it

Take the same content as a modal, a non-modal side panel, and an in-page block, and insert it into a main task already underway. Record duration of interruption, errors after resume, and the rate of closing the dialog unread. Independent variables: whether the content is actually a precondition of the next step, timing (user-initiated versus system-pushed). Dependent variables: time to finish the main task, discarded in-progress state. System-pushed modals that are not preconditions should show the highest unread-close rate.

Where it stops holding

Legally required consent and payment confirmation are must-respond even when they annoy. A background success message is not; it blocks no next step. Full-screen immersive editing (canvas, code) sometimes wears a modal shell to isolate the session; what is actually blocking is the editing session, which does not need another “answer this first” dialog on top. On multi-window desktops a modal usually locks its own window and leaves others usable; do not read window-level modality as “nothing was interrupted.”

Applying it

• Write one sentence: if this is not answered, what lawful next step remains on the main surface? If one remains, do not use a modal.
• Put previews, filters, and explanations in panels that do not lock the main surface, or in the page. Keep modals for irreversibility, permission, and leave protection.
• Decisions that can wait for a user-initiated open should not pop during load or idle.
• How to check: fire the candidate dialog halfway through a user’s work and count instant closes plus complaints of interruption. Those candidates should not be modal.

Related

• Within the group: E4.10.2 A modal must trap focus and restore it on close · E4.10.3 A modal should not open another modal · E4.10.4 A modal must offer a keyboard-reachable way to close
• Adjacent: E4.11 Non-modal panels · E6.05 Confirmation dialogs
• Search terms: modal dialog · flow interruption · must respond