What automated accessibility scanners can and cannot find

What scanners are good at

A scanner reads the page code and the rendered result and applies rules that can be answered yes or no. Typical findings:

• Images with no alt attribute.
• Text whose color contrast falls below the WCAG ratio.
• Form fields with no associated label.
• Buttons and links with no accessible name.
• A missing page language or page title.
• Invalid or misused ARIA attributes.
• Duplicate IDs that break label connections, and skipped heading levels.

What needs a person

What the DOJ says

The Department of Justice's web accessibility guidance treats automated checkers as helpful but limited: it says they can be useful tools that need to be used carefully, and it points out that a clean report does not mean a site is accessible. It recommends combining them with a manual review. Read the guidance.

How Clir turns findings into fixes

Clir keeps three kinds of result apart. Confirmed WCAG findings are issues an automated check established. Best practices are recommendations without a WCAG mapping. Items that need review are questions a person has to answer, and they are never presented as failures. Every report states what it did not test. The methodology page defines each, with benchmark results and their limits.

A criterion-by-criterion view

Automated tools cannot judge meaning, so they split the WCAG criteria into three rough groups. The table gives examples from each group.

This is why you will often read that automated testing finds "about a third" or "up to half" of issues. The exact figure depends on how issues are counted and which site is tested. What matters is the direction: automation is the start, not the finish.

Where hands-on testing adds the most

• An image of a red shoe with the alternative text "image". The tool sees alt text; a person sees it is useless.
• A button labelled "Click here" in the code. A tool sees a name; a screen reader user hears the same words on every button.
• A form where the visible label is "Phone" but the code label says "Email". The field has a label, so a scan passes it, but it describes the wrong thing.
• A popup that opens and takes focus but cannot be closed with the keyboard. The code is valid; the experience is broken.
• A page that is read in a confusing order because the layout was built with positioning, not structure.

Examples a scan flags that a person might accept

Scanners also produce false alarms, though good ones keep them rare. A tool may flag a decorative image with empty alternative text as an issue when empty alt text is the correct choice, or report low contrast on text that is part of a logo, which is exempt. When a tool says "needs review", it is telling you it cannot be sure. Look at the element and decide.

Where scanning fits in a process

1. While building: run a scan on every new template, so problems are caught in a week and not in a year.
2. Before launch: scan the key pages and complete a keyboard, zoom and screen reader check.
3. After launch: rescan on a schedule and after major changes, and keep a record.
4. For legal or procurement needs: add a manual evaluation, written up with pages, methods and dates.

If you are comparing options, see free accessibility checkers compared. For a first manual pass, follow how to check if a website is accessible.

How scanners work, briefly

A scanner loads a page in a browser, reads the structure of the page and the styles applied to it, and then runs a set of rules against what it found. Each rule asks a narrow question, for example: does every image have an alt attribute, does every form field have a label, is the contrast between this text color and its background at least 4.5 to 1. If the answer is no, the tool reports an issue.

That approach is fast and repeatable, but it only works for questions that have a yes or no answer in the code. Anything that depends on interpretation, such as whether a description is good or a sequence is logical, is outside the tool's reach.

Why the same page can score differently

• Tools use different rules and version them differently.
• Some tools wait for the page to finish loading scripts; others read it earlier.
• Some report "needs review" items as issues, and others hide them.
• Counting methods differ: a tool may count one issue per element or one per type.

For this reason it is better to track the same tool over time than to compare scores between tools.

Accessibility problems that are easy for a scanner to find

Accessibility problems that need a person

A fair way to talk about scanners with clients or colleagues

If you work with clients, set expectations early. A scan is a quick, useful baseline that finds a share of the issues. It is not an audit, it does not certify anything, and it cannot say whether a site meets a law. A clear way to put it: "The scan tells us where to look first. Then we test the important journeys by hand and keep a record of what we find and fix."

That framing is accurate and avoids the problem of overpromising. It also fits with how regulators describe testing. For example, federal guidance on web accessibility for government treats automated tools as one part of an evaluation, with manual testing needed alongside it.

Reading a scan result critically

Every scanner result benefits from a few questions. Asking them takes a minute and prevents wasted effort.

1. Is it a real issue? Open the page and look at the element. Occasionally a tool flags something that is fine in context.
2. How many people does it affect? An empty button in the checkout affects more people than a missing label on an old blog comment form.
3. Is it a template problem or a one-off? Fixing the template can remove the issue from hundreds of pages.
4. What did the tool not test? Look for a list of limits, and think about what that leaves for a person to check.
5. Is the fix simple? Many issues take minutes; mark those for immediate action.

What the standards bodies say

The W3C's guidance on choosing evaluation tools says tools can help but cannot determine accessibility on their own, and that manual evaluation is needed. The U.S. Department of Justice's web guidance makes the same point about automated checkers. Government testing programs for Section 508 combine automated checks with manual steps. See Section 508 website requirements for how that works in practice.

Building a repeatable testing routine

A routine like this is more convincing to a customer, a regulator or a court than a single large audit, because it shows continuing attention.

Choosing between a scanner, a plugin and a person

Each has a role. A scanner finds the detectable issues across many pages quickly. A plugin or widget may offer visitors some display controls, but it does not fix the page. A person tests the experience, interprets the standard and explains what to change. When budgets are tight, the best sequence is usually scanner first, then manual checks on the most important journeys, then a specialist if the site is large, high-risk or subject to a contract or law.

Why scanners still matter

None of this is an argument against scanning. A scanner can look at hundreds of pages in the time it takes a person to review one, and it applies the same rules every time. That makes it the best way to spot repeat problems, to catch a regression after a release and to give a team an objective list to work through. The mistake is not using a scanner; it is treating the result as the whole story.

Routine automated accessibility testing before each release is the cheapest way to catch the problems a scanner can see, which leaves your manual time for the rest.

A sensible testing mix

1. Scan key pages and templates with an automated tool.
2. Fix the confirmed findings, starting with ones that block a task.
3. Test the same flows by keyboard, with zoom and with a screen reader (how to).
4. Have a specialist review high-risk flows such as checkout, sign-up and anything custom, especially if you face a legal claim or a government contract.
5. Recheck after changes and keep dated records.