A Next.js Audit for Fast Sites and Quiet Route Changes

What We Keep Finding

Next.js apps are fast precisely because the browser does less, and assistive technology notices what the browser skips. Here is the part most teams have backwards, though. Next already handles the announcement. It mounts a route announcer in both routers, by default, on every app, and that announcer reads the page title out loud when the route changes.

Which relocates the bug rather than removing it. The App Router's announcer only speaks when the new title differs from the old one, and it has no fallback if the title is missing. So two routes sharing a title announce nothing at all, and a shared layout with one static title in its metadata produces exactly that. The failure is silent, it survives code review, and it looks like a framework bug when it is a titling bug. Titles per route stop being a nicety and start being the whole mechanism.

Focus is the other half, and no framework announcer touches it. Next moves nothing. After a client navigation your user's focus is still sitting on the link they clicked, pointing at a view that no longer exists. Meanwhile the announcer cheerfully reads out a page they cannot reach from where they are. That split is genuinely useful to know, because it tells you which half of the problem your team owns. And it changes the fix. Moving focus to the new view is itself a change of context, so a page that both moves focus and fires its own live region announces the same thing twice.

Server-action forms have their own version of this, and the two halves get confused constantly. An error has to be described in text on the page, which is one rule. Whether the page announces that error out loud is a different rule. A form can satisfy the first and fail the second. An error that is on screen and never spoken is a real finding, and an error that is spoken and never written down is a different real finding.