Design the keyboard interaction flow for a modal dialog

WHAT THIS TESTS: This question probes whether you understand accessibility as a systems problem rather than a visual one. Interviewers want to see that you know a modal is not just a centered div with a backdrop, but a focus container that must manage keyboard state, trap interaction, and restore context. The specific reference here is the W3C WAI-ARIA Authoring Practices Guide dialog pattern.

A GOOD ANSWER COVERS: First, initial focus placement. When the dialog opens, focus must move into the dialog. The default target is the first focusable element, but if the content is long or structurally complex, you should place focus on a static element like the title with tabindex negative one so screen reader users can navigate semantic structures without missing context. Second, focus trapping. Tab must cycle forward through tabbable elements and wrap from the last to the first, while Shift plus Tab must cycle backward and wrap from the first to the last. This keeps keyboard users from escaping into the inert background. Third, an explicit close mechanism. The dialog must contain a visible button that closes it, and the Escape key must also dismiss it. Fourth, focus restoration. When the dialog closes, focus should return to the element that invoked it, unless that element no longer exists or the workflow logically demands placing focus on a new element such as the first cell of a newly added row.

COMMON WRONG ANSWERS: A red flag is saying the browser will handle focus automatically. Another is designing for click and touch only, then adding ARIA roles as an afterthought. Some candidates mention focus trapping but forget to account for Shift plus Tab wrapping, or they omit focus restoration entirely, leaving keyboard users stranded at the bottom of the DOM. Proposing to use positive tabindex values is also a mistake, as the spec strongly discourages values greater than zero.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle nested modals, where each layer must maintain its own focus trap and return focus to the opener of that specific layer. They might ask how you manage focus when the trigger element is removed from the DOM, or how you would handle a dialog that contains a complex widget like a calendar grid or listbox with its own arrow key behavior. Another common follow-up is how you prevent background scrolling and ensure the inert state is communicated to assistive technologies.

ONE CONCRETE EXAMPLE: Imagine a data grid with an Add Row button that opens a modal asking for a row count. When the user opens the dialog, focus moves to the number input. Tab cycles between the input, a cancel button, and a confirm button, wrapping around. Pressing Escape closes the dialog and returns focus to the Add Row button. After confirming, the dialog closes and focus moves to the first cell of the first newly inserted row rather than back to the button, because the workflow naturally continues with editing the new data.

Source: W3C WAI-ARIA Authoring Practices Guide