Why Accessibility Scan Results Don’t Count as Compliance Evidence

Most organizations believe that running an accessibility scan and producing a report demonstrates compliance. It does not. A scan report is a detection artifact — it proves that issues were identified at a point in time. It says nothing about whether those issues were acknowledged, assigned, fixed, or verified. On its own, a scan report has almost no evidentiary value in a legal, regulatory, or audit context.

Compliance is not about finding problems. It is about proving you responded to them. That proof lives in documentation: structured records showing what was found, who was responsible, what action was taken, and when each step occurred. Without those records, an organization cannot demonstrate compliance — even if every issue was actually fixed.

The distinction between detection and documentation is not academic. It determines whether an accessibility program can withstand scrutiny or collapse under it.

What Accessibility Scanners Actually Do

Automated accessibility scanners evaluate web pages against a set of machine-verifiable rules derived from standards like the Web Content Accessibility Guidelines (WCAG). They check for conditions that can be detected programmatically: images without alternative text, form fields without labels, insufficient color contrast, missing document language attributes, and similar patterns.

These tools are valuable. They evaluate hundreds of pages in minutes, identify recurring patterns across a site, and surface issues that would take a manual reviewer hours to find. For organizations managing large or frequently changing websites, automated scanning is a practical necessity.

But scanners operate within hard constraints. They evaluate code structure, not user experience. A scanner confirms that an image has an alt attribute — it cannot determine whether the alt text meaningfully describes the image. It detects that a button exists, not whether the button's purpose is clear to someone using a screen reader. Industry estimates suggest automated tools detect roughly 30 to 40 percent of WCAG conformance issues. The rest require human judgment.

This is not a criticism of scanning tools. It is a description of their boundaries. Organizations that understand those boundaries use scanners effectively. Organizations that do not treat scan output as proof of compliance when it is only the first step.

Why Detection Is Not Enough

When an organization's accessibility practices come under scrutiny — whether through a regulatory inquiry, a legal complaint, or an internal audit — the questions asked are rarely about scanning. They are about institutional response.

Typical questions include:

• When were accessibility issues first identified?
• Who was made aware of the findings?
• What decisions were made about how to address them?
• What specific actions were taken to fix each issue?
• How was the effectiveness of those fixes confirmed?
• What is the timeline from detection to resolution?

A scan report answers the first question. It shows that issues were identified at a particular point in time. It does not answer any of the others. Presented alone — without remediation records, assignment history, or verification evidence — a scan report would not satisfy legal discovery, regulatory inquiry, or independent audit. It is an input to a compliance process, not an output of one.

An organization that produces scan results but cannot demonstrate what happened afterward has a detection program, not a compliance program. Compliance is about demonstrating ongoing, responsive effort — not producing an artifact that says problems were found.

Regulators understand that accessibility is complex and that no organization fixes everything instantly. What they look for is evidence of a systematic process: awareness, prioritization, action, and follow-through. The absence of that process, even in the presence of scan results, indicates that accessibility is being monitored without being managed.

The Importance of Remediation Records

Remediation documentation is where scanning ends and compliance begins. When an issue is detected, the record of what was done about it — and by whom, and when — is what transforms a finding into evidence of institutional accountability.

Effective remediation records include several elements: a description of the issue as detected, including where it appeared and what standard it relates to; the action taken to address it, whether a code change, content update, design revision, or policy decision; the identity of the person who performed the remediation and, separately, the person who reviewed it; and timestamps establishing when each step occurred.

What an Accessibility Evidence Record Looks Like

Consider a concrete example. An automated scan on March 3 identifies a missing form label on a checkout page, a WCAG 2.1 Level A violation under Success Criterion 1.3.1. The issue is assigned to a front-end developer on March 4. On March 6, the developer adds an associated label element to the input field and marks the issue as remediated. On March 7, a separate team member reviews the fix, confirms the label is programmatically associated and visible, and closes the record. Each step carries a timestamp and an identified responsible person.

That five-line record — issue, assignment, action, review, resolution — is more defensible than a 200-page scan report with no follow-up documentation. It demonstrates awareness, responsibility, and verified response.

This is the level of evidence that regulators, auditors, and plaintiff counsel expect to see. A scan report — no matter how detailed — cannot produce it.

Remediation records demonstrate that the organization treated accessibility findings as actionable obligations rather than informational outputs. They create a chain of awareness, responsibility, and response that can be examined independently.

Organizations that maintain these records also gain operational clarity. When findings are documented systematically, patterns become visible. Recurring issues surface and can be addressed at a structural level rather than fixed one page at a time. The remediation record becomes both a compliance artifact and an operational tool for improving accessibility outcomes.

Verification Matters

Fixing an issue and confirming the fix actually resolved the problem are two different activities. Organizations routinely assume that once a change is made, the issue is resolved. In practice, fixes are incomplete, introduce new issues, or fail to address the underlying barrier more often than expected.

Verification closes the loop. It confirms that the remediation was effective — that the issue identified by the scanner or manual reviewer is no longer present. Verification takes several forms: a follow-up scan targeting the specific page and issue, a manual review by someone other than the person who performed the fix, or a structured test confirming that the assistive technology interaction now works as expected.

From a compliance perspective, verification demonstrates diligence. An organization that detects an issue, fixes it, and confirms the fix has completed a full cycle of responsive action. An organization that detects and fixes without verification has done most of the work but left the most credible part of the record incomplete.

Verification also protects against regression. Issues fixed in one release reappear in the next if the underlying cause was not fully addressed. Periodic verification ensures resolved issues remain resolved, and creates a longitudinal record that demonstrates sustained attention rather than one-time effort.

Documentation Is the Evidence

Scanning is detection. Documentation is proof. These are not interchangeable, and treating them as equivalent is the single most common failure in accessibility compliance programs.

Organizations that invest in scanning without investing in documentation do genuine work to improve accessibility while failing to create any record that the work was done. When scrutiny arrives — and in the current regulatory environment, it arrives — the absence of structured documentation leaves the organization unable to answer the most basic questions about its own process. Work that is not documented is, for compliance purposes, work that did not happen.

The goal is not paperwork for its own sake. The goal is to ensure that every meaningful step in the accessibility lifecycle — detection, assignment, remediation, review, and verification — produces a record that an independent reviewer can examine. That record, maintained consistently over time, is what transforms accessibility activity into defensible compliance evidence. For a deeper examination of what qualifies as defensible evidence, see What Compliance Evidence Actually Is. For why that evidence must be continuous rather than point-in-time, see Compliance Is a Timeline, Not a Snapshot.

Scanners find the issues. Documentation proves you addressed them.