For a modal dialog, which dismissal routes should a design-system spec require, and when should a backdrop click not close it?

## The dismissal routes A **modal dialog** blocks the rest of the screen, so the way out matters as much as the way in. A design-system dialog spec typically names four routes: - **Escape key** — the WAI-ARIA Authoring Practices (APG) dialog pattern lists Escape as closing the dialog. The alert-dialog pattern, used for confirmations, reuses the same keyboard contract, so Escape closes confirmations too. - **A visible close or cancel control** — the APG strongly recommends that the tab sequence of every dialog include a visible element with the button role that closes it, such as a close icon or a Cancel button. Pointer, touch and switch users need something they can see. - **Backdrop click or tap** — the APG notes that *in some implementations* attempts to interact with the inert content cause the dialog to close. That makes it an optional convenience, not part of the contract. - **Platform back actions** — on native mobile, the system back action and, for sheets, a downward swipe are the expected dismissals, and users will try them. ## Every route means cancel Whatever route the user takes, dismissal must mean **cancel**: close without applying the dialog's action. A dialog that submits its form when the user presses Escape, or confirms a removal when they tap the backdrop, turns an escape hatch into a trigger. The spec should say this outright, because it is easy to wire a single 'on close' handler that saves. ## When the backdrop should not dismiss Backdrop dismissal is convenient for light, stateless dialogs — an information dialog, a picker whose choice has not been applied yet. It is harmful in three situations: 1. **The dialog holds unsaved input.** In a pharmacy prescription-refill app, a user types a two-line delivery note, then taps just outside the dialog while scrolling on a phone. If the backdrop dismisses, the note is gone. Either ignore backdrop taps for dialogs with input, or ask 'Discard your note?' before closing. 2. **The dialog exists to get an explicit answer.** A delete confirmation should end with the user choosing an action they read. A stray tap should not count as an answer; Escape and Cancel remain available as deliberate ways to decline. 3. **The dialog is large on a small screen.** When the dialog nearly fills the viewport, the thin backdrop strip is mostly hit by accident. | Dialog type | Escape | Close / Cancel control | Backdrop click | |---|---|---|---| | Information, no input | closes | present | may close | | Holds typed input | closes, or asks first if data would be lost | present | off, or asks first | | Confirmation of an action | closes as cancel | present | off | ## Is containing Tab a keyboard trap? A modal dialog keeps Tab and Shift+Tab inside itself, which can look like a violation of **WCAG 2.2 success criterion 2.1.2 No Keyboard Trap (Level A)**. It is not, because that criterion asks that focus can be moved away using only a keyboard, with standard exit methods or with the user told how. A modal that closes on Escape and has a keyboard-reachable Cancel meets it. A modal that disables Escape and whose only exit is a pointer target does not — that is a genuine trap. ## Dismissal on touch and native platforms Touch changes the balance. On a phone, the backdrop strip is small and is often hit while the user is trying to scroll, and sheets add a downward swipe as a dismissal. Both are fast, which is good for a light dialog and dangerous for one holding input. The same guards apply: a sheet with typed content should resist the swipe or ask before discarding, and the system back action should behave exactly like Escape — close the top dialog as a cancel, nothing more. Testing dismissal only with a mouse and keyboard misses most accidental closes, because they happen on touch. ## What to put in the spec - which routes each dialog variant honours, per platform, - that every route is a cancel, never a confirm, - the backdrop rule per variant, with 'ask before discarding' as the pattern for input, - that Escape is never disabled to force a choice. Writing these down once removes a whole class of product-team decisions, and it keeps the behaviour identical wherever the dialog appears, which is what makes a modal feel safe to open.