How do you prove accessibility remediation?

Proving accessibility remediation requires a documented chain of evidence: the original issue was identified and recorded, a specific person was assigned responsibility, remediation actions were taken and documented, evidence of the fix was submitted, and an independent reviewer verified the resolution. Each step must be attributed to a specific person and timestamped.

Is fixing an accessibility issue the same as proving you fixed it?

No. Fixing an issue and proving you fixed it are different things. The fix is the technical work. The proof is the documented evidence that the work happened — who did it, when, what they changed, and who verified the result. Without that documentation, the fix is invisible to anyone examining your compliance record.

What evidence is needed to prove accessibility remediation?

At minimum: a record of the original finding, documentation of who was assigned to fix it, evidence of what was changed (screenshots, code changes, or re-scan results), a timestamp for each action, and a review decision by someone other than the person who made the fix. This creates a chain of accountability that can withstand external examination.

How to Prove Accessibility Remediation

Fixing an issue and proving you fixed it are not the same thing.

Proving accessibility remediation means producing documented evidence that a specific accessibility issue was identified, assigned to a responsible person, fixed, and independently verified. It requires a chain of accountability — not just a before-and-after scan, but a record of who did what, when, and under whose authority.

The technical fix is the work. The proof is the documentation that the work happened.

What Proof Requires

A record of the original finding — what was wrong, where, and when it was detected
Documentation of who acknowledged the issue and who was assigned to fix it
Evidence of remediation — what was changed, by whom, and when
Verification by someone other than the person who made the fix
A timestamp at every step, creating an unbroken timeline

What Does Not Count as Proof

A follow-up scan showing the issue is gone does not prove remediation by itself. It proves the issue is no longer detected. It does not show who fixed it, when, or what they changed. It does not show that anyone reviewed the fix.

Similarly, a Git commit is evidence that code changed. It is not evidence that the change was made in response to a specific accessibility finding, or that the result was verified against accessibility criteria.

Proof requires connecting the finding to the fix to the verification. Without that connection, each piece is an isolated artifact.

Why It Matters

In legal and regulatory contexts, claiming "we fixed it" is not sufficient. The question is whether you can demonstrate — with documentation — that a specific issue was addressed through a deliberate, accountable process.

This is especially important when the same issue category appears across multiple scans. If a pattern of recurring issues exists with no corresponding pattern of documented remediation, it suggests negligence rather than diligence. Building compliance evidence at the time of remediation avoids this problem.

Common Misconceptions

"A clean re-scan proves we fixed it." A re-scan proves the scanner no longer detects the issue. The issue may have been fixed, or it may have moved, or the scanner's rules may have changed. A re-scan is supporting evidence, not standalone proof.

"The developer who fixed it can testify." Testimony about past work is inherently weaker than contemporaneous documentation. Memories are unreliable. Developers leave organizations. A defensible record does not depend on any individual's recall.

"We track remediation in our project management tool." Project management tools track tasks. They do not enforce the separation of duties between evidence submission and review. They do not produce immutable records. Tickets get edited, reassigned, deleted. That is task management, not evidence.

What This Means in Practice

Remediation proof should be generated as a byproduct of the remediation process, not assembled after the fact. When a developer fixes an accessibility issue, they should submit evidence — a screenshot, a re-test result, a description of the change — through a system that timestamps it, attributes it, and routes it to an independent reviewer.

This is the difference between testing and governance. Testing finds the problem. Governance produces the documented proof that the problem was solved.

SiteRecord captures remediation evidence at the point of action — attributed, timestamped, reviewed, and stored as part of an immutable compliance record.