What minimum toolchain do I need to enforce WCAG 2.2 AA in CI?

Lint with eslint-plugin-jsx-a11y, unit test with jest-axe, E2E with cypress-axe or Playwright + axe, and run Pa11y/Lighthouse for page-level checks. Convert to SARIF and upload to your PR for inline annotations.

How do we handle WCAG 2.2’s new focus and target size rules?

Ship design tokens for focus ring width/contrast and target size. Enforce via CSS utilities and component props. Add visual regression tests for focus-visible if you can.

Won’t this slow us down?

It speeds you up. Fail-fast locally, block only on critical/serious issues in PR. Teams we’ve worked with reduced post-merge a11y bugs by 60–80% in two quarters.

We’re HIPAA/PCI. Can we still store artifacts?

Yes—store them in your VPC with short TTL and PII-scrubbing. Avoid SaaS scanners and keep SARIF in your repo’s security tab. Use self-hosted runners.

We have a legacy UI and AI-generated “vibe code.” Where do we start?

Start at the design system: ship accessible Button, Link, Dialog, Combobox, and FormField. Then run component-level jest-axe and E2E on your top 5 flows. GitPlumbers can help with vibe code cleanup and code rescue to get you above the bar fast.

Security-compliance · Nov 14, 2025 · 9 minute read

Stop Hand-Waving Accessibility: How We Made WCAG 2.2 AA + ARIA Non‑Negotiable in CI

If your “accessibility” plan is a Jira label and a quarterly audit, you’re already in trouble. Here’s how to turn WCAG 2.2 AA and ARIA into guardrails, checks, and automated proofs that ship fast—even under HIPAA/PCI/GDPR constraints.

Back to all posts

Stop Hand-Waving Accessibility: How We Made WCAG 2.2 AA + ARIA Non‑Negotiable in CI

Key takeaways

Implementation checklist