Automated scanners catch roughly a third of WCAG issues. AI-guided checks extend into the majority that needs judgment. A keyboard and screen-reader pass catches what no machine sees. This playbook chains all three into one WCAG-mapped audit — and teaches you what each layer is structurally blind to.
Tier: Core · Workflow area: Accessibility
The output is a findings table mapped to WCAG success criteria, a remediation plan ordered by user impact, and an honest account of which layer found what.
Skip the full chain for a single component — run axe plus a two-minute keyboard check instead.
Layer 1 — automated sweep. Run axe on every distinct page state, not just the landing render: open the modal, expand the menu, trigger the error state, then scan again. Export results. Deduplicate by component — one broken Button primitive can produce forty findings that are one fix. Expect this layer to find contrast failures, missing alt/labels, landmark and heading structure, and ARIA misuse.
Layer 2 — AI-guided interrogation of what scanners skip. Feed the page's rendered HTML (or component source) plus screenshots to a multimodal assistant and direct it at the non-automatable criteria:
Here is the rendered HTML and a screenshot of our checkout step.
Audit ONLY things automated scanners cannot judge:
1. Is the accessible name of each control meaningful out of context?
2. Does the visual reading order match the DOM order?
3. Are error messages programmatically associated with their fields
and specific enough to act on? (WCAG 3.3.1, 3.3.3)
4. Is anything conveyed by color or position alone? (1.4.1, 1.3.3)
5. Are touch targets plausibly under 24x24 CSS px? (2.5.8)
For each finding: element, WCAG criterion, why it fails, suggested fix.
Then have it generate a page-specific manual test script: "Tab from the promo field: focus should land on Apply, and the discount announcement should be heard." Every AI finding is a hypothesis — verify each one against the live page before it enters the findings table.
Layer 3 — manual keyboard and screen-reader pass. Unplug the mouse. Traverse the full flow with Tab/Shift-Tab/Arrow/Enter/Escape: can you reach everything, see focus at all times, escape every trap, operate every widget? Then repeat with the screen reader on, screen dimmed if you can bear it: are announcements meaningful, are state changes (loading, errors, async results) actually spoken, does the dialog announce itself? Use Accessibility Insights' guided assessment to structure this pass and record evidence.
Merge into one WCAG-mapped plan. Consolidate all three layers into the findings table, deduplicate, and rank by user impact (blocks task completion > degrades task > annoyance), not by count. Cluster fixes by component so remediation lands where the code is shared.
Fix, then re-run the failing layer. Every remediation is verified by the layer that found the issue — an axe finding by re-scan, a layer-2 finding by re-inspection, a screen-reader finding by re-listening. Close nothing on "the code looks right now."
Each layer has a blindness: automation cannot judge meaning, AI cannot hear your actual screen reader, and humans cannot scan 400 elements for contrast. The audit is only complete when all three have run and every finding carries its WCAG criterion and the layer that caught it.
For client engagements where screenshots and HTML cannot go to external APIs:
"The AI audited it" is not a compliance defense. Legal exposure under EAA, ADA, and Section 508 attaches to the shipped product regardless of what tool wrote or reviewed the code — only the layered evidence trail defends you.