How do I pivot from QA to accessibility testing?

QA to accessibility felt less like a random jump and more like a rename of the stuff I was already noticing, at least for me. I’d keep your resume anchored in QA, then add an accessibility section with real checks you can prove - keyboard flow, screen reader smoke tests, focus states, contrast issues, form labels. A tiny audit writeup or before-and-after bug examples helped me look intentional instead of scattered, could be totally different for you tho.

A lot of QA work already maps cleanly to accessibility, so I’d reframe your resume instead of “pivoting” hard. Add a small section for a11y checks you’ve done - keyboard-only pass, focus order bugs, contrast issues, alt text gaps. In my old team, 3 solid bullets beat 12 vague ones.

Build one mini portfolio piece from a real app or demo site and show 2 fixes plus the test method. Use tools like Axe and NVDA, then mention WCAG 2.1 AA by name. Apply to hybrid QA/a11y roles first - pure accessibility jobs were weirdly picky until I had at least 1 story with impact metrics and screenshots

qA teams I worked with kept treating accessibility like a side quest, then got surprised when it turned into a real hiring lane. People say to just “add WCAG” to your reesume and wait, but that reads thin. Put 2 or 3 concrete examples on there - keyboard testing, screen reader checks, color contrast failures you caught, and maybe one audit on a 50-page app - so the move looks like specialization, not a detour.

That jump feels messy, yeah. It isn’t, if you stop pretending accessibility is a totally different planet. Reframe QA as “quality and usability,” then add real a11y artifacts - bug reports, mini audits, screen reader cecks, keyboard paths. Random? Only if you make it look like one