- Good documentation ties every accessibility claim to an audit, a fix, and a dated record.
- The core documents are an audit report, a remediation log, an accessibility statement, and an ACR.
- Keep records current as your site changes, not frozen at a single point in time.
Documenting digital accessibility compliance means keeping dated, evidence-backed records that connect each accessibility claim to a specific test, fix, and reviewer. Done well, it protects you with buyers and in legal review. Done poorly, it means very little.
Why documentation matters more than a single certificate
There is no government certificate that declares a website ADA compliant. What you actually have is a paper trail. That trail is what a procurement officer or an opposing attorney will ask to see.
Think of your documentation as a running account of what you tested, what you found, and what you did about it. A claim without records behind it is an opinion.
Because accessibility is measured against a standard, your records should always name one. We recommend defaulting to WCAG 2.1 AA or WCAG 2.2 AA and stating the version you tested against.
The core documents you need
A method is only as good as the artifacts it produces. Here are the records that carry the weight of a compliance file:
- Audit report: the technical findings from a (manual) audit, tied to specific WCAG success criteria.
- Remediation log: a dated record of each issue, its status, and who fixed it.
- Accessibility statement: a public page describing your conformance level and how users can report problems.
- ACR: a completed VPAT that reports your product’s conformance for buyers and procurement teams.
Each of these answers a different question. The audit says what was wrong, the log says what changed, the statement speaks to users, and the ACR speaks to buyers.
A step-by-step documentation method
Building a defensible record follows a clear order. Documenting your compliance from scratch takes six steps:
- Define scope: list the pages, templates, flows, and any mobile app or PDFs in the assessment.
- Name the standard and level, for example WCAG 2.2 AA.
- Commission a (manual) audit and store the report as your baseline.
- Log every issue with a status, an owner, and a date.
- Retest after remediation and record the outcome next to each issue.
- Publish an accessibility statement and, if buyers need it, produce an ACR.
Tracking these documents over time keeps the file honest as your site evolves. New code, new design, and new content can all introduce issues after your baseline is set.
How the core documents compare
| Document | Primary audience | What it proves |
|---|---|---|
| Audit report | Your team | What was tested and what failed |
| Remediation log | Your team, legal counsel | That issues were addressed and dated |
| Accessibility statement | Site visitors | Your stated conformance and contact path |
| ACR | Buyers, procurement | Conformance reported against a standard |
Keep the record alive
A compliance file is not a one-time artifact. Every publish can change your accessibility posture, so a snapshot from last year proves little today.
Set a cadence. Re-audit high-traffic templates on a schedule, and log fixes as they ship rather than reconstructing them later.
Note: the remarks column in an ACR carries most of its value. If that column is thin, the document reads as near worthless to a careful buyer.
Where to start
If you want records that hold up, start with an accurate baseline audit and build the rest around it. We only conduct fully (manual) accessibility audits, and we deliver reports for most clients within one to two weeks.
Contact us for a fast quote and competitive pricing, and we will point you to the exact documents your situation needs. Reach out through our contact page and we will respond quickly.
For a closer look at this, see our overview of compliance documentation tracking.
