Migrating to Mithril 2.x routing: how should focus and screen reader announcements be handled after m.route.set?

Short answer

Put the focus logic in one shared layout component's oncreate (or onupdate) hook, focus the <main> landmark with tabindex="-1", and update document.title in the same hook. An aria-live region can complement this but cannot replace it. m.route.prefix is a URL-only concern and has no effect on any of this.

Why the layout hook is the right place

m.route.set triggers an asynchronous redraw, so focus must be moved only after the new routed view's DOM actually exists. The lifecycle hook that guarantees this is oncreate on the vnode whose element you want to focus — it runs after that element is in the DOM. Calling focus() inside view() would fire on every redraw, stealing focus during unrelated updates.

To avoid duplicating the logic in every routed component, wrap all routes in a single layout via m.route with a render function:

m.route(root, "/home", {
  "/home": { render: () => m(Layout, m(Home)) },
  "/about": { render: () => m(Layout, m(About)) },
});

// Layout.js
export default {
  oncreate(vnode) {
    document.title = vnode.attrs.title + " | My App";
    vnode.dom.querySelector("main").focus();
  },
  view(vnode) {
    return m("main", { tabindex: "-1" }, vnode.children);
  },
};

One caveat: if the same layout DOM element persists across route changes, oncreate fires only once. In that case use onupdate instead, or key the routed content (e.g., m(Layout, { key: m.route.get() }, ...)) so the element is recreated per navigation. Which behavior you get depends on your exact Mithril 2.x patch version and structure, so verify with the pinned version.

Heading, main, or aria-live?

Focus the <main> landmark with tabindex="-1". This is the widely recommended SPA pattern: it moves keyboard and screen reader context to the start of the new content without adding the element to the tab order. Focusing a top-level <h1 tabindex="-1"> is an accepted equivalent. Without tabindex="-1", focusing a non-interactive element fails silently in some browsers.

An aria-live region alone is weaker: it announces text but does not move keyboard focus, so keyboard users remain on a stale or removed element. Use one only as a supplement (e.g., announcing the new page title). Updating document.title in the same hook gives screen readers a second, free cue that navigation occurred.

m.route.prefix

Purely a URL/server concern. It controls whether routes live in the hash, query string, or pathname; it does not change redraw timing, the DOM lifecycle, or announcements. You can switch it and confirm focus behavior is identical.

Verification

• Navigate between two routes keyboard-only: focus should land on the new <main>, and Tab should proceed through the new page's controls.
• Run NVDA or VoiceOver through a route change: the new heading/title should be announced, not the old page.
• Inspect the DOM after m.route.set: document.activeElement should be the intended main/h1 with tabindex="-1".
• Trigger an unrelated redraw on the same route and confirm focus is not stolen.

If focus lands correctly on the first navigation but not subsequent ones, that points to the oncreate-vs-onupdate persistence issue above — share whether your layout element is recreated per route if you need a definitive pick between the two.