Automated accessibility testing is not a complete answer. The usual estimate is that axe-family engines mechanically detect thirty to fifty percent of real problems; the rest only surface under human eyes and hands. Even so, putting them in CI has paid for itself.
What automation is good at
Problems that reduce to rules — contrast ratios, missing alt text, duplicated landmarks, unlabeled form controls — are found faster and more reliably by a machine. Contrast especially suits CI as regression detection: change one color token and the effect ripples across many pages at once.
Making it operable
- Check representative template pages only (home, article, search) rather than crawling everything
- The passing condition is “zero new violations”; known deferrals live in an explicit allowlist
- Never silently ignore a false positive — allowlist it with a reason comment
What stays with humans
Keyboard traversal order, how naturally a screen reader narrates the page, and layout under zoom are not automated here. They live on a separate pre-release checklist, deliberately kept apart from CI green.
Takeaway
Treat automated checks not as proof of accessibility but as an early-warning device for obvious regressions. Once the team shares that framing, nobody over-trusts a green build either.