Accessibility Testing Beyond Axe: How to Build a WCAG 2.2 Compliance Pipeline in 2026

Your axe-core scan is green. Your accessibility posture is not.

Here is the uncomfortable number: automated tools like axe detect roughly 30–40% of WCAG success criteria. The other 60–70% — keyboard traps in modals, meaningless link text in context, broken focus order, inaccessible error recovery — ship to production unchecked. And since June 2025, the European Accessibility Act (EAA) makes that a legal liability for any digital product sold in the EU, with enforcement actions ramping up through 2026. WCAG 2.2 added nine new success criteria, and most teams have tested for exactly zero of them.

In a previous post we covered wiring axe-core into GitHub Actions. This is the next layer: turning a single scanner into a full compliance pipeline.

1. Map What Automation Actually Covers

Before adding tools, be honest about coverage. Break WCAG 2.2 Level AA into three buckets:

• Fully automatable: color contrast, missing alt text, duplicate IDs, ARIA attribute validity, form labels. Axe, Lighthouse, and Pa11y handle these well.
• Partially automatable: focus visibility, heading hierarchy, target size (the new 2.2 criterion — 24×24 CSS px minimum), language attributes. Tools flag candidates; humans confirm.
• Manual-only: focus order logic, meaningful sequence, error suggestion quality, consistent help placement (also new in 2.2), dragging alternatives.

That third bucket is where lawsuits come from. Your pipeline must route these to structured manual passes, not ignore them.

2. Layer Component-Level Tests Into CI

Page-level scans catch issues late. Move accessibility assertions down to the component level, where fixes are cheap:

// Playwright component test with axe
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('checkout modal meets WCAG 2.2 AA', async ({ page }) => {
  await page.goto('/checkout');
  await page.getByRole('button', { name: 'Pay now' }).click();

  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag22aa'])
    .analyze();

  expect(results.violations).toEqual([]);
});

Note the wcag22aa tag — most teams enable 2.0/2.1 rules and never turn on the 2.2 criteria (target size, focus not obscured, accessible authentication). That one flag closes a real gap.

3. Automate Keyboard Journeys, Not Just Scans

Static scans cannot tell you whether a user can actually complete a flow with a keyboard. Script the critical journeys:

• Tab order through your top five user flows (signup, checkout, search, settings, support).
• Assert focus is visible and never obscured by sticky headers or cookie banners — a WCAG 2.2 criterion that breaks on a surprising number of marketing sites.
• Assert modals trap focus and return it to the trigger on close.
• Assert no interaction requires dragging or a complex pointer gesture without an alternative.

These run as ordinary Playwright tests — page.keyboard.press('Tab') plus focus assertions — and catch the class of bugs scanners structurally miss.

4. Add the Assistive-Technology and Manual Gate

Once per release cycle, run a structured manual pass:

• Screen reader smoke test: NVDA on Windows, VoiceOver on macOS/iOS. One hour on critical flows catches more real user pain than a thousand automated violations.
• Zoom and reflow: 200% zoom, 320px viewport width, text spacing overrides.
• Cognitive checks from 2.2: accessible authentication (no cognitive function tests like puzzles), redundant entry (don't make users re-type information), consistent help location.

Track findings in the same issue tracker as functional bugs, with severity tied to user impact, not scanner counts.

5. Report Compliance as a Release Signal

Treat accessibility like performance or security: a measured release gate.

• Maintain an accessibility scorecard per flow: automated violations, keyboard journey status, last manual pass date.
• Publish a VPAT/Accessibility Conformance Report if you sell to enterprises or the public sector — procurement teams ask for it, and the EAA gives them leverage.
• Fail the build on new critical violations, but baseline the existing backlog so the gate is achievable from day one. A gate everyone bypasses is worse than no gate.

The pipeline end-state: axe at the component level, keyboard journeys in CI, a scheduled AT/manual pass, and a scorecard that blocks regressions. That is defensible compliance — not a green Lighthouse badge.

Ship Accessible Products Without Building an A11y Team In-House

That is why we built QA::SYNTH. Our engineers run the full accessibility pipeline for you — automated WCAG 2.2 scanning in your CI, scripted keyboard and screen-reader journeys, and structured manual audits mapped to EAA and ADA requirements — as an on-demand service that scales with your release cadence.

👉 Ready to make accessibility a release gate instead of a legal risk? Check out our flexible, productized QA plans on our homepage.