A scan cannot replace an audit. Automated scans detect approximately 25% of accessibility issues, which means the other 75% goes undetected without human evaluation. Scans evaluate HTML, CSS, and ARIA attributes against rule sets, but they cannot judge context, meaning, or user experience. An audit is a thorough human evaluation that includes screen reader testing, keyboard testing, visual inspection, code inspection, and an automated scan as one component of the review. Scans and audits work together. They are not interchangeable.
| Key Point | What It Means |
|---|---|
| Coverage | Scans detect approximately 25% of accessibility issues. The remaining 75% requires human evaluation. |
| Method | Scans apply rule-based checks on code. Audits combine assistive technology testing, code inspection, and visual review. |
| Output | A scan produces a list of flagged code patterns. An audit identifies specific issues with locations and remediation guidance. |
| Role | Scans are most useful for monitoring after an audit. They catch regressions but cannot replace the original evaluation. |
What a Scan Actually Does
A scan loads a web page and applies automated checks against WCAG success criteria by parsing HTML, CSS, and ARIA attributes. It looks for patterns: missing alternative text, form inputs without labels, empty links, invalid ARIA roles, and similar code-level signals.
These checks are fast and consistent. A scan can evaluate hundreds of pages in minutes and produce a report flagging every instance of a known issue pattern. That speed makes scans valuable for ongoing monitoring across large sites.
The limitation is the rule set. A scan can only flag what its rules describe. If a WCAG criterion requires human judgment, the scan cannot evaluate it.
What a Scan Cannot Detect
Most accessibility issues require context. A scan can confirm an image has alternative text, but it cannot judge whether that text accurately describes the image. A scan can verify a button has a name, but it cannot determine whether the name makes sense in context.
Areas where scans fall short include alternative text quality, link text clarity, heading structure logic, reading order, focus order, keyboard operability across components, screen reader announcements, error message usefulness, and the relationship between visual layout and the underlying code. These represent the bulk of real-world accessibility issues.
What an Audit Covers
An audit is a human evaluation conducted by an accessibility professional. The methodology includes screen reader testing with NVDA, JAWS, and VoiceOver, keyboard testing, code inspection, visual inspection, browser zoom evaluation at 200% and 400%, and an automated scan as one input among many.
The output identifies specific issues with their locations, the WCAG criterion involved, severity, and remediation guidance. That level of detail is what allows a development team to fix issues correctly the first time.
How They Work Together
The right model treats scans and audits as complementary. An audit establishes the baseline by identifying issues across the full WCAG criteria a human can evaluate. Remediation follows. Once fixes are in place, scheduled scans monitor for regressions: a developer pushes a change, and the scan flags newly introduced code-level issues before they accumulate.
Replacing an audit with a scan leaves 75% of issues invisible. Replacing a scan with an audit leaves ongoing changes unmonitored between evaluations. Both have a role.
When a Scan Is Enough
A scan alone is rarely enough for any organization with conformance obligations or external accountability. The exception is early-stage internal tooling where no users with disabilities are affected and no conformance requirement applies. Even then, a scan provides a partial view. Any product that reaches real users, customers, employees, or procurement reviewers needs an audit to support a credible conformance position.