Focus management
Deliberately moving keyboard focus after an action (route change, dialog open, row deleted) so nobody gets dumped at the top.
See it
What it is
Load a fresh document and the browser starts you over in it. A single page app never does that: after a client-side navigation the URL and the content change while the browsing context, and whatever had focus, carry straight over. If the element that had focus is now gone, where the next Tab picks up is up to the browser and the assistive tech, and either way nothing announces that the page changed at all. Focus management is you handling by hand what a real navigation used to handle for you.
The moves are small and repeatable: after a route change, send focus to the new page's heading or main landmark. When a dialog opens, send it inside; when it closes, send it back to the trigger that opened it. After deleting a row, send it to the next row, or to the list container if the list is now empty. After a multi-step form advances, send it to the new step.
Gotcha: containers like h1, section, or div cannot receive focus without tabindex='-1', so calling focus() on them silently does nothing. Bigger gotcha: do not steal focus for things the user did not ask for. A toast, a lazily loaded widget, or a background save should speak through a live region, never yank the keyboard out from under someone mid-typing.
Ask AI for it
Add focus management to this app. On client-side route change, move focus to the new page's h1 (give it tabindex='-1') or to the main landmark, and announce the new page title in a polite live region. When a dialog, drawer, or menu opens, store the triggering element, move focus to the first meaningful control inside, and on close return focus to that stored trigger. When a list item is deleted, move focus to the next sibling item, or to the list container if the list is now empty. When a wizard step changes, move focus to the new step heading. Never move focus for background events like toasts or autosave; announce those instead.