One thing worth mentioning for anyone evaluating k6: the k6 extensions ecosystem is worth exploring early. We added xk6-sql to test some of our DB-heavy endpoints more realistically. The extension model is a bit involved to set up but powerful.

For SPA routing specifically — the accepted pattern is moving focus to either the new page <h1> or a skip link after navigation. Most teams just… don’t do this. It’s a significant failure for screen reader users but keyboard-only users are also affected.

Good list. A few things I’d add from our testing standards in indonesia:

• Timeout warnings — if your app has session timeouts, can a keyboard user dismiss the warning and extend the session in time?
• Drag and drop alternatives — anything with drag-and-drop UI needs a keyboard-accessible alternative. Often completely forgotten.
• Autocomplete/combobox patterns — these are notoriously broken. Test whether results can be navigated with arrow keys and selected with Enter.

The aria-live inconsistency you’re describing is a known pain point. JAWS has its own internal logic for deciding what’s “worth” announcing from live regions and it doesn’t always respect aria-atomic the way the spec intends.

What’s worked for us: wrapping live region content in a visually-hidden but real <p> tag rather than relying purely on ARIA attributes. More semantic HTML tends to behave more predictably across readers than heavy ARIA decoration.

<p class="sr-only" aria-live="polite">Form submitted successfully</p>

It feels old-fashioned but it’s more reliable in practice.