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

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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.

ONE 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.

Source: W3C ARIA Authoring Practices Guide (APG), Dialog (Modal) Pattern