What parts of WCAG 2.2 cause the most regressions?

Focus not obscured (2.4.11/12) because of sticky headers, target size (2.5.8) when designers compress controls, and accessible authentication (3.3.8/9) when people add CAPTCHA without alternatives.

Is axe/pa11y enough to claim WCAG 2.2 AA compliance?

They’re necessary but not sufficient. Automated tools catch ~30–40% of issues. Pair them with design-system guardrails, manual keyboard checks in Storybook, and targeted Playwright tests for 2.2 deltas.

How do we avoid storing PHI/PII in test artifacts?

Use synthetic data, block calls to prod, redact logs (pino/winston redaction), and blackout PII in screenshots. Treat your CI like a public space.

Won’t this slow us down?

For about two sprints you’ll feel friction. After that, gates catch issues at PR time, not during audit week. Teams we’ve helped saw fewer rollbacks and faster approvals because evidence ships with the code.

Can GitPlumbers retrofit this into a legacy monolith?

Yes. We start with ESLint + jest-axe on the design system (or we carve one out), add page-level scans, then gate deployments with artifacts. We’ve done this in Rails, Java/Spring MVC, and React/Next monoliths without a rewrite.

Security-compliance · Nov 20, 2025 · 10 minute read

Make WCAG 2.2 AA a Build Breaker: ARIA as Code, Evidence on Every Commit

Stop treating accessibility like an afterthought. Turn WCAG 2.2 AA and ARIA into acceptance criteria, guardrails, and automated proofs that ship fast without leaking regulated data.

Back to all posts

Make WCAG 2.2 AA a Build Breaker: ARIA as Code, Evidence on Every Commit

Key takeaways

Implementation checklist