Automated accessibility checks are a floor, not a finish line

There is a number on my homepage: 100% of automated accessibility checks passing before a site goes live. I want to be precise about what that means, because “100% accessible” is a claim nobody can honestly make, and the number is easy to read as if it were one.

What the automated checks actually catch

Run an automated audit — axe, Lighthouse, pa11y, they broadly agree — and it will reliably find things like:

• Images with no alt attribute
• Form inputs with no associated label
• Text below the WCAG AA contrast ratio
• Missing document language, or a missing page title
• Buttons and links with no accessible name
• Broken heading order, or ARIA attributes pointing at nothing

These are real defects and they are worth catching. They are also, almost without exception, mechanical. A machine can see them because they are structural facts about the markup, and a machine can therefore verify them on every build.

That is why I hold every site to zero of them. It costs almost nothing once it is wired into the process, and shipping a site with unlabelled form inputs in 2026 is just carelessness.

What they cannot catch

Here is the part that gets left out of the marketing. Automated tooling catches somewhere around a third of WCAG issues. The rest need a person, because they are judgements, not facts:

• alt="chart" passes the check. It tells a screen reader user nothing.
• A visible focus ring can exist and still be invisible against the background it lands on.
• Tab order can be technically valid and still make no sense — a modal that puts focus back at the top of the page behind it will pass every automated rule there is.
• Error messages can be correctly associated with their field and still be incomprehensible.
• A colour-coded status badge with no text label passes contrast checks perfectly and is useless if you can’t distinguish the colours.
• Motion, autoplay, and time limits are all things a tool can spot the mechanism of but not the impact.

Every one of those is a real barrier for a real person, and every one of them would sit quietly behind a clean audit report.

So what do I actually do

Automated checks run before launch, and they have to be clean. That is the floor.

On top of that, on every build: keyboard-only navigation of each page, checking that focus is always visible and always somewhere sensible. Screen reader passes over the pages that matter most — usually the contact form and any interactive component. Reading the alt text I’ve written and asking whether it would be any use to someone who cannot see the image. Checking the site at 200% zoom and at narrow widths, because reflow is where a lot of real-world usage lives.

That is not a certification, and I am not going to pretend it is. There is no substitute for testing with disabled users, and for most small business budgets that is not on the table. Saying so is more useful than implying otherwise.

Why the wording on the stat matters

The homepage used to say “100% accessibility checks passed”, which is ambiguous in a way that flatters me. Passed on what? Every site? This one? Which checks?

It now says automated accessibility checks passing before a site goes live, because that is a claim I can defend if you challenge it. The number is the same. The sentence is honest about what the number is.

If a supplier tells you a site is “fully accessible” or “100% WCAG compliant”, ask them which checks, run by what, and what they did by hand. The answer will tell you a lot.