Managing keyboard focus in an accessible Modal

WHAT THIS TESTS This checks whether you understand the full keyboard focus lifecycle of a modal dialog, which is the most common accessibility failure in design systems.

A GOOD ANSWER COVERS Four moments matter. On open, programmatically move focus into the dialog, to the first interactive element or, if none is appropriate, the dialog container itself, so screen reader and keyboard users land inside. While open, trap focus: Tab from the last focusable element wraps to the first, and Shift+Tab from the first wraps to the last, so focus never escapes to the page behind. Make the background non-interactive by marking it inert or aria-hidden so assistive tech ignores it. Provide Escape to close. On close, restore focus to the triggering element so the user returns to where they were, not the top of the page. Use the correct semantics, role dialog with aria-modal true and a label via aria-labelledby pointing at the title, so the dialog is announced properly.

COMMON WRONG ANSWERS Not moving focus in, leaving it on the trigger so screen reader users do not know a dialog opened. No focus trap, so Tab leaks to the page behind. Forgetting to restore focus on close, disorienting the user. Missing Escape. Hiding the modal visually but leaving background focusable.

LIKELY FOLLOW-UPS How do you implement the focus trap robustly. Where should initial focus go when there is a destructive action. How does inert differ from aria-hidden.

ONE CONCRETE EXAMPLE A user opens a confirm dialog from a button. Focus moves to the dialog, Tab cycles only between Cancel and Confirm, the background is inert, Escape cancels, and on close focus returns to the original button, so a keyboard user never loses their place.