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.

We use an LLM to convert Gherkin specs into Playwright test scaffolding. It’s not magic but it cuts the initial draft time by maybe 60%. A tester still reviews and completes every test.

The key insight for us was: AI is good at structure and boilerplate 🦾 🦾 , humans are still needed for assertions and edge case logic. 💪💪

Given / When / Then → AI scaffold → Human review → Done

That pipeline actually works in practice. 💪

Would love to hear everyone’s thoughts on this

Indonesian developer here 🙋🏼‍♂️ We switched about eight months ago, team based in Indonesia. Zero regrets honestly. The multi-browser support alone paid for the migration effort within two sprints — we caught a Safari-specific bug in checkout that had been live for months without us knowing.

The learning curve for junior devs was real though. Playwright assumes you know async/await patterns well. We had to do internal workshops before everyone was comfortable.

Indonesian developer here 🙋🏼‍♂️ We switched about eight months ago, team based in Indonesia. Zero regrets honestly. The multi-browser support alone paid for the migration effort within two sprints — we caught a Safari-specific bug in checkout that had been live for months without us knowing.

The learning curve for junior devs was real though. Playwright assumes you know async/await patterns well. We had to do internal workshops before everyone was comfortable.