In a client-side-routed app where navigation swaps the page content without a full document load, why do keyboard and screen-reader users lose their place, and what markup makes the fix possible?

## What a real navigation gives you for free When the browser loads a new document, focus is reset to the top of the new page, the tab order restarts there, and assistive technology announces the new document. None of that is something the page author arranged — it is what a document load means. ## What breaks when the router swaps the view A client-side route change is a DOM mutation. The old view is removed, the new one is inserted, and the URL is updated — but the document never changes as far as the browser is concerned. Two things follow. First, focus. It was on the link the user activated, and that link has just been removed from the document. When the focused element disappears, focus reverts to `<body>`. From there the next Tab starts at the first focusable element in the whole page — the skip link, the logo, the entire navigation — every single time the user navigates. On a documentation site with a sidebar of a hundred links, that is unusable. Second, announcement. Nothing tells a screen-reader user that the view changed. The visual transition is invisible to them; unless something moves focus or announces, the software's position in the page and the page itself have silently diverged. ## The markup that makes the fix possible The fix is a focus target that exists in the newly rendered view. It has to be focusable, and headings and landmarks are not focusable by default, so it needs a negative tabindex: ```html <main id="main" tabindex="-1"> <h1 tabindex="-1">Search results</h1> </main> ``` Then, after the new view has committed to the DOM, move focus to it: ```html <script> document.getElementById('main').focus({ preventScroll: true }); </script> ``` `-1` rather than `0` matters: the target must be reachable by `focus()` but must not become an extra Tab stop for everyone on every page. ## Where to put focus The view's `<h1>` is usually the best destination, because focusing it means the title of the new view is the first thing announced — you get the navigation signal and the orientation in one move. The `<main>` landmark is the other reasonable choice, and is often preferable when the heading is not the first meaningful content. What not to focus: the first interactive control in the view, which skips past the content the user came for; and anything in the header or navigation, which puts them back where they were trying to leave. ## Ordering and the silent failure The focus call must happen after the new content is in the DOM. Calling `focus()` on a node that has not been rendered yet does nothing at all, silently — no error, no exception. The same silence is what you get if you forget the `tabindex` on the heading: `focus()` on a non-focusable element is a no-op, and focus simply stays on the body. Both bugs look identical from the outside, which is why this is worth testing explicitly rather than assuming. ## Do not move focus on every update This discipline is for navigations, not for every state change. Filtering a list in place, revealing a detail row, or a background refresh must not yank focus — the user may be typing. Moving focus is an interruption, and it is justified when the user's context has genuinely been replaced. Back and forward through history count as navigations for this purpose and need the same treatment. ## Scroll is not focus Scrolling to the top of the page is a separate concern that routers often handle and that people mistake for the fix. It repositions the viewport for a sighted mouse user and does nothing for the tab order or for what is announced. Handle both, and if you restore scroll yourself, pass `preventScroll: true` so the focus call does not fight your scroll restoration. ## Testing it Tab into the page, activate a navigation link with Enter, then press Tab once. The next focus stop must be inside the new view. If it is the skip link or the site logo, focus went to the body and the fix is not working — regardless of what the scroll position did.