What an accessibility audit report should contain, with a template

An accessibility audit report should say what was tested and how, list every failure with enough evidence to find it again, and give each one its WCAG criterion, a severity and a fix. It should give a result for every criterion in the target, including the ones nobody checked.

Then it should record each retest, so a finding can be closed. This post goes through each part, writes out one finding in full, and ends with a Markdown template you can copy.

How an accessibility audit runs, from scope to retest, is in our guide to website audits. This post is about what you get at the end, whether you write the report or receive it.

The parts of a useful report

W3C’s evaluation methodology, WCAG-EM 2, published as a Group Note on 23 July 2026, requires one thing of the report: document the outcome of each step, from scope to evaluation. Its other reporting steps are optional: recording the evaluation specifics (archiving the samples and recording the tools, browsers, assistive technology and methods used), an evaluation statement, an aggregated score and a machine-readable report. W3C’s own template for evaluation reports has eight sections, from an executive summary to appendices for tool output. A report that works as a tool for fixing has these parts:

1. A summary a manager can read in two minutes.
2. The scope: what was in, what was out, and why.
3. The sample: every page tested, and why it is there.
4. The method: who tested, with which tools, browsers and assistive technology.
5. A result for each criterion in the target.
6. The findings, one block each, with evidence.
7. The severity scale the findings use.
8. The limitations: what the audit cannot tell you.
9. A retest log, filled in after each round of fixes.

Scope and sample

The scope says what the results apply to. Name the domains and sections, the signed-in areas, and any documents such as PDFs. Say which third-party content was tested: a chat widget, a map, a payment form or an embedded video is part of your page to the person using it. Name the target, a WCAG version and level such as WCAG 2.2 Level AA, and the screen widths tested. If something is out of scope, say why, so nobody reads silence as a pass.

The sample lists every URL tested and the reason each one is there. WCAG-EM builds a sample from common pages, essential functionality, the different types of page and the technologies they rely on, the steps of complete processes such as checkout, and a random sample 10% the size of the structured one. A reason per row, such as “product page template” or “checkout, step 3 of 4”, lets the reader see what each result stands for. A finding on a product page template probably applies to every product page; a finding on the home page may apply only there.

List the states too: errors shown, menus and dialogs open, signed in or out. A form tested only empty has not been tested with its error messages. If you are commissioning the audit, our scope worksheet for an audit request asks for the same facts before anyone quotes.

Method: who tested, and with what

W3C’s template asks for the evaluation tools and their versions, and a description of the manual review. Versions matter: a rule can change between releases, and a retest with a newer tool can find something new that is not a regression.

Name the evaluators and their contact details. List the manual checks, such as keyboard only, zoom, text spacing and reflow, and the assistive technology used, as screen reader and browser pairs. Then mark each finding with the layer that found it: an automated rule, a manual check, or a test with assistive technology. A reader who knows which criteria a rule can decide and which need a person can then judge each result for themselves.

A result for every criterion

A report that lists only failures leaves every other criterion unknown. Did it pass, or did nobody look? W3C’s WCAG-EM Report Tool records one of five results for each criterion, and they are worth copying:

• Passed: the criterion is met on the sample.
• Failed: at least one instance does not meet it.
• Cannot tell: the evaluator could not decide.
• Not present: the sample has no content the criterion applies to, such as no video for the captions criteria.
• Not checked: nobody tested it.

“Not checked” is the honest result for anything outside the method. If the audit was automated only, most criteria belong there, or under “cannot tell”. An automated rule that finds no failure has not shown that the criterion passed: it has shown that the rule found nothing in the states it reached.

WCAG-EM lets a report give an aggregated score, as an option, and warns that such scores “can be misleading and do not provide sufficient context”. The list of results says more than a number.

One finding, written out

WCAG-EM asks for at least one example of each criterion not met. For a report you can fix from, write up every instance, or every component that causes them. This is an invented example, on example.com:

### F-07: Help text below the card number field fails contrast​- Criterion: WCAG 2.2 1.4.3 Contrast (Minimum), Level AA- Where: https://shop.example.com/checkout/payment  (checkout, step 3 of 4), at 390 and 1280 px wide- Element: the help text under "Card number",  selector #card-number-hint, from the PaymentField component- Evidence: text #949494 on background #ffffff, 16px, normal weight.  Contrast 3.03:1; the criterion requires 4.5:1.  Screenshot: findings/F-07.png- Found by: automated rule (axe-core 4.14 color-contrast),  confirmed by the evaluator with a contrast analyser- Reproduce: open the page, add any item to the basket, continue  to payment. The text is visible without interaction.- Who it affects: people with low vision or reduced contrast  sensitivity, and anyone reading in bright light. The text  explains which card types are accepted.- Severity: medium. The information is also shown as card logos,  so nobody is blocked, but it repeats on every form that uses  the component.- Instances: 6 pages in the sample, all through PaymentField- Fix: change the hint colour token from #949494 to #767676  (4.54:1 on white) or darker. One change in PaymentField  fixes every instance.- Status: open

What makes it usable:

• The criterion with its version and level, so nobody argues about which WCAG applies. Contrast is measured as a ratio; see how WCAG measures colour contrast.
• Where, three ways: the URL, the screen widths and the selector, plus the component that renders it. The component turns six instances into one fix.
• Evidence a developer can check: both colours, the text size and the measured ratio against the required one. For a screen reader finding, write what was announced, with which screen reader and browser.
• How it was found, so the retest uses the same method.
• Steps to reproduce, including the state. A finding nobody can find again is hard to fix.
• Who it affects and why it got its severity, in the report’s own scale.
• A fix specific enough to act on: a value, an element or an attribute, not “improve contrast”.

Severity: define your own scale

WCAG gives each criterion a level, A, AA or AAA, but no severity: a criterion is met or it is not. Severity is the report’s judgment of how badly a failure affects people, and the report has to define its scale. This one works:

• Critical: someone cannot complete a task, with no workaround. A keyboard trap in checkout, a sign-in field with no label.
• High: a task is possible but very hard, or a serious failure repeats across many pages.
• Medium: content or a function is harder to use, but there is another way to get it.
• Low: a minor failure with little effect on completing a task.

A low-severity failure still fails the criterion. Severity orders the work; it does not change the result. Order fixes by severity, then by reach: a failure in a shared component or a page template affects every page built from it.

The summary

The summary is for the person who decides what gets fixed. Say what was tested and when, the target, the main patterns (“form errors are not tied to their fields on every form”), the blockers by finding ID, and what was not tested. Keep it to what the results support. W3C’s template has the summary say whether the site meets the target. Say it only of the sample, and only if every criterion in the target was evaluated and none failed, or could not be decided, on any page in it. Even then, WCAG-EM says a conformance claim cannot be made for a whole site from a sample alone, because pages outside the sample can still fail.

Record each retest

A finding is closed by a retest, not by a developer saying it is fixed. For each finding, record the date, the build or deploy tested, the method, the result and who retested it. Use the same method that found it: a failure a person found needs a person again.

Write the result as “no longer found”, “still found” or “partly fixed”. “No longer found” is the accurate wording: a retest shows the failure is gone from what was tested, not that the fix works for everyone. Run the random sample again too, because a fix in a shared component can break a page you did not look at.

The template

Copy this, delete what does not apply, and keep the numbering so readers can cite sections. The results table needs one row for each criterion in the target: 55 rows for WCAG 2.2 Level A and AA.

# Accessibility audit report: [site or product name]​## 1. Summary- What was tested: [site, sections, dates]- Target: WCAG [2.2] Level [AA]- Overall: [the main patterns, in a few sentences]- Blockers: [findings that stop a task, by ID]- Not tested: [what is outside this audit, in one line]​## 2. Scope- In scope: [domains, sections, signed-in areas, documents]- Out of scope, and why: [...]- Third-party content: [chat, maps, payment, video; tested or not]- Screen widths: [for example 320, 390, 1280 px]​## 3. Sample| # | URL | Why it is in the sample | Width(s) ||---|-----|-------------------------|----------|| 1 | [/] | [common page: home] | [all] || 2 | [/products/example] | [type of page: product template] | [all] || 3 | [/checkout/payment] | [process: checkout, step 3 of 4] | [all] || 4 | [/blog/example-post] | [random sample] | [all] |​States tested: [errors shown, menus open, dialogs open, signed in]​## 4. Method- Evaluator(s): [name, organisation, contact]- Automated tools and versions: [...]- Manual checks: [keyboard, zoom, text spacing, reflow, ...]- Browsers and assistive technology: [screen reader + browser  pairs, voice control, magnification]- Dates: [start to end]​## 5. Results by criterion| Criterion | Result | Findings ||-----------|--------|----------|| 1.1.1 Non-text Content (A) | [Passed / Failed / Cannot tell / Not present / Not checked] | [IDs] || ... one row per criterion in the target ... | | |​## 6. Findings[One block per finding, highest severity first; see F-07 above]​## 7. Severity scale used in this report- Critical: [...]- High: [...]- Medium: [...]- Low: [...]​## 8. Limitations[What this audit cannot tell you: pages outside the sample,assistive technology not in the list, content added after the dates]​## 9. Retest log| Date | Build or deploy | Finding | Method | Result | By ||------|-----------------|---------|--------|--------|----|| [date] | [commit or release] | [F-07] | [rule + manual] | [No longer found / Still found / Partly fixed] | [name] |​## Appendix[Raw tool output, screenshots, the archived sample pages]

If you want a form instead, W3C’s WCAG-EM Report Tool walks you through the WCAG-EM steps in your browser and downloads the report as HTML or JSON. It does not test anything for you, and it does not save as you go, so download your work often.

When a buyer asks for a VPAT or an ACR

Procurement teams often ask for an Accessibility Conformance Report (ACR) instead. An ACR is a completed VPAT, a template published by the Information Technology Industry Council. For each criterion, an ACR states a level such as Supports, Partially Supports, Does Not Support or Not Applicable, with remarks.

The VPAT’s current version, 2.5Rev, comes in four editions: one for WCAG 2.0, 2.1 and 2.2; one for the US Section 508 standards, which take in the WCAG 2.0 Level A and AA criteria; one for EN 301 549; and an international edition that combines the three.

An ACR is a summary of conformance for a product. An audit report is the evidence behind it. Write the audit report first; an ACR written without one is a set of claims nobody can check.