A team adds an automated accessibility linter to CI. It reports zero violations on every page. Which statement best describes what they now know?

What is gained

Automated accessibility checking is genuinely worth having, and it is cheap. It reliably catches the mechanical failures that make up a large share of reported issues: missing alt attributes, form inputs with no associated label, insufficient colour contrast, missing document language, duplicate element IDs, invalid ARIA attribute values, and controls that cannot receive keyboard focus. These are structural properties of the markup, they are unambiguous, and a machine checks them perfectly every build at near-zero cost.

Running it in CI also stops regressions, which matters more than the initial sweep: the hard part of accessibility is not fixing a page once, it is keeping it fixed across 200 subsequent changes.

What is paid, and the thing the zero means

Widely cited industry estimates put the proportion of WCAG success criteria that can be evaluated automatically at roughly a third, with tool vendors' own documentation typically claiming detection of something like 30–57% of issues in practice depending on the page. So a clean report means the mechanical third passed. It says nothing about the rest.

What a machine structurally cannot judge:

• Whether alt text is correct. alt="image" passes every linter and is useless. The attribute's presence is checkable; its meaning is not.
• Whether the focus order is logical. A machine sees that every control is reachable. Whether tabbing moves through the form in an order that makes sense requires knowing what the form means.
• Whether an error message is understandable and whether it is announced to a screen reader at the right moment.
• Whether a custom component behaves like the control it imitates. A div with role="button" and correct ARIA passes validation and may still not respond to the space bar.
• Whether the page is usable at 200% zoom, or with a screen reader, by an actual person. This is the only test that answers the real question.

Why the other options fail

• "The pages conform and no further testing is needed." The conclusion teams act on, and the reason automated tooling can make accessibility worse: a green check creates documented confidence that displaces the manual testing that would find the real barriers.
• "Tools detect all issues but cannot judge severity." Inverts the limitation. Severity ranking is something tools do reasonably well; detection is where they are fundamentally limited, because most criteria require judgement about meaning.
• "It only checks colour contrast and needs plugins." Understates them. Mainstream linters check dozens of rule types out of the box, and dismissing them leads to skipping the cheapest, highest-frequency wins.

When not to rely on it

For a regression gate on a mature, previously audited product, it mostly is. If a manual audit has been done, the custom components have been validated with a screen reader, and the question is only "did this sprint break something", the linter answers it well and a full manual pass every sprint is not a good use of money.

It is never enough before the first manual audit, and the sequencing is the practical rule: run the linter in CI from day one because it is cheap, do a keyboard-only and screen-reader pass on each new interaction pattern as it is built, and commission a full audit at the point the product is relied on. The linter's job is to hold the line between audits, not to replace them — and a team that understands that will not read a zero as a conformance claim.