What accessibility scans catch, and what they don't

How I run an audit

Work — Triomics

• Playwright walks every page and every form of the product, and axe-core scans each view against WCAG 2.0, 2.1, and 2.2 A/AA rules plus best practices.
• Around 25 custom checks cover what axe can't: keyboard navigation and keyboard traps, focus order, focus not obscured (2.4.11), on-focus and on-input behavior, text resize and text spacing, non-text contrast, use of color, content on hover or focus, reading order, language of parts, link purpose, multiple ways, pointer cancellation, dragging movements, accessible authentication (3.3.8), and status messages.
• Findings are grouped by WCAG guideline and impact (critical, serious, moderate, minor) and roll up into VPAT-style conformance reports.
• A mandatory accessibility checklist gates every new feature before production, and a monthly review covers everything shipped — up from twice-yearly reporting.

Where automated scans stop

• axe-core automates only one rule specific to WCAG 2.2 (target size). The rest of 2.2's new criteria need custom checks or a human.
• A scan can confirm alt text exists, not that it's meaningful; that a label is present, not that it makes sense; that focus is visible, not that the order is logical.
• Some heuristics are low-confidence and produce false positives. Each one needs a human call before it becomes a ticket.
• Some criteria — error prevention (3.3.4) and redundant entry (3.3.7) — are tested by hand on purpose, because automating them would change shared QA data.
• Media, timing, and gesture criteria are checked manually.

What manual and exploratory testing add

• Keyboard-only passes through critical journeys, end to end, the way a keyboard user actually moves through the product.
• Exploratory sessions on new features, where the question is "can someone actually complete this?" rather than "does it pass a rule?"
• A manual review checklist for everything a rule engine can't judge: meaning, context, and whether the experience makes sense.

Risk-based: what gets audited first

• New features, before production — that's the checkpoint where a fix is cheapest.
• Forms and sign-in get their own dedicated audit alongside the all-pages audit, because that's where an accessibility blocker stops a user outright.
• Everything shipped in the month, in the monthly review — so nothing waits half a year to be looked at.

On this site

Public project

• Every push runs an axe-core audit of every page and a Lighthouse accessibility gate that fails the build below 95.
• Full keyboard navigation, a skip link, verified contrast in both themes, and a written accessibility statement.