Accessibility Audit Report Example: What a Useful WCAG Report Looks Like

If you have received an accessibility audit report, or you are about to pay for one, the hard part is knowing what a good one looks like. Some are a PDF of scanner flags with a logo on the cover. Others give a developer everything needed to reproduce, fix and verify each problem.

A useful accessibility audit report documents the scope and method of testing, each finding with its location and evidence, the WCAG success criterion it relates to, a recommended fix and a retest result. Below is a worked example for a fictional Shopify store, followed by how to read, prioritise and retest findings.

What Does an Accessibility Audit Report Look Like?

This is a short excerpt from the findings section of a report for a fictional store. Each row is one finding with its own ID, so the development team can discuss, fix and retest it individually.

Download the sample findings as a spreadsheet (CSV, fictional store). It has the full detail for all three findings, including observed behaviour, user impact and the recommended action.

The difference from a scanner export is the content of each row. A scanner flags that something may be wrong. A report documents what a person verified, what it means for users and what to do about it. The next sections show what sits behind each row.

What Should an Accessibility Audit Report Include?

The official W3C accessibility evaluation report template is a good reference for structure. In practice a useful report covers these sections:

The limitations section is the one most often missing, and it is the one that makes a report trustworthy. Any evaluation covers a sample of pages at a point in time. A report that says so is more reliable than one that implies everything was checked.

Accessibility Audit Report Example: One Finding Explained

Here is a single finding in full, written the way it would appear in the detailed findings section.

SH-001: Product variant selector is not keyboard operable

A developer could reproduce this in a minute, using steps like these:

1. Open the product page and press Tab until focus reaches the size options.
2. Try to select a size with Enter, Space or the arrow keys.
3. Note that no size can be chosen, so the purchase cannot continue.

Compare that with a weak report, which would say only "keyboard accessibility issue". The useful version describes the observed behaviour, explains the impact, maps it to a relevant criterion and gives the team a path to investigate. The criterion is 2.1.1 Keyboard, which requires that all functionality can be operated through a keyboard interface.

Example Accessibility Audit Findings for an Ecommerce Store

Findings differ by type. These two short examples fail for different reasons than SH-001, which is why a real report needs more than one kind of check.

SH-002: Checkout form error is not communicated in text

Observed: after submitting an invalid email address, the field border turns red. No message appears, and focus stays on the submit button.

Impact: screen reader users and people who cannot perceive the colour change are not told that an error occurred or how to fix it.

Mapping: 3.3.1 Error Identification (Level A), because the error is not described to the user in text. If a message appears without receiving focus, 4.1.3 Status Messages (Level AA) is also relevant.

Recommended action: add a text message beside the field that names the problem and suggests a correction. Link it to the field, and move focus to the first error or to an error summary.

SH-003: Cart drawer does not manage keyboard focus

Observed: opening the drawer leaves keyboard focus on the cart button behind it. Tab moves through the page underneath, and Escape does not close the drawer.

Impact: keyboard and screen reader users can lose their place and may be unable to reach or leave the drawer.

Mapping: 2.4.3 Focus Order (Level A), because the focus sequence does not preserve the meaning and operation of the opened drawer.

Recommended action: move focus into the drawer when it opens, keep Tab inside it while it is open, close it with Escape and return focus to the button that opened it.

How to Prioritize and Retest Audit Findings

When planning fixes, teams usually weigh four things:

• User impact: does the problem block a task, or only make it harder?
• Affected functionality: a barrier in checkout matters more than one on a rarely used page.
• Frequency: a problem in a shared template repeats on every page that uses it.
• Dependencies: one fix to a shared component can resolve several findings at once.

Labels such as Critical, High and Medium are a prioritisation system chosen by the evaluator. They are not official WCAG severity classifications. WCAG levels A, AA and AAA describe conformance levels, not how urgent a fix is, so a Level A failure is not automatically more urgent than a Level AA one for your store.

Retesting should record, for each finding, whether the specific issue is resolved and whether any related problems remain.

Accessibility Audit Report vs. Automated Scan Report

Automated scans are useful. They are fast, repeatable and good at machine-detectable problems such as missing text alternatives, missing form labels and some contrast failures. They cannot judge whether alternative text is accurate, whether a focus order makes sense or how a screen reader experience feels.

A broader evaluation includes manual testing and human review, and usually includes automated results as one input. The W3C Website Accessibility Conformance Evaluation Methodology describes the general approach: define the scope, explore the site, select a representative sample, evaluate it and report the findings. Our own process is set out in the audit methodology.

What to Ask Before Buying an Accessibility Audit

Before you commission a report, ask the provider:

• Which WCAG version and level will you test against?
• Which pages and user journeys are in scope, and how were they chosen?
• What is tested manually, and with which browsers and assistive technologies?
• Will each finding include reproduction steps and evidence?
• Can I see a sample report before I commit?
• Do you help with the fixes, or only report on them?
• Is retesting included, and how will you record the result?
• What does the report not cover?

Be wary of any provider that implies a report guarantees legal compliance. A report documents what was found at a point in time. It does not establish compliance on its own, and no provider can promise immunity from a legal claim. For more on comparing providers, see our guide to choosing an ADA compliance website audit service.