What an automated accessibility check can and can’t tell you

What automated checks are good at

Tools like axe-core (which our free check uses), WAVE and Lighthouse read the page’s structure and compare it against rules derived from WCAG. Where a rule has a clear yes-or-no answer in the code, they’re fast and consistent. Typical examples:

• Missing text alternatives. An image with no alt attribute.
• Unlabeled form fields. An input with no label a screen reader can announce.
• Empty links and buttons. Icon-only controls with no accessible name.
• Low contrast between text and a solid background.
• Missing page language or page title.
• Broken ARIA, such as attributes that point to elements that don’t exist.

These problems are common. WebAIM’s 2026 analysis of the top one million home pages found automatically detectable WCAG failures on 95.9% of them, with low-contrast text on 83.9%.1 Fixing them is worthwhile, and it’s usually the cheapest accessibility work there is.

What they can’t judge

A large share of accessibility depends on meaning and behavior, which software can’t evaluate on its own. A scanner can confirm that an image has alt text, but not that “image1” is a useless description. It can see that a menu exists, but not that pressing Tab gets you stuck inside it. Some examples that need a person:

• Keyboard use. Can every link, menu, button and form be reached and operated without a mouse, in a sensible order, with focus always visible?
• Screen-reader experience. Does the page make sense when it’s read aloud? Are state changes, errors and confirmations announced?
• Quality of text alternatives and link text. Present isn’t the same as useful.
• Forms in use. What happens when someone makes a mistake, runs out of time or uses autofill?
• Pop-ups and dialogs. Does focus move into them, stay there while they’re open, and return afterward?
• Zoom and reflow. At 200% or 400% zoom, does content stay readable without sideways scrolling?
• Contrast over images, gradients and video, which tools often flag as “needs review.”
• Third-party widgets for booking, chat, payments and maps, often inside frames the tool can’t read.

Why a clean scan isn’t proof

A page can pass every automated rule and still be impossible to use with a keyboard. The reverse also happens: a tool flags something that, in context, isn’t a barrier. That’s why automated results are best treated as potential issues until someone checks them, and why we don’t describe scanner output as a list of violations.

How much do automated tests catch? It depends on how you count. Deque, the company behind axe-core, analyzed more than 2,000 audits and found that automated tests identified about 57% of the issues by volume, largely because the most common problems are also the easiest to detect.3 The rest needed a person.

Accessibility tools that promise to make a site compliant automatically deserve skepticism. In 2025 the Federal Trade Commission finalized an order against one overlay vendor over claims that its AI product could make any website WCAG-compliant.2

A sensible way to use both

1. Start with an automated check. It’s quick, free or cheap, and shows you whether the basics are in place.
2. Fix the obvious things. Labels, alt text, contrast and names on icon buttons are often small template changes.
3. Have a person test what matters most. Your key pages and the tasks customers come to do: booking, buying, contacting you.
4. Re-test after changes, and keep a dated record of what was tested.

If you want to see where your site stands, run the free check on one page. For the parts a scanner can’t judge, a full audit adds manual testing.