How would you create a dismissible modal dialog over the current screen?

This tests modal architecture beyond visuals. A strong answer covers: dimming the inert background, trapping focus, returning focus on close, and supporting Escape plus a visible close button.
What's really being asked
The interviewer is evaluating whether you understand that a modal is an accessibility-critical interaction pattern, not merely a visual layer. In Figma or any design tool, it is easy to draw a rectangle over a screen and call it a dialog; the senior signal is knowing that the overlay must make the underlying content inert, manage keyboard focus, and provide clear exit paths. This question separates designers who think in screens from designers who think in stateful, accessible systems.
The full answer
A good answer hits four things in order. First, visual inertness: the background behind the modal should be dimmed or obscured so users can tell the underlying content is temporarily unavailable, and clicks on that background should either be blocked or dismiss the dialog depending on the pattern. Second, focus management: when the dialog opens, focus must move to an element inside it, ideally the first focusable element or a static container with tabindex negative one if the content is complex, and when it closes focus must return to the element that invoked it unless that element no longer exists. Third, keyboard trapping: Tab and Shift-Tab should cycle only among tabbable elements inside the dialog, never escaping to the page behind it, and the Escape key should close the dialog. Fourth, visible close controls: the tab sequence must include a visible button that closes the dialog, such as a close icon or cancel button, rather than relying solely on background clicks.
The mistakes people make
The most common red flag is describing the modal purely in visual terms, for example mentioning auto-layout, component variants, and overlay transitions without ever discussing focus, keyboard behavior, or screen reader announcements. Another red flag is suggesting that users can simply click outside to close without also providing an explicit close button inside the dialog, since the W3C pattern strongly recommends a visible control. A third red flag is forgetting to restore focus to the trigger on dismissal, which breaks keyboard workflow.
What usually comes next
Expect the interviewer to ask how you would handle nested modals, where focus must move into the new layer while remembering the previous one. They may also ask when to use alertdialog versus dialog, which hinges on whether the message is brief and critical enough to restrict navigation. Another follow-up is how you prototype focus order in Figma, which typically requires annotating tab order or pairing your designs with accessibility documentation since Figma does not natively simulate focus management.
A concrete example
Suppose you are designing a Delete Account confirmation. When the user clicks Delete, the modal opens and focus moves to the Cancel button, the least destructive action, because undoing deletion is impossible. The background dims to sixty percent opacity, the dialog traps Tab cycles between Cancel and Confirm Delete, and pressing Escape closes the modal and returns focus to the Delete button in the settings list. If the Delete button is removed after confirmation, focus would move to the next logical element, such as the Account Settings heading.
Interview question
When a modal dialog opens, which focus behavior is required for accessibility?
- a.Focus is removed from the page and restored to the document root on close
- b.Focus moves to the dialog container while Tab navigates the rest of the page
- c.Focus remains on the trigger until the user presses Tab
- d.Focus moves into the dialog, traps within tabbable elements, and returns to the trigger on closeCorrect
Why? this is the answer
The card states that focus must move into the dialog on open, cycle only among tabbable elements inside it, and return to the invoking element on close. Option B is tempting because moving focus to the dialog container is sometimes appropriate, but allowing Tab to escape to the page breaks the required keyboard trap.
Just read this? Test yourself on what you have been reading.
Read the original → w3.org
- #modal
- #accessibility
- #figma
- #focus management
- #interaction design
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles