WCAG Checker: What the Free Tools Catch and What They Miss

I built a WCAG checker. It gives my own homepage 71 out of 100.

That was the result on 6 November 2026: six buttons and links a screen reader can't name, and nine pieces of text with too little contrast. The old version of this site also scored 71, back when I took the screenshots further down. The code and the design have both changed since. The number hasn't.

I'm leaving that in because it shows what a WCAG checker gives you: a short list of real bugs, plus a score that tells you very little. This post used to be a sales page for my tool, and it still picked up searches for "wcag checker". So this version answers the search.

What a WCAG checker can and can't see

WCAG 2.2 has 55 success criteria at levels A and AA, the two levels laws usually point at. A checker reads your code and rendered styles, so it handles the questions a machine can decide. Does this image have an alt attribute? Does this button have a name? Is this text above a 4.5:1 contrast ratio? Does the page declare a language?

It can't tell you whether the alt text describes the picture or whether the tab order makes sense. An image with alt="image" passes.

Deque, the company behind axe-core, says its engine finds on average 57% of WCAG issues. That's the vendor's own number, counted by volume of issues rather than by criteria, so treat it as the optimistic end. The W3C says it more flatly: tools "can not determine accessibility, they can only assist in doing so."

My favorite proof is from 2019, when developer Manuel Matuzović built a page with a perfect Lighthouse accessibility score that was close to unusable. He blocked keyboard input, removed the cursor, disabled clicks, and shrank the text to 1px at near-zero opacity. Score: 100.

The bugs a checker does find are still worth fixing, because they're everywhere. WebAIM's 2026 scan of the top million home pages detected WCAG failures on 95.9% of them, with 56.1 errors per page on average. Low-contrast text showed up on 83.9%, missing alt text on 53.1%, links with no text on 46.3%, buttons with no text on 30.6%. Three of those four are exactly what failed on my homepage.

The "WCAG 2.2" label is thinner than it sounds

WCAG 2.2 added six new criteria at levels A and AA: Focus Not Obscured, Dragging Movements, Target Size, Consistent Help, Redundant Entry and Accessible Authentication.

axe-core 4.14 has exactly one rule for those six: target-size. In axe-core itself it's switched off by default. Lighthouse weights its accessibility score on axe, and every audit my checker returns is a standard Lighthouse audit, target-size included.

So a "WCAG 2.2 checker" built on axe is a WCAG 2.1 checker with one extra rule. That goes for mine too, and its homepage says WCAG 2.2 in large letters. The other five need a person: does your sticky header cover the focused element, can someone use your slider without dragging, does your form make people type the same address twice, is the help link in the same place on every page.

The free WCAG checkers worth your time

These are the ones I'd point you to, and the entry version of each costs nothing:

• Lighthouse is already in Chrome DevTools. Open the Lighthouse tab, tick Accessibility, run it. It's the quickest way to get the axe rules on any page your browser can reach, staging included.
• WAVE draws its findings onto the page itself, which makes it the friendliest for non-developers. The extension checks the rendered page, so it also works behind a login.
• axe DevTools gives you the same engine with more detail per finding. The free extension is automated only and tests one page at a time.
• Accessibility Insights is Microsoft's open source option. FastPass takes under five minutes, and the tool can also assess a site for WCAG 2.1 AA coverage.
• Pa11y is for developers. Pa11y CI tests a list of pages inside your pipeline, so a regression fails the build.

For a single color pair, WebAIM's contrast checker is faster than all of them. The W3C tools list has the rest.

I built barrierefreiheitcheck.de as a side project, and it runs the same rules as Lighthouse, so a developer with DevTools open gains nothing from it. It helps the person who will never open DevTools: paste a URL and get a German report without installing anything, about nine seconds for my homepage. It's free for one URL at a time. Multi-page scans sit behind a waitlist and PDF checking is marked as coming soon.

The screenshots in this post come from an early version of the tool. The layout has changed since, but findings still arrive this way, each with its HTML snippet and measured value. Read its BITV 2.0 and EN 301 549 sub-scores as sorting buckets rather than conformity verdicts. A contrast failure gets filed under BITV, and it's the same failure under all of them.

Four checks no tool does for you

My scan listed 51 items under "manual review". Ten of those are checks Lighthouse hands back to a human, like tab order and focus traps. The rest are rules that had nothing to test on that page, which is a labeling problem in my tool.

A passed list like this one only covers what was tested. These four cover a good part of what wasn't, and you can do them today:

1. Keyboard. Put the mouse away and press Tab through the page. You should always see where you are, reach every control, open the menu, and close a modal with Esc.
2. Zoom. Set browser zoom to 200%, then 400%. Text must stay readable, and at 400% the page should reflow without sideways scrolling.
3. Screen reader. NVDA is free on Windows, VoiceOver is built into every Mac. Listen to your headings and one form. You'll hear the problems within minutes.
4. Forms. Submit one empty. The error should appear as text, sit next to the field, and tell people what to do.

The W3C's Easy Checks go further and are still explicit that a page can pass them and have significant barriers. If your form uses a CAPTCHA, add it to the test, because some CAPTCHAs have their own WCAG problem.

A clean report doesn't settle the legal question

The European Accessibility Act has applied since 28 June 2025. Germany's version is the BFSG. It targets consumer services, so pure B2B offers and purely informational sites are generally outside it, though a contact form is a gray area commentators disagree on. Service businesses with fewer than ten people and no more than €2 million in turnover or balance sheet total are exempt. Non-conforming services risk fines of up to €100,000.

Enforcement so far looks slow. The German market surveillance body in Magdeburg has been running since September 2025, but a law firm review dated 27 August 2026 found no publicly documented fines and no published court decision on BFSG violations. Warning letters of around €2,700 are reported, and whether competitors can even bring those claims is unresolved.

Which WCAG version counts is messier than the marketing suggests. EN 301 549 V4.1.1, published in September 2026, moves Europe's standard to WCAG 2.2. The Commission hasn't cited it in the Official Journal yet, so the reference is still V3.2.1, built on WCAG 2.1 AA. Build for 2.2 anyway, since that's where this is heading.

In the US, state and local governments have WCAG 2.1 AA as the rule, with compliance dates moved to April 2027 and April 2028 depending on population. Private businesses get sued instead: 3,117 federal website accessibility lawsuits in 2025, up 27% on 2024.

An accessibility widget won't shortcut any of this. In April 2025 the FTC ordered accessiBe to pay $1 million over claims that its plugin could make any website WCAG compliant.

I'm a developer, so if real money depends on the answer, ask a lawyer.

What to do with your results

Start with everything the checker flags. These are cheap fixes, and my 15 elements are a few attributes and color values. Then run the four manual checks on your templates rather than every URL: homepage, a service or product page, your main form, your checkout. One fix in a template fixes every page built on it, and a relaunch is the cheapest moment to do it.

If you sell to consumers in the EU, or a lawsuit would hurt, pay for a human audit against a method like WCAG-EM. In Germany the BIK BITV-Test is the name you'll keep running into.

There's a side benefit I wrote about in what happens when an AI agent fills out your contact form: clean labels and clear focus help agents the same way they help screen readers. Accessible markup is also part of what separates professional web design from a nice-looking template.

A scan can't make your site compliant, and neither can I in an afternoon. What I can do is fix what the scan finds and go through the rest with you. Let's talk if that sounds useful.