When a modal dialog opens on a page, what must happen to keyboard focus while it is open and when it closes?

## Why focus is the whole problem A modal is a visual convention: an overlay covers the page and the eye accepts that only the dialog is live. Keyboard and screen-reader users get none of that for free. Focus is still wherever it was — typically on the button that opened the dialog, which now sits behind the overlay. Press Tab and you walk into content you cannot see; a screen reader happily reads the page underneath. "Modal" is a promise about interaction, and markup has to keep it. ## The four obligations **Move focus in.** On open, focus must land inside the dialog. Nothing else makes the dialog the user's context. **Constrain it.** While open, Tab and Shift+Tab must cycle within the dialog. Focus must not reach page content, and ideally not the browser chrome round-trip either. **Neutralise the background.** Content behind the dialog should be non-interactive and absent from the accessibility tree. The `inert` attribute does both. **Restore it.** On close, focus returns to the element that opened the dialog, so the user resumes exactly where they left off. ## What the native dialog gives you `<dialog>` opened with `showModal()` satisfies all four. The browser makes the rest of the document inert, so background content is neither focusable nor exposed to assistive technology and Tab is naturally confined. It moves focus into the dialog: to the element carrying `autofocus` if there is one, otherwise the first focusable element inside, otherwise the dialog itself. Escape fires a `cancel` event and closes it. When it closes, the browser returns focus to the element that was focused before it opened. ```html <button id="open">Delete file</button> <dialog id="confirm"> <h2>Delete report.pdf?</h2> <p>This cannot be undone.</p> <form method="dialog"> <button value="cancel" autofocus>Cancel</button> <button value="delete">Delete</button> </form> </dialog> ``` Note that `show()` — the non-modal opener — does none of this: the rest of the page stays interactive and focus is not confined. Non-modal is a different component with different rules. ## Choosing where focus lands The default choice is the first interactive control in the dialog. Two adjustments matter in practice. If the dialog is content-heavy, focus a container or heading with `tabindex="-1"` instead, so the accessible name of the dialog is announced before the user starts tabbing; jumping straight to a control skips the title. And never put initial focus on a destructive action — `autofocus` belongs on Cancel, not on Delete, because Enter is pressed reflexively. ## Restoring focus, including the awkward case The trigger sometimes disappears: you opened a confirmation from a row's Delete button and the row is now gone. Falling back to `<body>` is the failure mode you are trying to avoid, because the next Tab restarts at the top of the document. Pick a stable target — the list container, the heading above it, the table — give it `tabindex="-1"`, and focus that instead. ## When you hand-roll one If you cannot use `<dialog>`, you are reimplementing all four obligations. The container needs `role="dialog"` with `aria-modal="true"` and an accessible name, the rest of the page needs `inert`, Tab must wrap from the last focusable element back to the first, and the dialog must be dismissible. Enumerating "all focusable elements" is itself unreliable: elements can be added while the dialog is open, disabled mid-flight, or hidden by CSS, so a trap computed once at open time drifts. ## Testing it Open the dialog with the keyboard alone. Focus should be inside immediately. Hold Tab and count — the ring must cycle and never appear behind the overlay. Press Escape. Focus should be back on the button you started from, and the next Tab should continue from there. Every failure in that sequence is a real bug for a real user, and none of them are visible with a mouse.