A web team runs its monthly automated scan, watches the dashboard turn green, and files the report without much ceremony. Six months later, a formal complaint names a specific defect on a specific page, and someone in the state accessibility office or the agency's own legal counsel asks a plain question: when was this found, who was told, and what happened after that. The scan has no answer, because a scan was never built to keep one.
Searching for a ranked list of platforms will not solve that problem, because the feature that separates a scanning tool from a compliance record has little to do with how many pages a crawler can process in an hour.
A scan reports a moment; compliance tracking reports a history
An automated scanner is genuinely good at one job: catching a defined set of repeatable defects across many pages in a short amount of time. It checks contrast ratios, missing labels, empty links, and a handful of other machine-detectable patterns against Web Content Accessibility Guidelines (WCAG) success criteria, and it returns a snapshot of what it found on the day it ran. That snapshot dissolves the moment the page changes or the next scan overwrites it.
Compliance tracking is a different obligation entirely. It asks whether an institution can show, months or years later, that a known defect was assigned to someone, fixed within a reasonable window, and confirmed fixed by retesting the same path rather than a fresh crawl of the whole site. Title II of the Americans with Disabilities Act (ADA) and the Department of Justice's 2024 web rule put public entities on a practical timeline for accessibility, and that timeline makes the difference between a scan and a record far more consequential than it used to be. The Department of Justice's overview of the 2024 Title II web accessibility rule explains the compliance dates institutions are working against, but it says nothing about how to keep evidence, because that is an institutional decision, not a legal one.
Four things a scan alone will never produce
- Retest history. Whether the exact defect that was reported got checked again, on the same page and the same interaction, after someone claimed to fix it.
- Assigned ownership. Who was responsible for the fix, recorded at the moment the defect was found rather than reconstructed from a group chat six months later.
- A specific success criterion. The exact WCAG criterion a finding violates, rather than a generic accessibility flag, so legal, technical, and program staff can describe the same problem in the same terms.
- A defensible timeline. The connected dates from detection to assignment to remediation to retest, held in one place rather than scattered across tickets, emails, and screenshots.
None of this means the scanning tool failed at its job. It means the job of scanning and the job of compliance tracking are not the same job, even though vendors frequently sell them under one name.
What an audit trail schema actually needs to hold
A compliance record only works if every finding carries the same fields, whether the finding came from an automated crawl or a person testing with a screen reader. A workable schema looks like this:
| Field | Why it matters |
|---|---|
| Finding identifier | Lets the same defect be referenced consistently across tickets, emails, and reports. |
| Date first detected | Establishes when the institution first knew, which matters if a complaint later asks what was known and when. |
| Success criterion cited | Ties the finding to a specific WCAG requirement rather than a vague category. |
| Page or component | Points to the exact template, form, or document involved, not just a domain. |
| Severity | Distinguishes a blocked task from a cosmetic issue, so remediation time follows public need. |
| Owner | Names the person or team accountable for the fix. |
| Remediation date | Records when the fix was actually made, not when it was promised. |
| Retest date and result | Confirms the same path was checked again and what it showed. |
| Evidence artifact | Preserves a screenshot, code excerpt, or document export tied to that specific finding. |
The World Wide Web Consortium's Website Accessibility Conformance Evaluation Methodology lays out a comparable structure for documenting how a conformance evaluation was conducted, and it is a reasonable model to borrow from even for teams that are not running a formal evaluation. A platform that automates most of these fields saves a team from rebuilding this record by hand every time a complaint or audit request arrives.
Evidence retention needs a shape before it needs a duration
Most conversations about retention start with how long to keep records, but the more common failure happens earlier than that. Many quality assurance (QA) tools save a pass or fail boolean and a timestamp, not the artifact that proves the finding. A compliance tracking platform needs to keep the actual screenshot, the document excerpt, or the interaction state, and it needs to keep it attached to the version of the page that existed at the time, because the live page will not match what a complaint describes once a redesign or a template change has happened. Losing that link turns a defensible record into an argument about whose memory is more accurate.
Separating a scanning tool from a compliance tracking platform
Procurement conversations tend to focus on scan coverage and speed, since those numbers are easy to compare on a vendor sheet. The more useful questions are structural, and they rarely appear in a sales pitch:
- Does the platform store a retest result against the original finding, or does a new scan simply replace the old one without a visible history?
- Can a human reviewer add or annotate a finding the automated scan cannot detect, and does that manual entry carry the same weight in the record as an automated one?
- Does every finding map to a specific success criterion, or does the tool group everything under a single generic accessibility label?
- Can the platform export a record that a legal team, a state auditor, or a federal reviewer could read without a technical translator?
- Does retest and ownership history survive a redesign, a vendor swap, or a content management system migration, or does the history reset along with the tool?
A scanning tool that cannot answer most of these questions is still worth using for what it does well. It is simply not the same category of tool as a platform built to hold an institution's compliance record, and treating the two as interchangeable is where the exposure usually starts.
Building the record before someone asks for it
A practical place to start is with one finding the team already knows about. Fill in the fields above by hand for that single defect, then compare the result against what the current tool would have produced automatically. The gap between those two versions is a more honest procurement question than anything on a vendor's feature list, since it shows exactly what the institution would be missing when a complaint asks not just what was found, but what happened after.
Key takeaways
- A scan reports what a crawler found on the day it ran; compliance tracking preserves who owned a defect and what a later retest confirmed.
- A defensible record needs a cited WCAG success criterion, an assigned owner, and connected dates from detection through retest, not just a pass or fail flag.
- Evidence must include the actual artifact, tied to the version of the page it describes, not a placeholder timestamp.
- Testing this is simple: build one finding's record by hand and compare it to what the current tool produces automatically.
Questions readers ask
Is an automated accessibility scan the same thing as compliance tracking?
No. A scan produces a snapshot that the next scan overwrites, while compliance tracking keeps a permanent record of when a defect was found, who owned it, and what a retest later confirmed.
What fields belong in a compliance audit trail?
At minimum, a finding identifier, the date first detected, the specific WCAG success criterion cited, the assigned owner, the remediation date, the retest date and result, and an evidence artifact tied to that finding.
Why isn't a pass or fail flag enough evidence?
A boolean and a timestamp show that a check ran, but they don't preserve the artifact that proves what was found or tie it to the version of the page that existed at the time.