Skiplink

What a scan does and does not tell you

Last updated 28 July 2026

Automated testing detects a subset of WCAG success criteria. Published estimates of automated coverage range from roughly 13% to 57%, depending on whether coverage is measured by success criteria or by issue volume. A passing Skiplink scan means no automatically detectable violations were found. It does not mean a site conforms to WCAG, nor that it complies with the ADA, Section 508, the European Accessibility Act, or any other law. Manual testing by a qualified reviewer, including testing with assistive technology, is required for a conformance claim.

That paragraph appears in every scan result, every report, and in the API response body itself. This page explains why we are so insistent about it.

The split

A machine can check

  • Colour contrast ratios against the computed background
  • Missing alt attributes on images
  • Form inputs with no associated label
  • Links and buttons with no accessible name
  • Invalid or contradictory ARIA
  • Missing document language
  • Heading levels that skip
  • Duplicate id attributes

A machine cannot judge

  • Whether alt text actually describes the image
  • Whether focus order matches the visual order
  • Whether an error message is understandable
  • Whether a custom widget behaves as its role promises
  • Whether captions are accurate
  • Whether a page works under a screen reader in practice
  • Whether content is written clearly enough to use

An image with alt="image" passes every automated check and helps nobody. That is the shape of the gap, and no scanner closes it.

Why we will not say "compliant"

In January 2025 the FTC fined accessiBe $1M over claims that its product made websites WCAG compliant, along with undisclosed paid reviews. Separately, roughly a quarter of businesses sued over website accessibility already had an overlay product installed.

The lesson is not subtle: in this market the marketing is the liability. So we do not sell compliance, we do not sell protection from litigation, and we do not put a score on a page without this explanation next to it. We tell you what a machine found, name what it cannot check, and leave the claim to you and your reviewer.

The score

Scans return a score between 0 and 100. It is the share of automated checks that passed, weighted by impact:

score = 100 × passes ÷ (passes + 10·critical + 5·serious + 2·moderate + 1·minor)

The weights trade off linearly and exactly, so ten minor violations cost the same as one critical. That is a property of the formula, not a hidden judgement, and it is why the score is never what fails your build — CI fails on impact level and on new violations, both of which are unambiguous. The score is for humans reading a report.

Engine version

Every result names the exact axe-core and Chromium versions that produced it. Rule engines change between releases, and a result you cannot attribute to a version is a result you cannot reproduce. We pin the engine and tell you which one you got.

Getting the rest of the way

Use automated testing for the floor: it catches the regressions that would otherwise pile up between audits, and it catches them in the pull request where they are cheap to fix. Then have a qualified reviewer test the flows that matter with assistive technology. The two are not substitutes, and anyone selling you the first as the second is selling you something.