Testing & Scanners

Accessibility Checker: How to Pick a Scanner

Last updated May 25, 2026

An accessibility checker(often called a scanner or WCAG scanner) is a tool that runs a set of rules against your rendered HTML and accessibility tree, then reports the rules that failed. Some checkers stop there. Others add a crawler, a remediation engine, regression detection, an accessibility-statement generator, and authenticated-page support. The category is wider than it looks, and the names you hear most (axe, WAVE, Lighthouse, Silktide, SweepHound) sit at very different points on it. This page is a buyer's guide, not a competitive review — it covers the comparison axes that actually decide whether a checker will move the needle for your team.

Before anything else, the honest caveat: no automated checker catches every WCAG issue, and no vendor that tells you otherwise is being straight with you. Per Deque's Automated Accessibility Coverage Report, Deque reported automated tests identified 57.38% of issue instances by volume in its dataset, based on 2,000+ audits across 13,000+ pages and roughly 300K issues. That is a dataset-specific volume measure, not a clean automated-vs-manual split. Manual review is still required for judgment-dependent issues — meaningful alt text, keyboard usability, screen-reader experience, focus order — regardless of how the scan looks. Picking a checker is really about picking the deterministic floor and the manual-review scaffolding you get on top of it. For the full directory of checkers worth knowing, the W3C Web Accessibility Evaluation Tools List is the comprehensive starting point.

What an accessibility checker actually does

Under the hood, a modern checker loads the page in a real browser, waits for JavaScript to settle, then runs a rule engine — typically axe-core, IBM Equal Access Checker, or a vendor-specific ruleset — against the rendered DOM and computed styles. Each rule maps to one or more WCAG success criteria; failures become findings. The good checkers also give each finding enough context (selector, code snippet, severity, the WCAG rule it maps to) for a developer to act on it. The great checkers add a remediation suggestion, group duplicates so one root cause does not produce 400 tickets, and re-scan on a schedule. For a primer on how rules map to WCAG criteria, see the wider guide.

Two things a checker does notdo: tell you whether your site is “WCAG-compliant” (that is a legal determination requiring manual review against every applicable success criterion), and replicate the experience of assistive-tech users. Treat the scanner's output as a triage queue, not a verdict.

The 8 things that actually matter when comparing scanners

Marketing pages will tell you about “AI” and “coverage.” The axes below are the ones that show up in real procurement conversations once teams have used a checker for a quarter and know what they wish they had asked first.

• Rule engine. axe-core is the most-deployed engine and the implicit baseline; IBM Equal Access is the strongest second engine and is particularly opinionated on ARIA patterns and table semantics. A few vendors ship a custom ruleset. Running two engines and deduping the overlap is meaningfully better than one alone because each engine has different blind spots.
• Crawl depth.Single-page (paste a URL), sitemap-driven, BFS link discovery, JS-rendered SPA support, and authenticated crawls are all different products in disguise. Most violations live in the long tail of templates and content pages, so single-page scanning will systematically undercount your site's real defect load.
• Remediation output. Does the tool just flag the violation, or does it generate a concrete before/after code fix? Deterministic fixes (mechanical transformations like adding alt="" or correcting a label association) are safe to ship; LLM-only fixes need review. Per-violation guidance beats an aggregate score every time when you actually have to fix things.
• Manual-review handling. Does the tool acknowledge the judgment-dependent issues automation cannot evaluate, and produce a finite checklist (keyboard pass, screen-reader smoke test, focus order, reading order) for the human work? Checkers that ship a green badge after a single automated scan are quietly selling false confidence.
• Exports. PDF for stakeholders, CSV for ticket systems, sharable HTML report URLs for clients, JSON for CI integrations. Audit and procurement teams will ask for at least one of these on day one. The absence of a clean export is a tell that the tool is built for individual developers, not organisations.
• Monitoring and scheduled re-scans. Accessibility regresses the moment a content editor pastes a new image or a developer ships a new component. Recurring scans on a custom schedule, plus regression detection between runs, turn the tool from a one-shot snapshot into a living signal.
• Authentication support. Can the checker scan signed-in pages? Stored credentials, session cookies, login-form playback, and arbitrary auth headers are all different feature sets. For commerce and SaaS, where most of the product lives behind a login wall, this is the axis that decides whether the checker is useful at all on your actual product surface.
• Accessibility statement generation. Under the EU Accessibility Act (Article 13 and Annex V) and the Web Accessibility Directive, in-scope services must publish accessibility information. A checker that generates an EAA-ready statement from your latest scan saves you a separate document workflow. A checker that produces only a numeric score does not.

Tools worth knowing about

This is a directory, not a ranking. Each tool fits a different shape of buyer. The W3C maintains the comprehensive list; the short selection below covers the names that come up most often in procurement conversations.

• WAVE (WebAIM) — Free single-page checker available as a web tool and browser extension. Long-running, well-trusted, particularly good as a teaching tool because it overlays icons on the page so you can see exactly where each issue sits visually.
• axe DevTools (Deque) — Browser-extension and CI version of axe-core, the most-used open-source rule engine. The free extension covers single-page scans; paid tiers add intelligent guided tests, CI integration, and reporting. This is the engine many other tools, including SweepHound, run under the hood.
• Silktide — Full-site scanner with broader content/SEO coverage in addition to accessibility, popular with government and higher-ed buyers who need one tool for content quality and a11y together.
• Lighthouse — Built into Chrome DevTools; runs a subset of axe-core rules against a single page and produces a numeric score. Free, always available, and a reasonable smoke check — but single-page only and not an audit-grade tool.
• ARC Toolkit (TPGi) — Browser-extension checker oriented toward auditors, with strong ARIA pattern coverage and an emphasis on guided manual inspection alongside automated checks.
• W3C Web Accessibility Evaluation Tools List — The full directory, filterable by license, language, guideline (WCAG version), and tool type. If a tool is not on this list it is not (yet) part of the recognised ecosystem.

Free single-page scanners vs site-wide scanners

The clearest dividing line in the category is whether a tool scans a single page on demand or crawls the whole site on a schedule. They solve different problems and you usually need both at different points in the workflow.

Single-page scanners(WAVE, axe DevTools extension, Lighthouse, ARC Toolkit) are free, instant, and live in your browser. They are the right tool when a developer is fixing a specific page, when a designer wants to sanity-check a new template, or when you need a five-minute assessment of a vendor's landing page. They are the wrong tool for production audits because you have to remember to run them on every URL, including the long tail of legacy templates and content-team pages where most violations actually live.

Site-wide scanners (SweepHound, Silktide, and the audit-grade tiers of axe and others) crawl every discoverable page, track findings over time, and surface regressions between runs. They are the right tool when you are responsible for the accessibility posture of a production site, when procurement requires a defensible audit trail, or when you need an EAA-ready statement generated from fresh data. The cost trade is that they take longer to run and require some setup (sitemap, auth, schedule). For the broader automated-vs-manual strategy story, our accessibility testing guide covers how these fit into a full testing program.

What no scanner can do

The honest answer to “which scanner is best” is that even the best one only sees a slice of the WCAG surface. No checker can evaluate whether your alt text is meaningful, whether tab order matches visual order, whether the page sounds right on NVDA and VoiceOver, whether focus moves predictably after a delete, or whether your error messages help a real user recover. That is human work, and the categorical limits are the same across every scanner on the market. Our what scanners miss analysis walks through exactly what falls outside automated coverage and why, and our manual accessibility checklist turns that gap into a concrete review script. Read those before you finalise a scanner choice — they will change which axes above you weight most heavily.

How SweepHound fits the buyer matrix

SweepHound is a site-wide scanner positioned at the remediation-and-statement end of the matrix. It is not the right tool if you only want a free in-browser smoke check of a single page; it is built for teams responsible for the ongoing accessibility posture of a production site. Mapped to the axes above:

• Rule engine — dual-engine (axe-core + IBM Equal Access Checker) on every paid plan, Starter through Agency. We dedupe overlap and group by element so one button does not produce four findings.
• Crawl depth — full-site sitemap and BFS crawling on every plan, with JS-rendered SPA support; authenticated scanning is available from the Growth tier upward.
• Remediation output — deterministic before/after code fixes for mechanical issues (alt-text presence, label association, contrast adjustments), with explicit manual-review flags on findings that need human judgement. We never let an LLM ship unsafe markup unattended.
• Manual-review handling — every report ends with a finite manual checklist, not a green badge.
• Exports — PDF, CSV, sharable HTML report links (Agency), and webhook integrations for ticket systems.
• Monitoring — custom-schedule re-scans with regression detection and email alerts on every paid plan.
• Authentication — stored credentials and session playback on Growth and Agency.
• Accessibility statement — EAA-ready statement (English) generated from your latest scan on every paid plan.

If you want to compare those features against what your site actually returns, start a free scan — the free tier runs a full crawl and shows grouped findings, and paid tiers add the dual-engine, monitoring, authentication, and statement features above. See pricing for the full plan matrix.