Automated testing finds roughly half of accessibility issues. The rest need a human. Here’s what we found automatically.
That line sits on every report we produce. This page explains what is behind it: how the scan actually works, which failures it can prove, which ones it can only guess at, and which ones it will never see at all.
What the scanner is
Perceva runs axe-core, the open-source accessibility testing engine maintained by Deque Systems. It is the same engine behind axe DevTools and behind a large share of the accessibility testing built into browsers and CI pipelines. We did not write our own rules engine, and we would be suspicious of anyone who claimed to have written a better one in a weekend.
We run it against the WCAG 2.1 Level A and Level AA rule sets — in axe’s terms, the wcag2a, wcag2aa, wcag21a and wcag21aa tag groups. Those are the levels that the ADA-related cases and the European Accessibility Act conversation actually turn on. Level AAA rules are not run: they are a higher bar than any regulation asks for, and reporting them would pad the count with things nobody is being asked to fix.
The mechanics, plainly:
- We load your page in a real Chrome browser, not a HTML parser. Scripts run, styles apply, and the page settles.
- axe-core inspects the rendered DOM — the page as it exists after JavaScript has done its work, which is the page a real visitor gets.
- We take axe’s raw findings and translate them. Every issue we have written up gets a plain-English title, an explanation of who it affects and how, the WCAG success criterion it maps to, and a copy-paste fix.
- Identical failures are grouped. Two hundred images missing alt text is one issue with two hundred locations, not two hundred issues.
That last point is worth dwelling on, because it is where most free scanners become useless. A wall of two hundred repeated rows tells you nothing about what to do first. One row that says “images missing text descriptions — 200 locations” tells you it is a template problem and roughly what an afternoon of work would buy you.
The score is a severity score, not a compliance score
Every report carries an Issue severity score out of 100. It is arithmetic, not judgement:
100 − (critical × 10 + serious × 5 + moderate × 2 + minor × 1)
…counted once per grouped issue, floored at zero. The impact ratings come from axe-core, not from us.
It is a triage number. It tells you how bad the automatically detectable problems on this page are relative to another page you might scan. It is not a rating of whether your site meets a legal standard, and no honest number could be, for the reasons in the next section.
What automated testing genuinely proves
Some accessibility failures are decidable from code. A machine can be certain, and when Perceva reports one of these it is reporting a fact, not an opinion:
- Images with no text alternative. The
<img>element either has analtattribute or it does not. - Text with insufficient colour contrast. The contrast ratio between the computed foreground and background colour is a calculation. WCAG’s thresholds — 4.5:1 for body text, 3:1 for large text — are numbers, and the comparison is exact.
- Form fields with no label. An input with no associated
<label>, noaria-labeland noaria-labelledbyis announced to a screen reader user as bare “edit text”. This is checkable. - Buttons and links with no readable name. An icon-only button with no accessible name announces as “button”. A machine can see that the accessible name computation returns nothing.
- Broken ARIA. Required ARIA attributes missing, ARIA attribute values that are not valid for that attribute,
aria-hiddenwrapped around something focusable, interactive elements nested inside other interactive elements. ARIA has a specification with rules; violations of a specification are machine-checkable. - Document structure basics. No page title, no
langattribute on<html>, an<iframe>with no title, alangvalue that is not a real language tag, list markup with items that are not list items. - Table semantics. Data table headers that reference cells that do not exist, header cells with no data cells to describe.
These are not trivial. They are, empirically, most of what is broken on the web.
The WebAIM Million — an annual automated analysis of the top one million home pages — found detectable WCAG 2 A/AA failures on 95.9% of home pages in its 2026 report, averaging 56.1 detected errors per page.
Six categories accounted for 96% of everything it found: low contrast text (83.9% of pages), missing alternative text for images (53.1%), missing form input labels (51%), empty links (46.3%), empty buttons (30.6%), and a missing document language (13.5%).
Every one of those six is a category Perceva detects. If your site is typical, an automated scan will find real, fixable, user-affecting problems on day one.
What a scan cannot tell you
This is the part most scanners leave out, so we will be specific. These failures are real, they are in scope for WCAG 2.1 A and AA, and no automated tool — ours included — can decide them:
Whether alt text is accurate. A machine can confirm an image has an alt attribute. It cannot confirm the attribute describes the image. alt="image", alt="DSC_0421.jpg", or alt text copied from the paragraph next to it all pass an automated check and all fail a human. The WebAIM Million found that 10.8% of images that had alt text had questionable or repetitive alt text — text that passes the machine check and helps nobody.
Whether the reading order makes sense. Screen readers and keyboard users move through a page in DOM order. CSS can put a visually-first element last in the source. A machine can see the order; it cannot judge whether that order tells a coherent story.
Whether an error message is understandable. WCAG asks that input errors are identified and described to the user. A machine can confirm a message element exists and is associated with the field. It cannot tell whether “Error: invalid input” tells anyone what to do next.
Keyboard traps and custom widgets. A hand-built modal, carousel, date picker or combobox can be perfectly valid HTML, pass every ARIA rule, and still trap focus so that a keyboard user cannot escape it. Actually operating a widget is a human task — you have to tab into it and try to get out.
Whether the visual focus indicator is usable. A machine can see that a focus style exists. It cannot tell you the focus ring is a 1px light-grey outline on a white card that nobody can see.
Whether headings describe their sections. Heading levels are checkable. Whether an <h2> reading “More” describes what follows is not.
Video captions, audio descriptions, and whether the captions are correct. The presence of a track element is checkable. Whether it is accurate, synchronised, and includes speaker identification is not.
Anything that depends on flow. Multi-step checkouts, session timeouts, forms that reset, content that changes after an action. A single-page automated scan sees a snapshot; barriers often live in the transitions.
Anything behind a login, or on a page we did not scan. The free scan is one page. A paid plan covers a site on a schedule, but no crawler sees an authenticated dashboard.
So where does “roughly half” come from?
We say roughly half because that is the honest shape of it, not because we have measured your site.
Deque, which maintains the engine we run, states in the axe-core project README that it finds on average 57% of WCAG issues automatically.
That is the engine maintainer’s own figure and we report it as theirs, not as an independent finding.
Other practitioners put the number lower. The Overlay Fact Sheet, signed by accessibility practitioners and disabled users, is blunter still: it states that full compliance cannot be achieved by automated means.
The range across those sources is wide, the honest summary is “about half”, and anyone quoting you a precise coverage percentage for your specific site is quoting a number they cannot have.
What matters more than the percentage is the shape of the gap. Automated testing is excellent at the failures that repeat across a template and terrible at the failures that require someone to understand your content. That is why the right sequence is: fix what a machine can prove first, because it is cheap and high-volume, then bring in a human for the rest — knowing what the rest actually is.
What Perceva is for
Perceva sits in the gap between doing nothing and paying for a full manual audit before you know whether you need one.
A manual audit by a qualified practitioner is the real thing, and if you have a legal deadline or a complex application you should get one. But most sites do not start there. Most sites start with fifty-six detectable errors per page and no idea which ones matter. Finding and fixing those is a genuine improvement for real users, it is work a developer can do in an afternoon, and it is a documented record that you are working on this.
Then your site changes. A theme update, a new plugin, a client edit, a redesigned checkout — and something you fixed breaks again. That is the argument for monitoring rather than a one-off scan: a single report is accurate for about a week.
Limits of the free scan
So you know exactly what you are getting:
- One page. The URL you enter. Not a crawl.
- A 30 second budget. Pages that never finish loading are reported as a timeout rather than as a clean result.
- Public pages only. We refuse private, internal and local addresses, and anything that is not
httporhttps. - The page as it renders for us, from a US-region server, with no cookie consent accepted and nobody logged in. A page that is substantially different behind a consent banner will scan differently for you.
- Rules we have not written up yet appear in the engine’s own words. We map thirty rules into plain English. When a page trips a rule outside that set, you get axe’s own description, clearly marked as not ours, with a link to its documentation. We would rather admit that than invent an explanation.
Related
- Why we’re not an overlay — what overlay products claim, and what the record shows.
- Do accessibility overlays actually work? — the evidence, with sources.
Sources
- axe-core project — Deque Systems: https://github.com/dequelabs/axe-core
- The WebAIM Million, 2026 report: https://webaim.org/projects/million/
- Overlay Fact Sheet: https://overlayfactsheet.com/en/
Scan a page and see for yourself. No signup. No credit card. First scan free.