A page can score 100 and still fail a blind user

If you've never run axe-core, WAVE or Lighthouse against your own site, do it today. This page is not an argument against rule-based scanning. It explains what it can and cannot see, so you know what a passing score actually tells you.

What rule engines are genuinely good at

A rule-based scanner walks the rendered DOM and checks it against a fixed set of assertions: does this image have an alt attribute, does this button have an accessible name, does this page declare a lang, is there exactly one <h1>. Each assertion is either true or false. There's no judgment involved, which is precisely why these tools are valuable:

• Fast. Thousands of DOM nodes checked in milliseconds, not the minutes a human audit takes per page.
• Free or near-free to run at scale. No per-check cost, so nothing stops you scanning every page, every commit.
• Deterministic. The same page produces the same result every time. You can wire it into CI and trust the diff.
• They catch real, common bugs. Missing form labels, duplicate IDs, empty links, missing page titles. These break screen readers and keyboard navigation outright, and rule engines find them reliably.

This is why axe-core, free and open source under the MPL-2.0 licence, sits underneath a large share of the commercial accessibility-testing market. Building your own DOM-assertion engine from scratch is pointless when a well-maintained free one already exists; it's also why so many "AI accessibility scanner" products can offer unlimited free scans. The underlying check costs them almost nothing to run.

The structural limit

Here's the part that doesn't change no matter how many rules you add: a rule engine evaluates the DOM against assertions about structure. It can verify that an attribute exists, that it is non-empty, that it doesn't match a known bad pattern like a filename. It cannot verify that the attribute's content is correct for the thing it's attached to, because "correct" requires understanding what's actually on the page, and a DOM walker has no eyes.

An alt attribute that reads "A golden retriever running on a beach" passes every structural check a scanner runs. It passes whether or not the image next to it shows a dog, a beach, a completely different product photo, or a stock-photo warning banner. The scanner isn't being sloppy: checking that would require downloading the image and looking at it, which is outside what DOM assertions can do.

Four ways a page scores 100 and still fails someone

In all four cases, every rule-based check a scanner runs returns green. The page would report as fully passing. Someone using it still can't complete the task.

How much of WCAG this actually covers

There's no single agreed number here, and anyone quoting one precisely is rounding more than the evidence supports. The most cited figure comes from accessibility consultant Karl Groves, who put it this way: automated tools "can definitively test for approximately 25–29% of best practices for WCAG 2.0" and "cannot test for approximately 40%" at all. The rest falls into a grey zone that needs a human judgment call either way. (source)

Other sources land in similar territory without matching exactly, which is why we won't hand you a single decimal-point figure and call it settled. The defensible summary is that roughly a third of WCAG success criteria is reliably machine-checkable, not an exact percentage. The WebAIM Million is the standard reference for how that plays out on real sites: even the errors automated tools can detect are still present on the overwhelming majority of home pages tested, so passing more checks is worth doing regardless of the ceiling.

Where GotAlt fits

GotAlt's free scan is a rule-based check. It runs 16 checks across up to three pages, covering the DOM-assertion territory described above: missing alt attributes, placeholder-style alt text, page language, page title, link and button accessible names, form field labels, heading structure, iframe titles, zoom settings, positive tabindex, duplicate IDs, aria-hidden on focusable elements, timed meta refresh, autoplaying media. It's fast and free because that's what this class of check costs to run, and you should absolutely run it.

The deep audit sits on top of that, not instead of it. It downloads each image on a page and asks a vision model whether the alt text is actually true of what's in the picture, the specific gap the four examples above illustrate for alt text. That work is done image by image, page by page, which is why the audit is metered on the free tier and priced by page on paid plans rather than offered as unlimited scanning. If a product claims to verify alt text at unlimited volume, ask whether it opens the images at all.

To be precise about what's genuinely new here: some competitors do more than presence-checking already. Sitechecker flags alt text it considers "insufficient", AudioEye states it scans for "missing or incorrect alt text", and headingchecker.dev already does AI-based semantic analysis of heading quality, so we're not the only tool with any judgment layer at all. Most significantly, Deque ships an image-informative-has-alt rule in axe DevTools Pro that puts image content through a vision model, and a text-contrast rule that does the same for contrast, a check our architecture cannot do at all. Their image rule uses AI to work out whether a picture is informative and then checks that alt text is present. What we haven't found elsewhere is a tool that fetches the actual image file and asks whether the alt text already there is true of it. That's the specific, narrow claim we're making, not a broader one about being the only tool that thinks.

You may not need us

If what you actually need is thorough presence-checking (catching missing labels, broken landmarks, contrast failures, keyboard traps) across a whole site, for free, excellent free tools already do this well and GotAlt's rule scan doesn't try to out-feature them:

• WAVE, from WebAIM, runs in-browser, visually overlays errors and warnings directly on your rendered page, and checks contrast because it has the rendered CSS to check it against. Free, no signup.
• axe DevTools: the browser extension built on the same axe-core engine described above, running directly against your live, rendered DOM rather than a fetched copy of the HTML.
• Silktide's free browser toolbar: over 200 checks, plus a screen reader simulator and disability simulations, at no cost. If you want to see roughly what a screen reader user experiences without installing one, this is the fastest way.

Run one of those first. If it comes back clean and you're wondering whether "clean" really means what it sounds like (whether your alt text says something true, your link text tells people where they're going, your headings mean something), that's the question a rule engine structurally cannot answer, and it's the one GotAlt exists to answer.