AccessibilityScore.in
Run a free accessibility score

Accessibility guide

Free WCAG Checker: What It Finds and What It Cannot

Paste a public HTTPS URL into AccessibilityScore.in and get an accessibility score, a list of WCAG failures mapped to success criteria, and the elements that caused them. This guide explains what an automated WCAG checker can prove, what it cannot, and how to use the result.

Last reviewed by the HalfAccessible accessibility team

Short Answer

A WCAG checker is an automated tool that tests a web page against the Web Content Accessibility Guidelines and reports failures such as low contrast, missing labels and invalid ARIA. Automated checks find a large share of common issues, but no tool can confirm full WCAG conformance; keyboard, screen reader and expert review are still required.

Key facts

Current standard
WCAG 2.2, a W3C Recommendation since 5 October 2023
Success criteria in WCAG 2.2
86 (55 at Level A and AA, the usual legal and contract target)
Pages with detected failures
95.9% of the top one million home pages (WebAIM Million, 2026)
Most common failure
Low-contrast text, on 83.9% of those home pages
Share of issues automation finds
About 57% of issues by volume in Deque's study of real audits
Engine used here
axe-core plus AccessibilityScore.in rules for focus visibility, target size, names, language and titles
Price
Free for a single public HTTPS page

What does a WCAG checker test?

A WCAG checker loads the rendered page, inspects the DOM, computed styles and accessibility tree, and runs rules that each map to one or more WCAG success criteria. A rule passes or fails only when the answer can be decided from the code.

AccessibilityScore.in runs axe-core in a real Chromium browser after the page has loaded and settled, so content added by JavaScript is tested too. On top of axe-core it runs its own rules for visible focus (2.4.7), target size (2.5.8), accessible names, page language and page title. Typical failures it catches:

  • Text and background colours below the 4.5:1 contrast ratio (1.4.3)
  • Images, buttons and links with no accessible name (1.1.1, 4.1.2, 2.4.4)
  • Form fields with no label (1.3.1, 3.3.2)
  • Invalid or misused ARIA roles, states and properties (4.1.2)
  • Missing page language or page title (3.1.1, 2.4.2)
  • Duplicate IDs referenced by labels and ARIA (1.3.1)

What can an automated WCAG checker not decide?

Many success criteria depend on meaning and behaviour, not markup. A tool can see that an image has alt text, but not whether the text describes the image. It can see a focus style, but not whether focus moves in a logical order through a checkout.

When a check runs but cannot decide, AccessibilityScore.in reports it as Needs review rather than dropping it or calling it a failure. Treat those items as a to-do list for manual testing. These questions always need a person:

  • Whether alt text, link text and headings are meaningful (1.1.1, 2.4.4, 2.4.6)
  • Keyboard operation of whole tasks and the absence of keyboard traps (2.1.1, 2.1.2)
  • Logical focus order and reading order (2.4.3, 1.3.2)
  • Captions and audio description for video (1.2.x)
  • Error identification and suggestions in real form flows (3.3.1, 3.3.3)
  • How a screen reader announces dynamic changes (4.1.3)

How is the accessibility score calculated?

The score starts at 100 and deducts 8 points for each failing rule rated critical, 4 for serious, 2 for moderate and 1 for minor, with a floor of zero. A rule that fails on 40 elements costs the same as one that fails on one element, so the score tracks how many kinds of problem a page has; the affected-element counts show how widespread each one is.

A score of 100 means no automated rule failed. It does not mean the page conforms to WCAG, because the criteria that need human judgment were not tested.

How should you use WCAG checker results?

Use the report as triage. Automated findings are cheap to confirm and usually cheap to fix, and fixing them first stops a manual auditor spending paid hours on missing labels and contrast.

  • Fix critical and serious findings first; they usually block a task outright.
  • Fix at the template or component level so one change clears every page that uses it.
  • Re-scan to confirm the fix, then work through the Needs review items by hand.
  • Test the top user journeys (sign-up, search, checkout, contact) with a keyboard and a screen reader.
  • Before claiming conformance, run a full WCAG 2.2 evaluation such as the W3C WCAG-EM method.

Which WCAG version and level should you test against?

Test against WCAG 2.2 Level AA unless a contract or law names another version. Level AA is the level referenced by most laws and procurement rules, including the EU's EN 301 549 and the US Department of Justice's 2024 ADA Title II rule (which names WCAG 2.1 AA). Because WCAG 2.2 keeps every 2.1 criterion except the obsolete 4.1.1 Parsing, a page that meets 2.2 AA also meets 2.1 AA.

Automated WCAG checker vs manual WCAG audit

AspectAutomated checkerManual audit
SpeedSeconds per pageHours to days per site
CostFree to low costPaid expert time
FindsRepeatable code-level failuresMeaning, behaviour and task-level barriers
Can prove conformanceNoYes, with a defined scope and method
Best used forTriage and regression checks on every releaseConformance claims, VPAT/ACR evidence, legal risk

Common Questions

Is this WCAG checker free?

Yes. Scanning a single public HTTPS page is free and needs no account. Scanning whole websites uses page scan credits, at $10 for 1,000 pages.

Can a WCAG checker prove my site is compliant?

No. A checker can find failures, but it cannot confirm that every success criterion is met. Conformance needs manual evaluation of the criteria that depend on human judgment, such as meaningful alt text and keyboard task flows.

How much of WCAG can automated testing cover?

Deque's study of real audits found automated tests caught about 57% of issues by volume, because common issues like contrast and labels are automatable. Measured by success criteria rather than by volume, far fewer criteria can be fully decided by a tool.

Does the checker test pages behind a login?

No. It tests public HTTPS pages as an anonymous visitor would see them. It does not sign in, submit forms or complete purchases.

Why does my score differ from Lighthouse or WAVE?

Each tool runs a different rule set and scores differently. Lighthouse also uses axe-core but runs a subset of its rules and weights them its own way. Compare the specific failures, not the headline numbers.

What does Needs review mean in the report?

A check ran but could not decide pass or fail from the code alone, for example a colour contrast over a background image. A person needs to look at it. Needs review items do not lower the score.

Which WCAG level should I aim for?

Level AA. It is the level named by most accessibility laws and procurement standards. Level AAA is not required as a whole for any site, because some content cannot meet it.

How often should I run a WCAG check?

On every release that changes templates or components, and at least monthly for content-heavy sites. Regressions usually come from new content and third-party widgets.

Sources

  1. W3C: Web Content Accessibility Guidelines (WCAG) 2.2
  2. W3C WAI: What's New in WCAG 2.2
  3. W3C WAI: WCAG-EM conformance evaluation methodology
  4. WebAIM: The WebAIM Million, 2026 report
  5. Deque: Automated testing coverage study
  6. axe-core on GitHub
Run a free accessibility score
Free WCAG Checker | AccessibilityScore.in