Accessibility audit report contents
An accessibility audit report documents what was evaluated, how the evaluation was conducted, what issues were identified, and what remediation each issue requires. The core audit report contents include project scope, methodology, WCAG version and conformance level, a detailed issue list with locations and severity, remediation guidance, and a summary of conformance status. A quality report gives a developer or project manager everything needed to understand and address each issue without guesswork.
| Element | What It Documents |
|---|---|
| Scope | Pages, screens, templates, user flows, and environments evaluated |
| Methodology | Evaluation approach including screen reader testing, keyboard testing, visual inspection, and code inspection |
| Standard | WCAG version and conformance level, typically 2.1 AA or 2.2 AA |
| Issue details | Description, location, WCAG reference, severity, and recommended fix for each issue |
| Summary | Conformance status, issue counts by severity, and prioritization guidance |
Project Scope
The report opens by defining what was evaluated. This section lists the specific URLs, templates, screens, or user flows included in the audit, along with the environments used, such as Chrome with NVDA, Safari with VoiceOver, or mobile browsers with assistive technology.
Scope matters because accessibility conformance claims only apply to what was evaluated. A report covering ten templates cannot speak to pages built from templates outside that scope.
Methodology
A report should explain how the evaluation was conducted. Professional audits combine several evaluation methods: screen reader testing with assistive technologies such as NVDA, JAWS, and VoiceOver, keyboard testing to confirm operability without a mouse, visual inspection at standard and zoomed views, and code inspection of HTML, CSS, and ARIA attributes.
Automated scans may appear as one input within a broader evaluation, but scans alone flag only about 25 percent of accessibility issues. The methodology section should make clear how much of the work was human-led.
Standard and Conformance Level
Every audit report should state the exact standard evaluated against. For most organizations this is WCAG 2.1 AA or WCAG 2.2 AA. The report should not use vague language like “accessibility standards” without a version and level attached.
This specificity matters for legal context. Title II of the ADA references WCAG 2.1 AA for state and local government web content, and procurement requirements often specify a particular version.
Issue Details
The heart of the report is the issue list. For each issue, a quality report includes:
- Description: what the issue is and how it affects users
- Location: the specific page, screen, or component, often with a code snippet or screenshot
- WCAG reference: the specific success criterion violated
- Severity: a rating reflecting user impact and risk
- Recommended fix: guidance on how to remediate, sometimes including sample code
Without this level of detail, a development team cannot act on the report efficiently.
Severity and Prioritization
Severity ratings help teams decide what to fix first. Most audit reports prioritize based on user impact (how significantly the issue blocks or degrades the experience for people using assistive technology) and risk factor (how likely the issue is to appear in a legal demand or complaint).
A report that lists 300 issues without prioritization forces the reader to guess where to start. A report with clear severity ratings turns the issue list into a work plan.
Conformance Summary
The closing section summarizes the conformance status of the evaluated scope against the stated standard. This typically includes total issue counts, counts by severity, counts by WCAG success criterion, and a plain-language assessment of where the product stands.
The summary is what executives and procurement teams usually read first. It should be accurate, specific, and tied directly to the evidence in the issue list.
What a Report Should Not Include
A credible audit report avoids pass or fail language for the product as a whole. Accessibility is evaluated criterion by criterion, and the report should reflect that granularity. It also avoids vague recommendations like “improve accessibility” without tying each recommendation to a specific issue and fix.
Reports that rely entirely on automated output, without human evaluation, cannot claim to cover WCAG conformance. The 75 percent of issues requiring human judgment will be missing.
A report that documents scope, methodology, standard, issues, severity, and remediation turns an audit from a deliverable into a working tool for the teams responsible for conformance.