Can we automate 100% of WCAG 2.2 AA?

No. Automation catches a large chunk (name/role/value, contrast, ARIA misuse, focus traps), but you still need manual checks for keyboard flows, visual focus quality, and screen reader experience. Treat automation as the gate and manual as periodic audits.

We’re a heavy SPA—won’t dynamic content break scanners?

Use Playwright/Cypress to drive real states before running axe. Wait for idle/networkquiet, open modals/menus, and analyze specific containers. Test the state your users see, not just the initial DOM.

Will this slow our teams down?

After the first week, it speeds you up. Lint rules and Storybook addons provide instant feedback; CI fails early instead of during release. Two‑tier checks keep PRs fast and deep scans off the happy path.

How do we handle third‑party widgets and iframes?

Sandbox them. Wrap with accessible affordances, provide keyboard alternatives, and require vendors to deliver their own a11y scan artifacts. If they can’t, gate usage behind a risk exception with a deprecation date.

Security-compliance · Oct 3, 2025 · 9 minute read

The Day-Before Audit That Blocked Release: Making WCAG 2.2 AA and ARIA Non‑Negotiable

Translate policy into guardrails, checks, and automated proofs—without slowing delivery or leaking regulated data.

Alex K. Harper

Principal Engineer, GitPlumbers

20+ years shipping and rescuing software in fintech, healthcare, and gov. Ex-SRE lead, accessibility stickler, and the person you call when audits block releases.

Accessibility isn’t a feature. It’s a failing test you haven’t run yet.

Back to all posts

The Day-Before Audit That Blocked Release: Making WCAG 2.2 AA and ARIA Non‑Negotiable

Key takeaways

Implementation checklist