WCAG 2.1 AA Accessibility Testing: A Practical Checklist for Product Teams

Accessibility testing has a reputation as a compliance checkbox, but the failures it catches are real product bugs: buttons nobody can reach by keyboard, forms screen readers announce as empty, text that disappears against its background for low-vision users. WCAG 2.1 AA is the standard most legislation references, and enforcing it continuously is far cheaper than retrofitting it.

The checks that catch the most failures

Contrast ratios fail more audits than anything else. AA requires 4.5:1 for normal text and 3:1 for large text — and dark-themed interfaces fail constantly because muted gray-on-dark palettes drop below threshold. Automated contrast checking on every build catches these the day they are introduced.

Keyboard navigation is the second giant: every interactive element must be reachable and operable without a mouse, in a logical order, with a visible focus indicator. Modal dialogs are the classic failure — focus must move into the dialog on open, stay trapped inside, and return on close.

Screen reader flows require semantics, not just markup: form inputs need programmatically-associated labels, images need meaningful alt text, dynamic updates need live regions. Tools like axe-core catch roughly half of WCAG failures automatically; the rest need scripted journey tests that simulate real assistive-technology usage.

Making it continuous instead of annual

The teams that stay compliant are the ones that treat accessibility like any other regression class: enforced on every build, failing loudly, filed automatically. An annual audit tells you how far you drifted; a per-build gate stops the drift entirely.

QAShift includes accessibility testing in every plan — axe-core scans plus keyboard and screen-reader journey tests, with WCAG 2.1 AA as the enforced baseline and violations filed to Jira like any functional bug. Accessibility regressions appear in the same 9am report as everything else, which is exactly where they belong.