An accessibility audit is worth buying when you know what it covers. It is worth very little when you do not, because the word covers two completely different things: a scan that a machine can finish in thirty seconds, and an examination that a person has to sit through.
This guide explains what each one actually tests, what neither can test, and how to tell which one you have been sold. We run both on our own work every time we deploy, so the limits described here are ones we have measured rather than read about.
The three layers of a real audit
Layer one: the automated scan. A testing engine — axe-core is the industry standard — walks the rendered page and checks rules it can decide mechanically. Missing alt attributes. Form fields with no label. Duplicate IDs. Buttons with no accessible name. Colour contrast where it can work out both colours. This is fast, cheap, repeatable, and the right thing to run on every single deployment.
Layer two: the measurement the scanner declines to make. This is the layer almost nobody buys, and it is where the interesting failures live. More on it below.
Layer three: the human pass. A person unplugs the mouse and drives the site with the keyboard alone. Turns on a screen reader and listens to the page. Zooms to 200% and 400%. Fills the form in wrongly on purpose to see whether the error message says anything useful. No machine does any of this, and no machine is close.
Layers one and two can and should be automated into your build. Layer three is a person's afternoon, and it is where the real report comes from.
The limit nobody selling a scan puts in the headline
Automated testing finds a minority of real accessibility barriers. That is not a criticism of the tools — they are excellent at what they can decide — it is a statement about what is decidable by machine.
We can put a number on the edge of it from our own work. Our demo sites run a blocking axe-core audit: seven demonstration businesses, every page in each one's navigation, at a 390-pixel phone width and a 1,440-pixel desktop width, plus the accessibility panel open as a separate state — 100 audits in about three and a half minutes.
On a run that reports no detectable A or AA failures, that same audit also reports 1,540 nodes as "needs review".
Those 1,540 are not passes. They are the engine saying I cannot decide this one. Overwhelmingly they are text sitting on something the tool cannot resolve into a single background colour: a gradient, a photograph, a semi-transparent glass panel, a video. The rule gives up and returns "incomplete" rather than guessing — which is correct behaviour, and it is also why "zero violations" is never the same sentence as "zero failures".
If a supplier hands you a clean automated report and calls the site compliant, the 1,540-shaped hole in that claim is what you are paying for.
What we built to cover that hole, and what it found
Because the engine declines to judge those pixels, we measure them ourselves: a probe screenshots the served page, samples the colours actually painted behind every piece of text, and computes the real contrast ratio from the pixels rather than from the CSS.
The first time we pointed it at every template on this website in both the light and dark themes, it returned 308 findings — 306 of them real defects, across 6,502 elements and 48 page renders. Our blocking axe audit had been green on all of it for twenty releases, for two independent reasons: it only ever ran in one of the two themes, and contrast against gradients and photographs is exactly the case it returns as "incomplete".
That is the practical shape of the limit. Two green gates, one real hole, and nothing dishonest happening anywhere — just two tools each doing precisely what it says it does.
The four states an audit forgets to enter
Most audits test one version of a page. There are usually at least four, and a failure that exists in only one of them is still a failure:
- The other theme. If your site has a light and a dark mode, that is two renders of every page. The light one is often the one a low-vision or dyslexic visitor deliberately switches to — and in our case it was the one with 302 of the 308 problems in it.
- The other width. Reflow and tap-target failures only exist on a phone. Some layout failures only exist on a desktop. One width is half a test.
- The states that only exist after a click. A closed dialog is not in the page. Neither is an open mobile menu, an expanded accordion, a validation error, or a cookie banner. Whatever is only reachable by interacting has to be audited in that state, deliberately.
- Keyboard focus. Focus styling is invisible until something is focused. An audit that never presses Tab never sees the focus ring — or its absence.
What a report should tell you
A useful audit report says, in its own words:
- What was measured — which URLs, at which widths, in which themes and states.
- When, and with which engine version. Accessibility results have a date on them; a report without one is folklore.
- What was not measured, and what that leaves open.
- Each finding with the evidence — the element, the measured value, the criterion it fails, and the page it is on. "Low contrast detected" is not a finding; "the service labels on /services measure 2.55∶1 against the tinted band they sit on, where 4.5∶1 is required" is.
- Severity in terms of people, not scores. A site-wide invisible focus ring is worse than one decorative image with a missing alt attribute, however the numbers land.
⛔ And what it should never say is that your site is "compliant". No one issues that certificate. What can honestly be said is: here is what was measured, on this date, at this level, and here is what it found. We hold ourselves to the same sentence.
Doing a useful first pass yourself, for nothing
Before you buy anything, twenty minutes with your own site will tell you most of what an audit would:
- Put the mouse away. Reach every link, button, menu and form field with Tab, and watch whether you can always see where you are.
- Press Ctrl and + until the text is at 200%. Does anything overlap, disappear, or need sideways scrolling?
- Open the site on your phone outdoors. Pale grey text is legible in an office and gone in daylight.
- Fill your contact form in wrongly. Does the error tell you what to do, or just go red?
- Turn on the screen reader you already own — VoiceOver on an iPhone or Mac, Narrator on Windows — and listen to your home page for two minutes.
Anything that annoys you in that test is stopping somebody else completely.
Where Neubor fits
Every deployment of this site and of all seven of our demonstration businesses runs the automated audit and the pixel-level contrast probe, in both themes, and a red result stops the release. We publish what those gates measure — including the times they have caught our own mistakes — because a supplier's accessibility claim is only worth the evidence attached to it.
If you want to know where your own site stands, get in touch. You will get the measurement, the date, and the honest list of what we did not test.
Next: the eight faults we find on almost every small-business website, and what you can fix this week without a rebuild.
Kieran Bourne is the founder of Neubor, a Stoke-on-Trent web development and AI studio. Every number in this guide comes from Neubor's own continuous-integration gates.