Focusable elements present before component resume in Qwik SSR

Qwik’s lazy resumability means server-rendered HTML can contain focusable elements before their component code loads on the client. For accessibility, this creates uncertainty about whether keyboard users and screen reader users encounter a stable, predictable experience when interacting with or navigating to those elements.

Standard ARIA attributes and native HTML semantics are supported in Qwik JSX, but the framework does not document a built-in focus-trap or route-change announcement primitive. Because behavior may differ between Qwik versions and SSR, static generation, or client rendering modes, it is unclear whether focus management and dynamic content announcements happen automatically or require manual implementation.

Does Qwik automatically move focus or announce route changes after a component resumes, or must developers manage focus and ARIA live regions manually? How does lazy resumability affect the timing of focusability for keyboard navigation across route boundaries in the current version? Are there any documented Qwik-specific utilities for accessibility during resume, or should teams rely only on standard web platform features?