Audit Reports
Accessibility Audit Report Sample: What a Good Report Includes
A practical guide to what an accessibility audit report sample should include for scope, evidence, severity, standards mapping, remediation, and retest review.
What an accessibility audit report sample should show
An accessibility audit report sample should help a buyer understand the quality of the audit before they commit to the engagement. It should show how findings are documented, how evidence is captured, how severity is assigned, and how remediation teams can act on the results.
A strong sample report is not only a list of issues. It is a structured decision document for compliance, product, design, engineering, procurement, and leadership teams.
Start with scope and audit context
The first part of the report should make the audit scope clear. Without scope, the reader cannot understand what was tested, what was excluded, or how much confidence the report provides.
For websites, apps, portals, PDFs, or authenticated journeys, scope should be specific enough that another reviewer can understand the exact coverage.
- Product, website, app, portal, or document set reviewed.
- Pages, templates, user journeys, or document samples included.
- Applicable standard such as WCAG 2.2 AA, IS 17802, GIGW, Section 508, or EN 301 549.
- Testing date, browser or device context, and assistive technology assumptions.
- Known exclusions, constraints, or areas not included in the audit.
Evidence should make findings reproducible
A sample report should show how evidence is captured. Screenshots are useful, but they are not enough by themselves. The report should explain where the issue occurs, what was tested, what failed, and what the expected accessible behavior should be.
Good evidence helps delivery teams reproduce the problem and helps governance teams understand why the issue matters.
- Affected page, screen, component, form, journey, or document page.
- Steps to reproduce the issue.
- Observed behavior and expected behavior.
- Screenshot, selector, interaction note, or assistive technology observation where useful.
- User impact for keyboard, screen reader, low-vision, cognitive, motor, or document users.
Severity should support prioritization
Severity should help teams decide what to fix first. It should not be a vague label added after the finding. A useful report explains severity through user impact, task importance, legal or procurement exposure, and remediation urgency.
For example, a keyboard trap in a payment or application journey usually carries more operational risk than a minor spacing issue in a low-traffic informational section.
- Critical issues block important tasks or prevent access to essential content.
- High issues create serious barriers in key journeys or regulated workflows.
- Medium issues affect usability, comprehension, or completion for some users.
- Low issues are still accessibility defects but usually have lower immediate impact.
- Severity should be consistent across the report so teams can compare issues fairly.
Map each finding to the relevant standard
An accessibility report sample should show standards mapping. For a WCAG audit, each finding should identify the related success criterion and conformance level where appropriate. For regulatory or procurement contexts, the report may also need to connect findings to IS 17802, GIGW, Section 508, EN 301 549, or another applicable standard.
Standards mapping is important because it turns an issue list into audit-ready evidence. It also helps remediation teams understand why a fix is required, not only what visually appears wrong.
Remediation guidance should be practical
A weak report says that something failed. A useful report explains what should change. Remediation guidance does not need to write the full implementation for every product, but it should be specific enough for design, engineering, content, or document teams to act.
The best guidance explains the accessible outcome, not only the technical symptom.
- Explain the expected accessible behavior.
- Identify whether the issue belongs to design, engineering, content, or document remediation.
- Avoid generic instructions that do not match the affected component.
- Include implementation direction when a common fix pattern is known.
- Clarify when manual retesting is needed after remediation.
Retest status closes the audit loop
A report sample is stronger when it shows how remediation will be verified. Retest status connects the original finding to the fix and gives stakeholders evidence that the issue was resolved, partially resolved, or still open.
For compliance-sensitive teams, this matters because the value of an audit is not only finding issues. The value is creating a traceable path from discovery to remediation to closure.
- Original finding reference or issue ID.
- Remediation owner or responsible team.
- Retest date and result.
- Closure evidence such as screenshot, URL, document version, or test note.
- Remaining risk when an issue is deferred or only partially fixed.
Common signs of a weak sample report
When reviewing an accessibility audit report sample, look for missing evidence and vague language. A polished PDF can still be operationally weak if it does not help teams reproduce, prioritize, remediate, and retest findings.
The sample should make the audit methodology visible enough for a buyer to judge whether the report will be useful after the audit is complete.
- Only automated scan output with no manual review context.
- No clear scope, standards, or exclusions.
- Findings without user impact or expected behavior.
- Severity labels without prioritization logic.
- No remediation guidance or retest path.