Skip to content
wcagc
←Back to blog
scannerbuying guideWCAGEN 301 549procurement

Accessibility scanner buyer's guide: what to look for

A buyer's guide to accessibility scanners: reach behind a login, findings mapped to a named standard, and honesty about what automation misses.

P

Pavel Charkasau

Most accessibility scanners find the same problems. Low contrast text, images with no alternative, form fields with no label: six error types accounted for 96% of everything detected across the million home pages in WebAIM's February 2026 report (WebAIM). A buyer's guide built on rule counts compares tools on the part where they barely differ. The criteria that decide a purchase are narrower. Can the tool reach the views where your barriers live, including the ones behind a login? Do findings map to the standard you are held to, by success criterion and by clause? Does it tell you what it could not check, not only what it checked? Can a developer act on the output without translating it first? Will it leave a dated record a reviewer accepts next year? And will the vendor say plainly what the product cannot decide? The W3C publishes its own selection criteria and they make a sound technical baseline (W3C WAI). No scanner at any price makes a site conformant on its own, so what you are buying is coverage and evidence.

What belongs on an accessibility scanner buyer's checklist?

Eight questions, in the order I would ask them. Each has a verifiable answer, which is the point: a vendor can dodge "does it cover everything" forever, and cannot dodge "show me a scan of a page behind a login".

  • Can it sign in and scan authenticated pages? The W3C names this directly, noting that some tools "can also access password-restricted content" (W3C WAI). Most stop at the login form.
  • Does it crawl a site or check one page at a time? Also from the W3C's criteria: "Some tools check a single page, while others check entire groups of related pages."
  • Which standards and versions does it report against? WCAG 2.1 AA and 2.2 AA are different lists, as are the Revised Section 508 standards and EN 301 549.
  • Does each finding carry the failing element, its selector and a fix, or a severity label and nothing to act on?
  • Does it show what it could not determine, as a separate bucket from what passed?
  • Does it keep a dated history, and does a re-scan produce a diff rather than a fresh unrelated list?
  • Can you export findings into a format a reviewer or a procurement officer will accept?
  • What does the vendor say the product does not catch? Ask it directly and listen to the whole answer.

Note what is missing there: issue counts, scores out of 100, and the number of rules in the engine. Most commercial scanners, ours included, run on axe-core, Deque's open-source rule library, so the rule set is often the same product to product. The differences live in reach, mapping, and what happens after a finding appears.

Which standard should the findings map to?

Whichever one someone will eventually hold you to, named by clause.

WCAG success criteria are the floor and every serious tool maps to them. What sits above that mapping is the real question. If you sell into the EU, the document that matters is EN 301 549, the harmonised standard the EAA leans on, and its Annex C is normative. Annex C sets out a procedure per requirement, each resolving to pass, fail or not applicable, with pre-conditions stated so a test that does not apply gets recorded as such instead of quietly dropped (EN 301 549 Annex C, reproduced by Accessibility Standards Canada). That three-way outcome is the shape a reviewer expects. A tool that only emits violations gives you a third of it.

For US federal work and anything procured against Section 508, the reference is the ICT Testing Baseline for Web, which sets "the minimum tests and evaluation guidance that determine whether Web content meets Section 508 requirements" and is deliberately tool-agnostic: "The Baseline for Web does not identify testing tools" (Section 508 ICT Testing Baseline Portfolio). The baseline covers requirements no scanner evaluates, so a vendor claiming to cover Section 508 is describing a subset of it.

One more mapping question: does the tool implement the W3C's ACT Rules? The implementation reports show "how many ACT Rules different accessibility test tools and methodologies have 'consistently implemented'" (W3C WAI), which is a published, comparable number rather than a marketing one. Our EN 301 549 checklist shows which rows a scan can reach and which need a person.

Can it reach the pages where your barriers live?

This is the criterion that eliminates tools fastest, and you can test it in an hour.

Your homepage is probably the most tested page you own. The barriers that cost you customers sit in the sequences: signup, checkout, password reset, the dashboard someone lands on after logging in. A scanner that cannot authenticate never sees any of that, and the clean report it hands you is clean because it never got there.

Three reach questions, in the order they break purchases:

  1. Authentication. Session cookies, a client-rendered login form, a multi-factor prompt. Configure it yourself during an evaluation rather than watching a sales engineer do it.
  2. Complete processes. A four-step checkout with a broken step three fails as a process even when the other three pages pass. WCAG-EM, the W3C's evaluation methodology, is explicit: "Include all samples that are part of a complete process in the selected sample set" (W3C).
  3. Page limits. Ask how many pages a scan covers on your plan, and what happens to page 501.

The mechanics of checking this before you sign are in our guide to running a scanner trial.

How do you tell an honest coverage claim from a sales one?

By whether the vendor volunteers the number and the limit, or waits for you to ask.

The honest range is public. Deque's analysis of more than 2,000 audits, covering over 13,000 pages and nearly 300,000 issues, found automated testing identified about 57% of accessibility issues when counted by volume of real defects (Deque). Counted by share of success criteria instead, the machine-decidable portion lands closer to 30 to 40%. Both ends are defensible. The W3C states the principle without a percentage: tools "cannot check all accessibility aspects automatically. Human judgement is required" (W3C WAI).

There is a concrete artifact to ask about. axe-core returns results in four buckets, and one is incomplete, described in its API documentation as "also known as 'needs review'", covering results that "were aborted and require further testing" because of technical restrictions on what the rule can test (axe-core API). Ask where those appear in the product. If the answer is that they get filtered out to keep reports tidy, you have learned something useful: the tool hides the exact set of items a human has to look at.

The cost of the other approach is documented. On 22 April 2025 the FTC approved a final order requiring the overlay vendor accessiBe to pay $1 million over claims its accessWidget could make any website WCAG compliant. The order bars the company from representing that its products can make any website WCAG compliant, or ensure continued compliance over time, without supporting evidence (FTC). My own bias, since it shaped what we built: a vendor who will not name the limit in a sales call will not name it in your accessibility statement either, and your company's name is on that document. Our scanner will not tell you whether your checkout works with a screen reader. Budget for the manual pass whichever tool you buy.

Does the output help the person who has to fix it?

A finding is useful when a developer can open the file and change something.

In practice that means the URL, the CSS selector, the failing markup, the success criterion, and a before-and-after snippet. Not a score of 78 out of 100, and not a chart of issues by severity with no way to reach the elements underneath. Scores are the most commonly sold thing in this category and the least useful: they compress a conformance question into a number no auditor recognises.

Two capabilities matter once the first scan is done. Can findings become tickets in the tracker your team already uses, and can a scan run in CI so a regression fails a build instead of surfacing in a quarterly report? Then check the re-scan: fix three things, run it again, and see whether you get a delta or a fresh list.

One hard line, ours rather than a preference: the tool should detect and explain, not inject fixes into your page at runtime. An overlay changes what a visitor's browser receives while your markup stays broken underneath, so the next deploy resets it and the codebase never improves.

What evidence will you need a year from now?

More than a current-state report, if the EAA applies to you.

Article 13 of the EAA requires service providers to explain how the service meets the accessibility requirements, in their general terms and conditions or an equivalent document, and to have procedures so that provision of the service continues to conform (EUR-Lex, Directive (EU) 2019/882). Continues is the load-bearing word. It makes a dated, retained scan history part of the deliverable, alongside a log of what you found and what you did about it.

So ask about retention and export before you buy. How long are scans kept, can you take the history with you if you leave, and can the tool draft an accessibility statement from real findings? Ours does through the statement generator, including the known limitations section, which is the part that has to be honest to be worth anything.

What should make you walk away?

Five signals, any one of which is enough for me:

  • The product fixes accessibility at runtime with a widget instead of reporting what is broken in the code.
  • The marketing promises compliance, or any guarantee about a legal outcome.
  • It cannot scan behind a login, and the roadmap answer is vague.
  • The only deliverable is a score, with no selectors and no export.
  • Nobody will answer "what does this not catch" in one clear sentence.

Frequently asked questions

What is the most important thing to look for in an accessibility scanner?

Reach, then mapping. A tool that scans your authenticated flows and ties each finding to a named success criterion or EN 301 549 clause beats one finding extra contrast errors on pages you had already tested.

Can an accessibility scanner make my site compliant?

No. Automated testing covered about 57% of issues by volume in Deque's analysis, less when measured by share of success criteria, and the W3C is explicit that human judgement is required. A scanner finds a defined subset of problems; conformance needs a person with a keyboard and a screen reader.

Do I need a scanner that supports EN 301 549 specifically?

If you sell into the EU, yes, because that is the standard your accessibility statement and any audit will reference. Look for findings mapped to clauses with the Annex C pass, fail or not applicable outcome rather than a generic WCAG report relabelled for Europe.

Should I choose the tool that reports the most issues?

No. High counts often mean duplicate findings or flags a human would dismiss. Take twenty findings only one tool reported and check them by hand; that tells you more about accuracy than any total.

Check the criteria against your own pages

Use this checklist against a real page instead of a feature table. Pick the most complicated page in your product, run a free scan, and read what comes back: whether each finding names the element and the criterion, whether the items needing human review are visible, and whether you could hand the output to a developer as it is. A minute of that beats a demo.

Pavel Charkasau, founder, wcagc.com. Last updated 20 September 2026.

Sources