A route change must reset where focus sits
Aliases: SPA focus reset · navigation focus · new view start focus
What it is
A full page load puts focus back at the start of the document. Client-side routing swaps a region and changes the URL while the focus pointer stays on a node left from the previous view — often a still-living nav control in the chrome. For keyboard and screen-reader users this does not feel like a new page; it feels like still standing on the old control. On every route commit, reset focus to the start of the new view.
Reset is for “a new page”: the path changed, the main content is another view. In-page filters, pagination, and hash anchors are not this reset.
Why it happens
A single-page app injects a new view into a shell that stayed alive. The top bar, the sidebar, the nav item just pressed are often not destroyed, so focus stays attached. The user chooses Settings, the main column becomes Settings, and the pointer is still on the Settings nav item: the screen reader never hears the new heading, the next Tab may loop in the nav, and the main content has not been entered.
A full load includes a “start of document” reset; client routing has to imitate that once by hand. A common landing is the new view’s main heading (programmatically focusable) or the first block after skip-nav. Without the reset, the visual change of page is complete and the assistive channel’s “current page” is not. The more stable the shell and the more frequent the routes, the more this desync becomes the default.
Where it stops holding
In-page anchors, accordions, and tabs that do not change the route should move focus as newly appeared content, not reset to the page heading — that yank would pull the user out of the block they just opened. A route that is really an overlay on the current page (a dialog on the same URL) should restore to the trigger on close, not reset to a new “page” heading. Back-navigation may want the focus left behind rather than the heading every time; if so, make that an explicit product behavior and only if the previous trigger still exists. On a redirect chain, reset once on the final view; do not grab focus on every intermediate URL.
Applying it
- After a successful route commit, set focus to the new view’s main heading or agreed start node, and make that node programmatically focusable.
- Do not leave focus on shell navigation after a page change; the nav may remain, the pointer must enter main content.
- Exclude filters, in-page tabs, and hash anchors from route reset; give those their own landings.
- How to check: from a control in the middle of a page, keyboard-trigger navigation. A screen reader should start the new view at its heading, the focus indicator should sit at the main-content start, and the next Tab should enter the new view rather than remain on old nav. Pointer still on the nav item just used means the route swapped content and did not reset focus.