In a pharmacy refill app, a refill modal opens an insurance modal, which opens an address modal; how would you diagnose the problems and decide whether it should become a page?
answer
- one Escape, one layer
- focus returns inside the parent dialog
- every lower layer must stay unreachable
- needs an address or Back: page
basics
~20 sStacked modals are allowed but fragile: each layer must block those beneath, Escape closes only the top one, and focus returns to its trigger in the dialog below. A multi-step task needing history or its own address belongs on a page.
solid answer
~50 sStacking is not forbidden — the Authoring Practices define a dialog as a window over the page *or another dialog* — but each layer multiplies the risk. I would test it: does Escape close only the topmost dialog, does focus return to the control inside the dialog beneath that opened it, are the lower dialogs as unreachable as the page, and does the phone's back action close one layer or throw away the whole flow? Then I'd decide by the task, not the bug list. A refill with insurance and address is a multi-step job with its own data; users may leave and return, press Back, or need more space than a dialog on a phone gives. That argues for a page, or at most one modal with a confirmation on top. A common rule of thumb is one modal layer, plus a confirmation when needed.
go deeper
Remember that one dialog opening another is allowed, but each Escape closes only the top one.
Explain the stacked contract: Escape per layer, focus returning inside the dialog below, and lower dialogs staying as unreachable as the page.
Diagnose a nested-modal flow across keyboard, screen reader and mobile back, then argue from the task's size, history and resumability whether it should be a page.
Set the system's stance on stacking and page-vs-modal as a documented default, so product teams stop nesting modals for multi-step tasks.
## Stacking is allowed, not free The WAI-ARIA Authoring Practices (APG) define a dialog as a window overlaid on either the primary window **or another dialog window**, and their modal dialog example demonstrates multiple layers. So **stacked dialogs** are legitimate. The most common, well-behaved stack is a confirmation opened from an editing dialog: 'Discard your changes?' over the dialog that holds them. Three nested modals for one task is a different matter. Each layer must honour the whole modal contract, and each extra layer is another place for it to break. A pharmacy prescription-refill flow where a refill modal opens an insurance modal, which opens an address modal, is a good candidate for diagnosis. ## What to test, layer by layer 1. **Escape closes one layer.** Under the APG keyboard contract, Escape closes the dialog — the active, topmost one. A stack where one Escape closes all three throws away the user's work in the two lower dialogs; a stack where Escape closes the wrong layer leaves focus in a hidden dialog. 2. **Focus returns to the right trigger.** When the address modal closes, focus should return to the control **inside the insurance modal** that opened it, not to the page trigger that started the whole flow. 3. **Lower layers are as unreachable as the page.** While the address modal is open, the insurance and refill modals are background too. If Tab or a screen reader can reach them, the stack has become a maze of partially blocked windows. 4. **Backdrop behaviour is unambiguous.** With three dimmed layers, which one does a backdrop click close? Users cannot tell, and compounding dims make the context unreadable. 5. **Platform back behaves predictably.** On a phone, the system back action should close one layer. If it navigates the page underneath and discards all three, the user loses the entire refill. 6. **Small screens.** Three nested dialogs on a narrow screen usually become three full-screen overlays, which is a page flow without a page's history or address. ## The underlying question: page or modal? The bugs are symptoms. The design question is whether the task belongs in a modal at all. Signals to weigh: | Signal | Points to a modal | Points to a page | |---|---|---| | Size of the task | one decision or a few fields | several sections or steps | | Need for the context behind | the user returns to it at once | the task stands on its own | | History | Back should just close it | Back should step through it | | Address | never linked or bookmarked | worth sharing, bookmarking or resuming | | Interruptions | finished in one sitting | may be left and resumed later | | Small screens | fits in a dialog | needs the whole screen anyway | A refill that collects insurance and a delivery address scores on the page side on almost every row. Users may need to fetch an insurance card, leave, and come back; Back should step through the flow; a pharmacist may send a link straight to it. ## Ways out of the stack - **Make it a page** (or a sequence of pages) with its own address and history, and keep modals for decisions inside it. - **Keep one dialog, swap its content** — the insurance and address views replace one another within a single dialog, with a clear way back to the previous view, so there is one modal layer, one Escape and one focus-return target. - **Move detail inline** — show the address as an editable section of the refill screen instead of opening a dialog for it. - **Allow a confirmation on top** of whichever surface remains; that is the stack users understand. The 'one modal layer plus a confirmation' guidance is a widely used convention, not a WCAG or APG rule. Its reason is that each additional layer adds focus-return, dismissal and inert-background obligations that are easy to get wrong and hard for users to follow. ## Writing it into the system A design-system dialog spec can state when a modal is the wrong choice, with the page-vs-modal signals as its guidance, and define the stacking rules for the cases it allows: Escape closes the top layer only, focus returns to the trigger in the layer below, and every lower layer is inert. That turns a recurring product-team debate into a documented default.
- What should the phone's system back action do when two modal dialogs are stacked?Close only the topmost dialog, exactly as Escape does, and return focus to its trigger in the dialog below. If back instead navigates the underlying screen, both dialogs and their input vanish. The spec should state this per platform, because back actions are not the same everywhere and some devices have none.
- Is a single dialog that swaps between steps really better than stacked dialogs?For keyboard and screen-reader users, usually yes: one modal layer means one Escape target, one inert background and one focus-return point. It needs its own care — announcing the new step, moving focus to its heading, and a Back control — and if the steps grow further, the task has outgrown a dialog and should be a page.
saying these in an interview costs you the question
- The Authoring Practices forbid opening a dialog from inside another dialog.
- One press of Escape should close the whole stack of dialogs at once.
- When the top dialog closes, focus should return to the page's original trigger.
- A modal always beats a page because the user never loses context.
- A modal flow needs no address; refresh and Back are edge cases.