- Successful accessibility programs keep five core documents: an audit report, an ACR, an accessibility statement, an internal policy, and remediation records.
- Each document serves a different audience, from buyers to lawyers to your own team.
- Documentation only works if it’s dated, accurate, and updated after every audit cycle.
Every successful accessibility program keeps a small set of documents: a current audit report, an ACR, a public accessibility statement, an internal accessibility policy, and records of remediation work. These five documents prove your effort, answer buyer questions, and reduce legal risk.
None of these are busywork. Each one exists because someone, a procurement officer, a plaintiff’s lawyer, a customer, or your own developer, will eventually ask for it.
The Five Core Documents
Here are the five documents every mature accessibility program maintains:
- Audit report: the findings from a (manual) audit of your website or app against WCAG 2.1 AA or 2.2 AA. This is your source of truth for what needs fixing.
- ACR: a completed VPAT that reports your product’s WCAG conformance to buyers, especially in procurement.
- Accessibility statement: a public page that states your commitment, your target standard, and how users can reach you with issues.
- Accessibility policy: an internal document assigning ownership, standards, and processes for your team.
- Remediation records: dated proof that issues were found, assigned, and fixed.
The audit report anchors everything else. You can’t write an accurate ACR or make honest claims in a statement without knowing your actual state of conformance, which is why (manual) accessibility audits come first.
Who Reads What
Different audiences pull different documents, and confusing them is a common mistake. Buyers want the ACR. Lawyers want to see remediation history. Users want the statement.
| Document | Primary audience | Purpose | Update cadence |
|---|---|---|---|
| Audit report | Internal team | Identify WCAG issues to fix | Every audit cycle |
| ACR (completed VPAT) | Buyers, procurement | Report conformance status | After major releases or annually |
| Accessibility statement | Public, users | Commitment and contact path | Whenever status changes |
| Accessibility policy | Internal team | Assign ownership and standards | Annually |
| Remediation records | Legal, leadership | Prove ongoing effort | Continuously |
Note: an ACR is not certification. It’s an accounting of your product’s accessibility, and it only brings value if it’s accurate. A vague ACR with empty remarks columns is near worthless.
How to Build Your Documentation Set
Building your accessibility documentation set works best in this order:
- Conduct a (manual) audit against WCAG 2.1 AA or 2.2 AA so you know your actual state.
- Remediate the issues and log every fix with dates and owners.
- Have an ACR prepared based on the post-remediation state of your product.
- Publish an accessibility statement that reflects reality, not aspiration.
- Write an internal policy that assigns ownership so the work continues.
Skipping to step four is tempting, but a statement that claims conformance you don’t have makes things worse, not better. Documentation follows the work; it never replaces it.
Keep It Current
Stale documentation is a liability. An ACR from three product versions ago misleads buyers, and a statement pointing to a dead contact form signals neglect.
Websites change constantly with new code, new content, and new design. That’s why tracking these documents over time matters as much as creating them. Date everything, and refresh after every audit cycle.
For remediation records, a running log works. Screenshots, ticket numbers, and completion dates are enough. If you ever face a demand letter, this history is your best evidence of good faith.
Need Help Getting Your Documents in Order?
We conduct fully manual WCAG audits and prepare ACRs with fast turnarounds and competitive pricing. Send us a message and we’ll respond ASAP, usually within a few hours.
