Accessibility Audit Evidence
Checklist for accessibility audit evidence: scope, WCAG mapping, screenshots, user impact, remediation, retesting, and closure proof.
Accessibility audits become useful when findings can be reproduced and fixed. A report that only lists failures may satisfy a surface-level checkbox, but it does not give teams enough information to remediate with confidence.
For technical teams, evidence is the bridge between a compliance finding and an implementation task.
What evidence should each finding include?
A practical finding should answer these questions:
- Where does the issue occur?
- What user flow, state, or component is affected?
- What was expected?
- What actually happened?
- Which standard or requirement is involved?
- Which users are affected?
- What should change?
- How should the fix be retested?
If the report does not answer these questions, the team will likely need another review before meaningful remediation can start.
Scope evidence prevents confusion
Before the findings, the report should explain the audit boundary.
This includes the reviewed pages, workflows, components, PDF files, document samples, user roles, browsers, devices, and assistive technologies. It should also identify the target standard, such as WCAG 2.2 AA or another agreed framework.
Without scope evidence, stakeholders cannot know whether the report represents a full audit, a sampled review, a document-only engagement, or a narrow journey test.
Automated scans need expert context
Automated tools are useful for discovering some issues quickly. They can identify many markup, contrast, ARIA, and structure problems.
But they cannot determine the full accessibility of a product. Human review is still needed for keyboard behavior, screen reader experience, logical reading order, error recovery, PDF semantics, and task completion.
The report should separate:
- Automated findings.
- Manual validation.
- Assistive technology observations.
- Issues that require judgment.
- Limitations of the testing method.
This makes the evidence easier to trust.
Use the right proof format
Different accessibility barriers require different proof.
A screenshot may be enough for poor contrast. It is not enough for a broken menu interaction. A screen reader issue needs observation notes. A keyboard trap needs step-by-step keyboard evidence. A PDF structure problem needs file-level tag or reading-order evidence.
Useful evidence may include:
- Screenshots.
- Short recordings.
- Keyboard navigation paths.
- Screen reader notes.
- Browser and viewport details.
- PDF tag, heading, table, link, and form evidence.
- Reproduction steps.
The goal is not to overload the report. The goal is to include enough proof for the assigned team to act.
Retesting needs its own evidence
A remediation ticket is not the same as verified closure.
Retest evidence should show whether the original issue was fixed, partially fixed, not fixed, deferred, or unable to verify. It should also include the tested environment and a note explaining any remaining risk.
For compliance teams, this is important because it creates a traceable record from finding to remediation to closure.
Conclusion
Strong accessibility evidence reduces confusion, speeds up remediation, and gives teams a defensible audit trail.
If your audit report cannot show what was tested, how the issue was found, why it matters, and how it was closed, the evidence is not complete enough.
Read the original guide on IAAP Audit: https://iaapaudit.com/blog/what-evidence-accessibility-audit-report-include
