Focus management in single-page interactions: dialogs, route changes and removed elements

Goal

Keep keyboard focus somewhere meaningful every time the page changes without a full load: opening and closing dialogs, client-side navigation, deleting the focused element, and replacing a view after an action. A full page load resets focus for everyone; a single-page transition has to do that work itself.

Prerequisites

Native <dialog> where possible; a router that exposes a hook after the new view has rendered; and the tabindex="-1" technique, which MDN describes as making an element focusable by script without adding it to the Tab sequence.

Steps

1. Dialogs: open with showModal(). MDN states that a modal dialog makes the rest of the page inert and can be closed with the Esc key, so a hand-written focus trap is unnecessary. Before opening, store a reference to the triggering element.
2. On open, move focus into the dialog. The APG dialog pattern says focus moves to an element contained in the dialog, usually the first focusable element; for a dialog that starts with long text, give the heading tabindex="-1" and focus that, so the user reads before acting.
3. On close, return focus to the stored trigger. The APG pattern notes the exception: if the trigger no longer exists, focus goes to another element that continues the workflow.
4. Route changes: after the new view renders, set document.title and move focus to the view's main heading (tabindex="-1") or to the main landmark. If the previously focused node was replaced during rendering, focus has already fallen to body.
5. Removed elements: when a "delete" control removes the row it lives in, decide in advance where focus goes: the same control in the next row, the previous row, or the list heading with a status message.
6. Revealed content: for disclosures and accordions keep focus on the trigger; for step-by-step flows that replace the whole view, treat the new step like a route change.
7. Keep the focus ring visible: never remove outline without an equivalent; style :focus-visible so keyboard users see where they are.
8. Test each flow with the keyboard only, then with a screen reader, and note what is announced after every transition.

Expected result

After any interaction, Tab lands on the next sensible control; a screen reader announces the new context (dialog title, view heading, status line) instead of "document".

Limits and test basis

Recommendations follow the cited APG pattern and MDN documentation; no user study is claimed. Custom dialogs built from div elements need their own inert and Esc handling, which <dialog> provides. Where exactly focus should land after a route change is debated (heading versus landmark versus announcement only); pick one convention and apply it consistently.