How CompliaScan tests websites

Last updated October 9, 2026

CompliaScan loads each page in a real Chromium browser, runs 90 rules from the open-source axe-core 4.11 engine plus 9 checks of our own, and turns the failures into a score from 0 to 100. This page explains what runs, what automated testing cannot catch, how the score is calculated and where the numbers on this site come from.

Run a free scan on your site

What happens during a scan

Load the page like a visitor would. A headless Chromium browser opens the URL at a 1280 by 720 desktop viewport and identifies itself as CompliaScan in its user agent. It waits for the document to finish loading and for stylesheets to apply, because contrast and focus checks only make sense on the styled page. If the page has not finished loading after 20 seconds, the scan continues with what has loaded.
Run axe-core. We inject axe-core 4.11 and run every rule tagged for WCAG 2.0, 2.1 and 2.2 Level A and AA, plus Deque's best-practice rules. Rules axe-core marks as experimental or deprecated are skipped.
Run CompliaScan's own checks. Nine checks cover gaps such as zoom blocking, missing skip links, missing focus styles and small tap targets (listed below).
Run supporting analyses. Each scan also builds a heading outline, a contrast analysis, a color-vision simulation, a screen reader output review and a keyboard focus pass that presses the Tab key through the page, and runs a Lighthouse accessibility audit. Scans from signed-in accounts also check linked PDF files. These analyses help explain and fix issues; they do not change the score.
Sort the results. Confirmed failures are grouped by severity and counted in the score. Results axe-core cannot decide on its own (for example, text over a background image) go to a separate “Needs Manual Review” list and do not affect the score.

The rules each scan runs

Of the 90 axe-core rules we run, 62 are tied to WCAG Level A or AA success criteria and 28 are best-practice rules that go beyond WCAG (for example, every page should have one main landmark). Deque publishes a description of each rule in the axe-core rule list (opens in new tab). These counts are read from the axe-core version installed when this site is built, so they change when we upgrade the engine.

CompliaScan's own checks

Confidence tells you how often a finding needs a second look: high means the code shows the problem directly, low means a person should confirm it.

CompliaScan's own checks: what each looks for, the WCAG criterion it maps to, its severity and confidence
Check	What it looks for	Maps to	Severity	Confidence
`skip-navigation`	No skip link or skip button that lets keyboard users jump past repeated navigation	2.4.1 Bypass Blocks (A)	serious	medium
`viewport-zoom`	A viewport meta tag with maximum-scale=1 or user-scalable=no, which blocks zooming	1.4.4 Resize Text (AA)	critical	high
`no-autoplay-media`	Video or audio elements set to play automatically	1.4.2 Audio Control (A)	serious	high
`text-minimum-size`	Text rendered smaller than 12px	1.4.4 Resize Text (AA)	moderate	medium
`focus-visible-indicator`	Links, buttons and form fields that show no visible change when they receive keyboard focus	2.4.7 Focus Visible (AA)	serious	medium
`new-window-warning`	Links that open a new tab or window without telling the user	W3C technique G201 (advisory)	moderate	high
`target-size-minimum`	Links, buttons and inputs smaller than 24 by 24 CSS pixels (spacing exceptions are not evaluated)	2.5.8 Target Size (Minimum) (AA)	moderate	medium
`interactive-element-semantics`	Click handlers on elements that are not links, buttons or form inputs	4.1.2 Name, Role, Value (A)	moderate	low
`reduced-motion-preference`	Animated elements on a page whose stylesheets never respond to prefers-reduced-motion	2.3.3 Animation from Interactions (AAA)	moderate	low

What automated testing can and cannot check

WCAG 2.2 has 55 success criteria at Level A and AA (4.1.1 Parsing is obsolete and removed). At least one automated rule in our scan maps to 21 of them. The other 34 have no automated rule here and need a person to evaluate them.

Having a rule is not the same as full coverage. The image-alt rule confirms an image has alternative text, but it cannot tell whether that text describes the image. The W3C puts it plainly: “Tools cannot check all accessibility aspects automatically. Human judgement is required.” (W3C WAI, Selecting Web Accessibility Evaluation Tools) (opens in new tab)

Counted by issues rather than criteria, automation does better, because the most common failures are machine-detectable. Deque, which maintains axe-core, analyzed nearly 300,000 issues from first-time audits of more than 13,000 pages and page states and found that 57.38% of them could be found with automated testing (Deque, Automated Accessibility Coverage Report) (opens in new tab).

Criteria with at least one automated rule (21)

WCAG 2.2 Level A and AA criteria with at least one automated rule, and the rules that test each
Success criterion	Level	Rules that test it
1.1.1 Non-text Content	A	7
1.2.2 Captions (Prerecorded)	A	1
1.3.1 Info and Relationships	A	9
1.3.5 Identify Input Purpose	AA	1
1.4.1 Use of Color	A	1
1.4.2 Audio Control	A	2
1.4.3 Contrast (Minimum)	AA	1
1.4.4 Resize Text	AA	3
1.4.12 Text Spacing	AA	1
2.1.1 Keyboard	A	3
2.2.1 Timing Adjustable	A	1
2.2.2 Pause, Stop, Hide	A	2
2.4.1 Bypass Blocks	A	2
2.4.2 Page Titled	A	1
2.4.4 Link Purpose (In Context)	A	2
2.4.7 Focus Visible	AA	1
2.5.8 Target Size (Minimum)	AA	2
3.1.1 Language of Page	A	3
3.1.2 Language of Parts	AA	1
3.3.2 Labels or Instructions	A	1
4.1.2 Name, Role, Value	A	28

Criteria that need a person (34)

Work through these by hand with our WCAG 2.2 checklist and the keyboard and screen reader steps in the accessibility audit guide.

1.2.1 Audio-only and Video-only (Prerecorded) (A)
1.2.3 Audio Description or Media Alternative (Prerecorded) (A)
1.2.4 Captions (Live) (AA)
1.2.5 Audio Description (Prerecorded) (AA)
1.3.2 Meaningful Sequence (A)
1.3.3 Sensory Characteristics (A)
1.3.4 Orientation (AA)
1.4.5 Images of Text (AA)
1.4.10 Reflow (AA)
1.4.11 Non-text Contrast (AA)
1.4.13 Content on Hover or Focus (AA)
2.1.2 No Keyboard Trap (A)
2.1.4 Character Key Shortcuts (A)
2.3.1 Three Flashes or Below Threshold (A)
2.4.3 Focus Order (A)
2.4.5 Multiple Ways (AA)
2.4.6 Headings and Labels (AA)
2.4.11 Focus Not Obscured (Minimum) (AA)
2.5.1 Pointer Gestures (A)
2.5.2 Pointer Cancellation (A)
2.5.3 Label in Name (A)
2.5.4 Motion Actuation (A)
2.5.7 Dragging Movements (AA)
3.2.1 On Focus (A)
3.2.2 On Input (A)
3.2.3 Consistent Navigation (AA)
3.2.4 Consistent Identification (AA)
3.2.6 Consistent Help (A)
3.3.1 Error Identification (A)
3.3.3 Error Suggestion (AA)
3.3.4 Error Prevention (Legal, Financial, Data) (AA)
3.3.7 Redundant Entry (A)
3.3.8 Accessible Authentication (Minimum) (AA)
4.1.3 Status Messages (AA)

How the score is calculated

Every page starts at 100. Each failing rule subtracts points by severity, and the score stops at 0. A rule counts once however many elements fail it: a contrast rule failing on 40 elements costs the same as one failing on a single element.

Points subtracted from the score for each failing rule, by severity
Severity of the failing rule	Points subtracted
critical	10
serious	5
moderate	3
minor	1

Severity comes from axe-core's impact rating for each rule and from our own rating for the nine CompliaScan checks. Example: a page with 1 critical, 2 serious and 3 moderate failing rules scores 100 minus 10, minus 10, minus 9, which is 71 (Needs Improvement).

Score labels

100: Perfect
90 to 99: Good
70 to 89: Needs Improvement
50 to 69: Poor
0 to 49: Critical

Multi-page site scores

On plans that scan many pages, the site score is the average of the page scores, rounded. Pages that fail to load are left out rather than counted as 0, and issue totals are added up across pages. Three pages scoring 93, 81, 100 give a site score of 91. Averaging keeps the score independent of site size, so one weak page lowers it in proportion instead of sinking it.

The score is a way to track progress over time. It is not a WCAG conformance level, and a high score does not mean a site meets the ADA.

Where the numbers on this site come from

We cite the primary source next to every figure we publish and leave out numbers we cannot trace. These are the sources our pages rely on most.

Seyfarth Shaw, ADA Title III blog (March 2026). Seyfarth Shaw counted 3,117 website accessibility lawsuits in federal court in 2025, up 27% from 2,452 in 2024, with per-state counts. Read the Seyfarth Shaw post (opens in new tab)
UsableNet 2025 year-end lawsuit report. A second tracker with its own method: it reports 3,195 federal cases plus 1,919 New York and California state cases for 2025, and the industries sued most often. Read the UsableNet report (PDF) (opens in new tab)
WebAIM Million (February 2026). An annual automated scan of the home pages of the top one million websites: 95.9% had detected WCAG failures, with an average of 56.1 errors per page. Read the WebAIM Million (opens in new tab)
Federal Register 2026-07663. Sets the DOJ Title II web rule compliance dates for state and local governments: April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts. The standard is WCAG 2.1 Level AA. Read the Federal Register notice (opens in new tab)
U.S. Department of Justice web guidance (March 2022). Says the ADA applies to the goods and services businesses offer online, that existing technical standards such as WCAG provide helpful guidance, and that businesses have flexibility in how they comply. Read the DOJ guidance (opens in new tab)
W3C, WCAG 2.2. The success criteria and levels on this page. WCAG 2.2 is also published as the international standard ISO/IEC 40500:2025. Read WCAG 2.2 (opens in new tab)
Our own scan data. The scans-run figure on our home page is a count of completed scans in our database, refreshed hourly and rounded down to the nearest thousand. If the count cannot be read, the page shows a fixed fallback figure instead.

For the lawsuit trend in one place, see our ADA website accessibility lawsuit statistics.

How often we update

Rule counts and coverage on this page: rebuilt from the installed axe-core version on every deploy.
Lawsuit figures: when Seyfarth Shaw or UsableNet publish new annual counts.
Home page failure rates: when WebAIM publishes its annual WebAIM Million report.
Legal dates and requirements: when the Federal Register or the DOJ publishes a change.

Limits you should know about

Scans use one desktop viewport, so mobile-only problems such as content that fails to reflow at narrow widths are not tested.
The scan sees the page as it loads. It does not log in, submit forms or open menus and dialogs, so issues behind those steps are missed.
Content inside embedded frames, such as third-party chat or booking widgets, may not be tested.
Some checks read stylesheets, and stylesheets served from another domain can be unreadable, which is one reason medium and low confidence findings deserve a second look.
Sites with strict bot protection can block the scanner, and slow pages may be scanned partly loaded.
Results are informational. They are not legal advice and not a certification of ADA or WCAG conformance.

Frequently asked questions

Can an automated scan tell me if my website is ADA compliant?

No. A scan finds the failures that code can reveal, which makes it a fast first pass, but the W3C says evaluation tools cannot determine accessibility on their own and human judgment is required. The Department of Justice also has no regulation setting out detailed web standards for businesses; its 2022 guidance calls WCAG helpful guidance. Use the scan to find and fix detectable issues, then review the criteria that need a person.

What does axe-core check?

axe-core is Deque's open-source accessibility rules engine. Its rules test the rendered page for problems such as missing alternative text, low text contrast, form fields without labels, buttons and links without names, invalid ARIA, missing page language and duplicate IDs used by ARIA. CompliaScan runs every axe-core rule tagged for WCAG 2.0, 2.1 and 2.2 Level A and AA, plus Deque's best-practice rules.

Why did my score change when I did not change my site?

Common causes are third-party scripts and embeds (chat widgets, ads, consent banners) that change on their own, content edits by other people, a page that loaded slowly so the scan saw less of it, and rule updates when we upgrade axe-core. Compare the issue lists of the two scans to see which rules appeared or cleared.

Does a score of 100 mean my site is accessible?

It means the scan found no failures in the parts of WCAG that automated rules can test. It is not a conformance claim or a legal opinion. Criteria such as caption quality, meaningful alternative text, logical focus order and clear error messages still need manual review.

Which WCAG version does CompliaScan test against?

Each scan runs the axe-core rules tagged for WCAG 2.0, 2.1 and 2.2 at Level A and AA. According to the W3C, a site that conforms to WCAG 2.2 also conforms to WCAG 2.1, and its working group recommends WCAG 2.2 as the conformance target. Note that the DOJ's Title II rule for state and local government websites names WCAG 2.1 Level AA.