WCAG 2.2 automated testing & turning test runs into compliance evidence

Accessibility and compliance usually live in two different worlds: accessibility in a one-off audit before a launch, compliance in a frantic evidence-gathering sprint before an auditor arrives. Both are treated as events. They should be byproducts — of testing you're already doing.

Can WCAG 2.2 compliance be automated?

Partly. Automated WCAG 2.2 testing reliably catches the machine-checkable failures — missing alt text, insufficient colour contrast, missing form labels, invalid ARIA, keyboard traps — but criteria that require human judgement still need a person.

The honest split, widely cited across the accessibility community: automated tools can detect on the order of 30–40% of WCAG issues with high reliability. The rest — whether alt text is meaningful, whether focus order is logical, whether content reads sensibly to a screen reader — needs human review. Any vendor claiming "100% automated WCAG compliance" is overselling. The right framing is: automate the machine-checkable layer so humans spend their time on the judgement calls.

What WCAG 2.2 actually added

WCAG 2.2, published by the W3C in 2023, adds nine success criteria on top of 2.1. The ones QA teams hit most often:

• Focus Appearance — the keyboard focus indicator must be clearly visible.
• Target Size (Minimum) — interactive targets must be large enough to hit reliably (24×24 CSS pixels, with exceptions).
• Dragging Movements — anything that works by dragging needs a single-pointer alternative.
• Consistent Help — help mechanisms appear in a consistent place across pages.
• Accessible Authentication — don't force a cognitive test (like remembering or transcribing) to log in.

Several of these — target size, focus appearance, visible-element checks — are exactly the kind of thing automation is good at, which makes 2.2 a good moment to put accessibility in CI.

Accessibility testing in CI

The shift that matters is moving accessibility from a pre-launch audit to a continuous check. Running an engine like axe-core against your pages on every build catches regressions the day they're introduced, not months later when someone files a complaint.

Done well, accessibility checks run alongside functional tests rather than as a separate initiative — the agent exercising your checkout flow is the same one that flags the unlabeled button and the low-contrast error text on the way through. That integration is the difference between accessibility being everyone's continuous habit and being one specialist's quarterly fire drill.

Turning test runs into compliance evidence

Here's the part almost no one operationalises: the test runs you're already doing are compliance evidence, if you capture them.

Frameworks like SOC 2, GDPR, and HIPAA don't just ask "are you secure?" — they ask you to demonstrate that controls are tested and working, over time. An auditor wants a trail, not a snapshot. Every automated run that is timestamped and records what was checked, what passed, and what failed is a brick in that trail:

• Accessibility evidence — dated WCAG scan results showing you test continuously and remediate, not that you ran one audit once.
• Security-control evidence — runs that exercise authentication, session expiry, access boundaries, and consent flows, with results retained.
• Release-readiness evidence — a record, per release, that quality and compliance checks ran before ship.

"Compliance evidence from your test runs" is a genuinely under-served idea. Accessibility checkers are a crowded market; the bridge from continuous testing to an audit-ready evidence trail mostly isn't built. That's the gap worth closing — because it converts work you already pay for (testing) into an asset that saves you a scramble later (audit evidence).

Where humans still own the outcome

Automation produces the evidence and catches the mechanical failures; it does not make you compliant or accessible on its own. People still:

• review the judgement-dependent WCAG criteria automation can't settle,
• decide remediation priority and acceptable risk,
• and own the attestation — automation supports the claim, it doesn't make it.

A note on honesty, because it matters in this domain: passing automated checks means "passed automated checks," not "conforms to WCAG 2.2" or "is SOC 2 compliant." Good tooling reports the former and never inflates it into the latter. (It's the same reason this site makes no SOC 2 claim for BugBrain itself — we market only controls that are real.)

The practical setup

1. Run automated WCAG 2.2 checks in CI on every build, alongside functional tests.
2. Keep a human review loop for the judgement-dependent criteria.
3. Retain every run, timestamped, as a dated evidence trail.
4. Generate release-readiness and audit reports from that trail when an auditor (or a customer security questionnaire) asks.

Accessibility and compliance stop being dreaded events when they're outputs of continuous testing. The teams that get there don't work harder before audits — they just kept the receipts all along.