Automated accessibility scanning works by running a rules engine across a webpage's rendered HTML, CSS, and accessible tree, then flagging code patterns that match known WCAG issues. The scanner parses the DOM, checks elements against a library of programmatic rules, and returns a list of detected issues with severity and location. Scans only flag approximately 25% of issues because most WCAG criteria require human judgment, such as evaluating whether alt text is accurate or whether a heading structure makes sense. Scans are useful for monitoring code-level regressions, but they cannot determine WCAG conformance on their own.
The Accessibility Tracker Platform includes scanning as a standalone feature for tracking these code-level issues over time across pages, which supports broader accessibility work without replacing a (manual) audit.
| Aspect | What It Means |
|---|---|
| Detection method | Rules engine checks DOM, CSS, and accessibility tree against WCAG rule library |
| Coverage | Approximately 25% of WCAG issues, all code-level |
| What scans cannot do | Determine conformance, evaluate content quality, judge context |
| Best use | Ongoing monitoring for code-level regressions across pages |
| Required companion | A (manual) audit conducted by a qualified auditor |

What a Scanner Actually Does
A scanner loads a page in a headless browser or crawler, waits for the DOM to render, then traverses the document tree. It reads element attributes, computed styles, ARIA properties, and the accessibility tree the browser exposes.
Each element is evaluated against a set of rules. A rule is a small program that asks a specific question. Does this image have an alt attribute? Does this button have an accessible name? Does this text meet the 4.5:1 contrast ratio against its background?
When a rule fires, the scanner records the element, the WCAG criterion it maps to, and a severity score. The output is a structured report listing every issue found.
What Scans Can Detect
Scans are accurate at catching issues with clear programmatic signals. These include missing alt attributes, empty buttons, form inputs without labels, low color contrast, missing language attributes on the html element, and improperly nested headings.
They are also reliable at finding duplicate IDs, invalid ARIA roles, and links without discernible text. These are pattern-matching problems, and pattern matching is what software does well.
Why Scans Only Catch About 25% of Issues
Most WCAG criteria require human judgment. A scanner can confirm an image has alt text but cannot evaluate whether that alt text describes the image accurately. It can see a heading exists but cannot judge whether the heading reflects the content beneath it.
Criteria like meaningful sequence, info and relationships, name role value in context, and focus order need a person who understands the page's purpose. Keyboard traps, screen reader announcements, and dynamic content behavior need real interaction, not static code analysis.
This is why scans flag approximately 25% of WCAG issues. The other 75% live in territory only a qualified auditor can evaluate.
How Does Scanning Differ From an Audit?
A scan is automated and fast. It runs on a schedule, returns a list of code-level issues, and repeats. An audit is a (manual) evaluation conducted by a person trained in WCAG, who reviews the page across desktop and mobile, uses assistive technology, and applies judgment to each criterion.
The audit produces a report that maps issues to specific WCAG criteria with reproduction steps and recommended fixes. The scan produces a list of detected patterns. These are completely separate activities, and one does not replace the other.
Where Monitoring Fits
Scanning has real value as a monitoring layer. After an audit identifies issues and a remediation cycle closes them, code regressions can reintroduce problems. A new component ships without an accessible name. A redesign drops contrast below the threshold. A developer removes an aria-label by mistake.
Scheduled scans catch these regressions early. Accessibility Tracker runs scans across pages and tracks results over time so teams can see when a known issue reappears or a new code-level issue is introduced.
The Role of AI in Scanning
AI extends what scanners can do at the edges. Computer vision models can attempt to evaluate whether an image's alt text matches the image content. Language models can flag heading text that seems disconnected from the section below it.
These are useful signals, not verdicts. AI applied to accessibility scanning makes the rules engine smarter, but it does not change the underlying limit: conformance still requires human evaluation.
Frequently Asked Questions
Can a scan determine if my site is WCAG conformant?
No. Scans detect code-level patterns that map to roughly 25% of WCAG criteria. Conformance requires a (manual) audit covering all applicable success criteria with human judgment.
How often should I run an accessibility scan?
Weekly scans work well for most production sites. Higher-frequency scans make sense after a deployment or major content update. The goal is catching regressions before they age into your codebase.
What is the difference between an accessibility checker and a scanner?
The terms are often used interchangeably. Both refer to automated tools that check pages against a rule library. A checker is sometimes the in-browser version, while a scanner typically runs at scale across multiple URLs and stores historical data.
Do scanners work on single-page applications?
Yes, but the scanner must wait for the JavaScript-rendered DOM before evaluating rules. Modern scanners manage this with headless browsers that render the page fully before traversal.
Can a scan replace user evaluation?
No. User evaluation involves real people, often using assistive technology, interacting with the product. Scans evaluate code patterns. The two answer different questions.
Scanning is one input in a larger accessibility workflow. Pair it with a (manual) audit and a tracking system that connects detected issues to remediation work, and the data starts to mean something.
Contact Accessibility Tracker to see how scanning fits inside a full conformance workflow: accessibilitytracker.com.

