In a design system, what distinguishes a modal dialog from a non-modal dialog, and when is each the right choice?
answer
- what happens to the page behind
- can the user leave and come back
- interruption versus parallel work
- background unreachable for every input
basics
~20 sA modal dialog makes everything behind it unreachable for every user until it closes, so it fits a decision needed before continuing. A non-modal dialog lets the user keep working on the page, so it fits reference or parallel tasks.
solid answer
~50 sThe difference is behaviour, not looks. A **modal** dialog makes the content beneath it inert: pointer, keyboard and screen-reader users all stay inside it until it closes, and the background is usually dimmed and does not scroll. A **non-modal** dialog floats above the page but the user can move to the page, work there and come back without closing it. Choose modal when the user must answer before anything else makes sense (a session-expired sign-in, a delete confirmation); choose non-modal when they need the page and the dialog at once (a chat-with-a-pharmacist panel beside the medication list). If the task is large, multi-step or needs its own history, neither fits and it should be a page. The worst outcome is a mismatch: a dialog that looks modal but lets keyboard or screen-reader users reach the page behind it.
go deeper
Recall the one-line difference: a modal blocks the whole page until closed, a non-modal lets the user keep working. Give one fitting example of each.
Explain modality as behaviour across pointer, keyboard, screen reader and scrolling, and walk the decision from 'answer needed first' to 'needs its own page'.
Show you can spot the mismatch failures: dimmed but reachable backgrounds, and dialogs announced as modal to assistive technology while pointer users can still use the page.
Frame modality as a system-level contract: each dialog variant declares its modality once, per platform, so product teams stop reinventing it and its failure modes.
## What makes a dialog modal A **dialog** is a window laid over the primary screen, or over another dialog. It is **modal** when everything beneath it is out of reach until it closes. The WAI-ARIA Authoring Practices (APG) dialog pattern says windows under a modal dialog are **inert**: users cannot interact with content outside the active dialog, and that content is typically visually obscured or dimmed so it is hard to make out. Focus moves into the dialog when it opens, Tab and Shift+Tab cycle inside it, and there is no way to move keyboard focus out without closing it. Modality is a **behaviour**, not a visual treatment, and it must hold for every input at once: - **Pointer and touch** — clicks or taps on the background do nothing, or, in some implementations, close the dialog. - **Keyboard** — Tab never lands on a control behind the dialog. - **Assistive technology** — a screen reader's reading cursor stays within the dialog instead of wandering into the page behind. - **Scrolling** — by common practice (not a standard), the background does not scroll while the dialog is open, so the user cannot drift away from the place they left. ## What a non-modal dialog allows A **non-modal dialog** also floats above content and has its own tab sequence, but the user can leave it, work on the page behind, and return without closing it. Typical examples are a find-and-replace panel, a chat window, or a panel of reference information. Because it blocks nothing, it does not dim the page. It still needs a visible close control and a known way to move between it and the page, because a keyboard user who tabs out needs to be able to get back. ## Side by side | | Modal dialog | Non-modal dialog | |---|---|---| | Content behind | inert for every user | fully usable | | Focus | moves in, stays inside until close | moves in, can leave and return | | Visual treatment | background dimmed or obscured | no dim; sits beside or over content | | Fits | an answer needed before continuing | reference or a parallel task | | Main cost | interrupts and hides context | competes for space, easy to lose track of | ## Choosing between them A short decision sequence works for most cases: 1. **Must the user answer before anything else can sensibly happen?** Then it is modal. In a pharmacy prescription-refill app, a 'Your session expired — sign in again' prompt is modal because no refill action behind it can succeed until the user signs in, and a delete confirmation is modal because the answer decides what happens next. 2. **Will the user need to read or edit the page while the dialog is open?** Then it is non-modal, or not a dialog at all but inline content. A 'Chat with a pharmacist' panel should let the user scroll their medication list and ask about it at the same time. 3. **Is the task large, multi-step, or something the user may want to bookmark, share or return to with Back?** Then it belongs on a page, not in a dialog of either kind. Transferring a prescription from another pharmacy is that kind of task. 4. **Does it need no response at all?** Then it is a message, not a dialog, and belongs to the inline-message and notification families. ## The mismatch that hurts The APG pattern advises exposing a dialog as modal to assistive technology only when both conditions hold: application code prevents **all** users from interacting with the content outside it, and visual styling obscures that content. The damaging failures are mismatches between what one group of users experiences and what another does: - **Looks modal, is not.** The page is dimmed, but Tab walks into the background or a screen reader reads it. Keyboard and screen-reader users can act on controls that sighted pointer users believe are locked. - **Modal to assistive technology only.** The dialog is announced as modal, so some screen-reader users cannot reach the rest of the screen, while pointer users still click the page freely. Those users lose content everyone else has. - **Modal by habit.** Every small panel blocks the page, so users constantly close dialogs just to see what was underneath. A dialog that shows reference information the user wants to compare against the page should not be modal. ## Across platforms Native mobile has the same split under different names. A modal sheet or alert blocks the screen beneath it, including screen-reader navigation, while a persistent sheet leaves the underlying screen usable. A design system's dialog spec should therefore say, for each variant, **which kind it is**, what the background does for pointer, keyboard and screen-reader users, and how the user leaves — instead of leaving modality to whichever team implements it on each platform.
- Is a bottom sheet on a phone modal or non-modal?Either, and the spec must say which. A modal sheet dims the screen, blocks touches and screen-reader navigation behind it, and closes with a swipe, the system back action or a close control. A persistent sheet leaves the screen above it usable, like a non-modal dialog. Shape does not decide modality; what the background does for every input does.
- Why is a dialog that looks modal but lets Tab reach the page worse than an honest non-modal panel?Because sighted pointer users believe the page is locked while keyboard and screen-reader users can still trigger controls behind the overlay, often without seeing them. Actions happen out of view, and focus ends up somewhere the user cannot see. An honest non-modal panel sets the same expectation for everyone.
A modal dialog is a pharmacist who asks you to confirm your date of birth before handing anything over: nothing else happens until you answer or step away. A non-modal dialog is a leaflet you hold while you keep filling in the form.
saying these in an interview costs you the question
- A non-modal dialog is just a modal without the dimmed backdrop.
- Dimming the background is enough to make a dialog modal.
- Modal only needs to block the mouse; keyboard users can still tab to the page.
- Every panel that floats above the content should be a modal dialog.
- A non-modal dialog needs no visible close control because it blocks nothing.