Someone has asked whether your website meets the accessibility standard, and nobody in the building knows. You can answer most of that question yourself, this week, for nothing.

What you cannot do is answer it the other way. You can establish that your site is not compliant in an afternoon. You cannot establish that it is — not with a free tool, not with a paid one, and not with any afternoon.

I ran the whole free route over my own site in September, so the numbers below are measured rather than illustrative. Everything they found was fixed the same day; I have said where, because the speed of the fix is part of the point.

The free scanners find real failures, and they find them in seconds

Install the axe DevTools extension, or WAVE, or open the Lighthouse tab already sitting in Chrome. All three are free. Run one against your five most important pages: the homepage, your main form, a content page, a listing page, and whatever someone reads just before they call you.

On twenty-three pages of my own site, axe fired on exactly two rules. Zero violations for form labels, alt text, ARIA, names, roles, parsing, focus order or language. One of the two was a Level A failure — the lowest bar the standard has — on sixteen of those twenty-three pages. Inline links in body text were told apart from the surrounding text by colour alone, and the colour was not different enough to carry it: 2.52:1, where the rule asks for 3:1. One CSS rule closed it.

The other was text contrast, and the interesting part is the size of the miss. Two genuine failures: 2.99 against a requirement of 4.5, and 4.44 against a requirement of 4.5.

Look at the second. It misses by six hundredths. Nobody sits down and trades away 0.06 of contrast — that is not a decision anyone made. Both numbers mean the same thing, and it is not that the palette was careless. The palette was chosen carefully and then never measured. The hover states, which nobody thinks about, came back at 5.34 and 9.17. Fine, by accident.

If your brand colours were signed off in a deck, that is probably true of you too. It is also the cheapest category of failure to fix and the easiest to fix permanently.

Then they hand you a score, and the score is where people stop

Lighthouse I ran over five of those pages. It failed on the same two rules as axe and on nothing else — two tools built by different people, agreeing completely on the half that can be automated. Then it rated those pages between 90 and 95 out of 100. The page selling accessibility audits scored 92, with a Level A failure standing on it.

Ninety-two looks like a pass. Lighthouse describes it (opens in a new window) as a weighted average of its accessibility audits, and says plainly that the manual checks it lists do not affect it. It is not a conformance level, it does not map to A, AA or AAA, and nothing in the standard recognises it.

A tool score gets pasted into a board update, an RFP answer or an accessibility statement, and the organization has now published a claim it cannot support.

What no scanner tests, and how I found out

Keyboard focus indicators — the visible ring showing a keyboard user where they are on the page.

Mine was a two-pixel ring three pixels outside each control. On the light background it measured 5.98:1. On the dark footer and the dark call-to-action bands that three-pixel offset painted the ring on the background instead of the control, at 1.88:1, against the 3:1 that WCAG 2.1 sets. WCAG 2.0, the version Ontario names, asks only that the indicator be visible; 2.1's number is what turns visible into something you can measure. Roughly twenty of the forty-four focus stops on a page, including the whole footer navigation.

Neither axe nor Lighthouse has an automated check for focus indicators. Not a weak one. None at all. Deque, which makes axe, ships a guided test that walks a person through the keyboard pass instead. The company that builds the scanner puts a human in the loop for this one.

I found it by sampling the rendered pixels during a keyboard pass. getComputedStyle, the browser's own report of what a style resolves to, returned a different outline than the one that actually painted. The machine-readable answer and the visible answer disagreed.

Everything in that category is invisible to a scanner. Whether alt text is meaningful rather than present. Whether a keyboard user can get back out of a modal. Whether form errors make sense read aloud in order. Whether reading order matches visual order. Every one of those takes a person to judge.

The afternoon that finds what the scanners cannot

Three hours, five pages, scanner closed.

Unplug your mouse. Complete your most important task — the booking, the application, the enquiry — with Tab, Shift+Tab, Enter and the arrow keys alone. If you get stuck, stop looking; that is your top finding.
Watch where you are. Can you see what is focused, on every background? Dark bands are where this dies, and mine is the reason I know.
Open the PDF people download most. Try to select the text. If you cannot, it is a scan of a page, and that is an immediate problem. If you can, it still may not be tagged — and if nobody in the building knows what tagged means, it is not.
Zoom to 400%. One column, or a horizontal scrollbar and clipped text?
Break your own form. Submit it empty. Are the errors attached to the fields they belong to, and do they say what to do rather than what went wrong?
Read the last three pages your team published, not the ones a designer built. Images with no alt text, headings picked for size rather than structure, and "click here" links are made in day-to-day publishing, not in the template. This is the check that finds your actual pattern.

None of it requires a specialist. All of it finds things no scanner reports.

Why I stopped running this by hand

Everything above is a photograph. The site keeps moving, and the failures come back at the speed your team publishes — which is the whole reason a yearly audit disappoints people.

So the checks belong in the machinery instead, and the shape I build is decided by what the free tools got wrong above:

The check the scanner does not have. axe has no opinion on focus indicators, so the first custom assertion I write measures the ring against whatever it actually paints on, per surface. You only know to write that once something has caught you.
Measured on the built page, not the source. getComputedStyle lied to me. Anything that reasons about resolved styles instead of rendered pixels will lie to you the same way.
A baseline, not zero tolerance. A build that fails on every pre-existing issue gets switched off in a week. Record what is already there, fail only on what is new, and burn the list down deliberately.
Grouped by the thing that caused it. Findings arriving per-page produce forty tickets. The same findings arriving per-template produce one.
A quarterly pass by hand anyway. Keyboard and screen reader on the main journeys. Nothing above replaces it, and I would not pretend otherwise.

If your site changes twice a year, you do not need any of this and I will say so. Re-testing against your old findings is the cheaper honest answer.

What to do with what you found

If the afternoon turned up failures, you have your answer. You are not compliant, and you now hold evidence rather than a worry — which is the thing that gets a budget approved.

If it turned up nothing, you have not learned that you are compliant. You have learned that the failures you have are the ones you are not equipped to see.

I run AODA accessibility audits for Ontario organizations — what the law asks of your site, measured, with a fix list in priority order. What that involves and what it costs.