Accessibility report template — what a good one actually contains
”Accessibility report” means at least three different artefacts depending on who said it, and the gap between them is wide enough that a procurement officer and an engineering lead can sit through the same meeting and walk out wanting completely different things. The phrase covers the automated PDF an axe DevTools or WAVE scan dumps out the back of a build pipeline; the 60-page manual deliverable a specialist firm hands over after a six-week audit; and the industry-wide benchmarks like the WebAIM Million and the year-one EAA enforcement compilations.
This piece is about the first two — the artefact you commission, review, sign off on, and hand to your dev team. What follows is the structure a usable report has, the severity rubric that separates a working report from a stack of unactionable tags, and the finding format engineering teams will actually triage. Half the reports landing on accessibility leads’ desks in 2026 fail the test laid out below, and the failure is almost always the same shape: no scope, no rubric, no roadmap, no verdict — just a long list of WCAG references and the word “high” copied down a column.
Automated scanner reports, manual audit reports, and industry annual reports are three different artefacts. The field guide below catalogues the nine sections that make a deliverable one usable, with the same anatomy in each entry: what it contains, the example wording that anchors it, why it matters, the intended audience, and whether it is mandatory or recommended. The catalogue can be read top-to-bottom or jumped into by section number.
9 sections · what every good accessibility report contains
| ID | Section | Job | Required? |
|---|---|---|---|
| E·01 | Executive summary | One-paragraph posture verdict for sponsors | Mandatory |
| E·02 | Scope statement | What was tested — and what was not | Mandatory |
| E·03 | Methodology | Standard, audit type, tools, versions | Mandatory |
| E·04 | Conformance verdict | Pass / fail / N-A by success criterion | Mandatory |
| E·05 | Findings — the issue list | Every defect with ID, SC, severity, fix | Mandatory |
| E·06 | Severity rubric | Defined meaning of blocker / major / minor | Mandatory |
| E·07 | Remediation roadmap | Prioritised fix order with effort estimates | Mandatory |
| E·08 | Re-test policy | Schedule and triggers for revalidation | Mandatory |
| E·09 | Accessibility statement template | Draft public-facing statement, ready to publish | Mandatory |
Required = covered in both automated-scanner and manual-audit reports, with the caveat that scanners auto-stub or omit E·01, E·02, E·07, and E·09 because those sections require human judgement. The format of every section is the auditor’s choice; the presence of all nine is what makes a deliverable usable.
Three types of accessibility report — and which one you actually need
The vocabulary matters because vendors blur the categories on purpose. Three distinct artefacts are sold under the same phrase, and they answer different questions.
Automated scanner report. Produced by a tool — axe DevTools, WAVE, Lighthouse, Pa11y, or the free accessibility scanner on this site. Runs in minutes. Covers roughly 60 to 70 percent of WCAG 2.2 success criteria by surface area but materially less by user impact, because the highest-impact failures — keyboard traps, focus-order quality, screen-reader legibility, meaningful alt text — are largely outside what static analysis can decide. Useful as a baseline and a CI regression gate, not as a complete report on its own.
Manual audit report. Commissioned from a specialist firm or built internally, ideally with a pass by a manual audit by testers with disabilities. Takes four to eight weeks. Covers the 30 to 40 percent of WCAG that automation misses plus a human read on the rest. This is the artefact that establishes a defensible legal posture under the ADA Title III or the EAA and drives the remediation roadmap.
Industry annual report. WebAIM Million, EU eGovernment Benchmark, EAA year-one enforcement summaries. Sector-wide context, not a substitute for testing your own property.
If a stakeholder says “we need an accessibility report” without qualifying which one, ask. The cost difference between the three is roughly four orders of magnitude.
A report that omits the scope, the rubric, or the verdict is actively misleading, because the reader cannot tell what was tested, what severity means, or whether the property conforms.
Each entry below records the same things in the same order: what it contains, the example wording that anchors it, why it matters, the intended audience, and whether it is mandatory or recommended. A report missing any of the nine is incomplete; a report missing E·02, E·04, or E·06 is unusable.
Executive summary
One paragraph, plain English, no jargon. The non-negotiable element is a posture verdict — a single sentence that tells an executive sponsor whether the property conforms, partially conforms, or does not conform to the named standard. Below the verdict, three to five sentences naming the standard, the audit window, the count of blocker findings, and the headline of the remediation roadmap.
Executive sponsors need a verdict, not a temperature reading. The summary is the only page most non-specialist readers will open, and a report that buries the conformance posture under twelve pages of methodology preamble fails its primary job. The verdict sentence is also what regulators and procurement officers cite when they reference your report.
Scope statement
What was tested — URLs, page types, user journeys, devices, browsers, assistive technologies. And what was not — auth-walled pages outside the test account, PDFs, native mobile apps, third-party embeds. Every excluded surface is named, with the reason it was excluded (out-of-budget, no test credentials, deferred to follow-up engagement).
The scope statement is what stops a year-end audit being argued away on technicalities. If it is missing, the conformance claim is unfalsifiable — a plaintiff can point to any unaudited surface and claim the report is silent on it, and a defender cannot show otherwise. A scope statement also bounds the auditor’s liability: an exclusion you named is an exclusion the audited organisation accepted.
Methodology
Which standard — WCAG 2.2 AA, WCAG 2.1 AA, EN 301 549 v3.2.1, Section 508. Which audit type — automated, manual, mixed. Which tools and at which versions — axe-core 4.x, NVDA 2025.1, VoiceOver iOS 18, JAWS 2025. Which testing approach — WCAG-EM sampled walkthrough, full-template review, journey-based.
The methodology is what lets a re-test six months later compare like with like. Without a named tool version, a regression cannot be distinguished from a tool-update artefact. Without a named standard, a “conformance” claim is uninterpretable. The methodology section is also where an auditor’s competence is read by other auditors.
Conformance verdict
The formal conformance claim, by success criterion, in three states: passes, fails, not-applicable. WCAG 2.2 AA has 55 success criteria; every one should appear in this table. Not-applicable is a legitimate verdict — a site with no video does not need to pass 1.2.2 Captions — but every N-A needs a one-line justification.
This is what regulators and plaintiff’s lawyers read first. A report that fudges the verdict — “mostly conforms,” “in substantial compliance,” “on a journey toward accessibility” — is a report that loses in front of the DOJ or a member-state EAA enforcement body. The verdict table is also the input to the public accessibility statement, so a fuzzy table produces a fuzzy statement.
Findings — the issue list
The longest section in any real report. Every finding gets its own row with a stable ID, WCAG SC, severity, location, description, user impact, and recommended fix. The format is laid out in the “finding format” section further down. Findings are grouped by template or by severity, ranked by remediation priority, and cross-linked to the conformance verdict table.
The findings list is the part the engineering team actually opens. A report that buries its findings in narrative prose will never be triaged; a report that ships them as rows with stable IDs becomes a backlog of tickets. The stable ID is the load-bearing detail — it lets the same finding be referenced across the verdict table, the roadmap, and the re-test report twelve months later.
Severity rubric
A defined rubric that names what blocker, major, and minor mean in this specific report. Without a rubric, the severities are vibes. The recommended three-tier rubric — anchored in user impact rather than scanner confidence or legal exposure — is laid out in the rubric section further down.
Without a rubric, “high severity” means whatever the reader brings to it, and the rubric column becomes decorative. With a rubric, blocker means the same thing in finding F-001 as it does in finding F-247, and the roadmap can prioritise rationally. A rubric is also what stops scope creep during re-tests — a finding cannot be silently re-classified between cycles if its severity definition is written down.
Remediation roadmap
A prioritised fix order with rough effort estimates. Blockers first, then major, then minor; within each tier, fix the things that recur across templates first. Effort estimates can be coarse — small, medium, large in engineer-days — but they have to exist, because the roadmap is what turns the report into a programme.
A report without a roadmap is a stack of findings without an instruction for what to do next, and the audited organisation will quietly shelve it. A roadmap turns the report into a programme of work that can be tracked, resourced, and reported against in subsequent quarters. It is also the artefact that the monitoring buyer’s guide recommends as the input to a continuous monitoring configuration.
Re-test policy
When the report will be re-validated, what triggers an out-of-schedule re-test, and which findings will be re-tested. An annual full audit plus a six-month re-test on previously-failed criteria is defensible for most properties; products shipping daily need a tighter cycle.
A report without a re-test cadence is a report that is silently stale within twelve months. The EU Web Accessibility Directive expects published statements to be refreshed annually; the EAA and DOJ Title II both treat un-refreshed audits as evidence the organisation has stopped paying attention. A named cadence is also what protects an auditor against a future client asking why the previous report did not catch a regression that landed two months after the audit window closed.
Accessibility statement template
A draft public statement written from the audit findings, ready to publish at /accessibility/. The auditor has the facts, so the auditor drafts the statement; the audited organisation reviews and publishes. For examples of how published statements vary in quality, the accessibility statement audit catalogs the top 100 in 2026.
The statement is the public surface of the report and the only document most users will ever see. Drafting it as part of the report — rather than leaving the audited organisation to translate findings into public language six months later — is what closes the loop between audit and public posture. It is also the EAA compliance artefact under Article 7, and one of the documents the DOJ’s 2024 Title II rule expects to be available on request.
A severity rubric that actually works
Most reports use “high / medium / low” without defining what those words mean, which makes the severity column decorative rather than load-bearing. A working rubric is anchored in user impact, not in scanner confidence and not in legal exposure.
Blocker. Users with the relevant disability cannot complete the journey at all. A keyboard trap on checkout. A screen reader that does not announce a critical form field. A modal that captures focus and cannot be dismissed without a mouse. The user has to abandon or get help.
Major. Users can complete the journey, but with significant friction or substantially less information than a sighted, mouse-using user. Focus order that jumps unpredictably. Error messages that appear visually but are not announced. Contrast below 4.5:1 across large parts of the page. The journey completes, but the experience is materially degraded.
Minor. An accessibility issue that does not block or substantially degrade the journey. A decorative image missing alt="". A landmark missing its label. An AAA-only issue surfaced as informational. These belong in the report but sit at the bottom of the remediation queue.
A note on legal severity. Some legal departments push for a parallel “legal severity” tier weighted by class-action exposure rather than user impact. That is fine — but keep it as a separate column. Conflating the two produces a report the dev team distrusts and the lawyers over-rotate on.
A finding format that engineering teams will actually use
A finding is a row, not a paragraph. The required fields:
| Field | Example |
|---|---|
| Finding ID | F-014 |
| WCAG SC | 1.4.3 Contrast (Minimum) |
| Severity | Major |
| Location | https://example.com/checkout — button.cta-primary (see screenshot F-014.png) |
| Description | Primary CTA text renders at 3.2:1 against the orange background; WCAG AA requires 4.5:1. |
| User impact | Users with low vision and users in bright outdoor light cannot read the button label. |
| Recommended fix | Darken the background token from #F2994A to #C95F0A, or change the text to dark navy. |
Every row that omits the user-impact sentence will be deprioritised by engineers asking “what does this actually break?” Every row that omits a recommended fix will be deprioritised by product managers asking “what’s the call here?” A report that gets triaged is a report that fixes things; a report that does not is a stack of severity tags.
The “scanner output” version — what’s different
For an automated scanner report — the PDF that a CI run, a free accessibility scanner, or a monitoring platform produces — sections E·01, E·02, E·07, and E·09 are usually absent or auto-stubbed. The value of a scanner report is in E·04 and E·05: a machine-readable list of failed success criteria and findings keyed to DOM selectors. The scanner cannot draft a useful executive summary, cannot make a scope decision, cannot prioritise a roadmap, and cannot write a statement any lawyer would sign off on.
That is fine — a scanner report is the raw input to a complete accessibility report, not a substitute. Some monitoring platforms now layer the missing sections on top of scan output; that is closer to a complete artefact, but the summary and the roadmap still need a human read before publication.
The downloadable template
A working markdown template maps one-to-one to the nine sections above:
# Accessibility report — [Property] — [Date]## Executive summary— one paragraph plus the verdict sentence## Scope— URLs, journeys, devices, ATs; explicit out-of-scope list## Methodology— standard, audit type, tools, versions## Conformance verdict— table of all WCAG 2.2 AA SCs with pass / fail / N-A## Findings— one subheading per finding, fields per the format above## Severity rubric— blocker / major / minor definitions used## Remediation roadmap— prioritised list with effort sizing## Re-test policy— schedule and triggers## Accessibility statement (draft)— ready-to-publish version
A future iteration of this page will host downloadable .md and .docx versions; for now the structure above is the canonical reference. The accessibility statement audit catalogs how the top 100 statements vary — the gap between good and bad tracks closely to whether the underlying report had a defined scope and a real rubric.
What these 9 sections have in common
Every one of the nine sections does the same underlying job: it converts a piece of evidence into a piece of language that can be quoted, audited, and held against the audited organisation twelve months later. The executive summary converts a 60-page review into a verdict. The scope statement converts the auditor’s actual coverage into an unfalsifiable bound. The methodology converts a process into a repeatable comparison baseline. The verdict table converts WCAG conformance into 55 atomic claims. The findings convert defects into triageable rows. The rubric converts severity from a vibe into a definition. The roadmap converts findings into a programme. The re-test policy converts the report from a snapshot into a cadence. The statement template converts the internal report into a public posture.
The reports that fail in 2026 fail because they skip the conversion step. They quote a WCAG number without translating it into “what does this actually break for which users.” They tag findings “high” without translating “high” into a definition. They produce a verdict without producing the scope it applies to. Each missing translation step is a place where the report becomes unfalsifiable — and an unfalsifiable accessibility report is not a deliverable, it is a marketing artefact.
The deeper pattern is that an accessibility report is read at four very different distances. The executive sponsor reads E·01 and never returns. The procurement officer reads E·02, E·03, and E·09. The engineering lead reads E·05, E·06, and E·07. The auditor reading the report twelve months later reads E·03, E·04, and E·08. A report that does not work at all four distances is one that fails at least one of those readers, and the reader who fails is usually the one with the budget.
What to do first
Practical actions for accessibility leads in 2026
- Run the free accessibility scanner on three representative templates to produce a baseline findings list in section E·05 format — this is the minimum-viable artefact and it costs nothing.
- Commission a manual audit by testers with disabilities for the full nine-section report. Insist on E·02, E·06, and E·07 as deliverable acceptance criteria.
- Publish the draft accessibility statement from E·09 at
/accessibility/within four weeks of the report. Do not let it sit unpublished. - Stand up continuous monitoring per the monitoring buyer’s guide to catch regressions between the annual report and the six-month re-test.
- Diary the re-test from E·08 into the engineering calendar — not the legal calendar — and treat it as a release gate.
A usable accessibility report is the one a regulator can read in five minutes (E·01, E·02, E·04), an engineer can triage in a sprint (E·05, E·06, E·07), and an auditor can re-run in a year (E·03, E·08). A useless one is the one that quotes WCAG numbers without translating them into language any of those readers can act on. Half the reports landing on accessibility leads’ desks in 2026 fail that test, and the failure is almost always the same shape: no scope, no rubric, no roadmap, no verdict.
Frequently asked questions
What should an accessibility report include?
A complete report contains nine sections: an executive summary with a posture verdict, a scope statement, a methodology section naming the standard and tools, a conformance verdict by success criterion, a findings list, a severity rubric, a remediation roadmap with effort estimates, a re-test policy, and a draft accessibility statement. A report missing the scope, the rubric, or the verdict is unusable — the reader cannot tell what was tested, what “severity” means, or whether the site conforms.
What’s the difference between an accessibility report and an accessibility statement?
An accessibility report is an internal deliverable — usually 30 to 80 pages — documenting an audit’s findings, severities, and roadmap. An accessibility statement is the short, public-facing page at /accessibility/ summarising the conformance posture, the standard, the audit date, the known exceptions, and the contact route for users who hit a barrier. The report produces the statement; the statement is not the report.
How long is a typical accessibility report?
A manual audit report for a small marketing site runs 25 to 40 pages. A report for a complex authenticated product across multiple journeys can reach 80 to 150 pages because the findings section grows with the number of templates reviewed. The narrative sections combined occupy roughly 10 to 15 pages regardless of site size. The rest is findings.
Are accessibility scanner reports legally sufficient?
No. Neither the DOJ’s 2024 Title II rule nor the European Accessibility Act treats automated scanner output as a complete accessibility report. Scanners detect roughly 30 to 40 percent of WCAG issues — primarily contrast, missing alt text, missing labels, and document structure. The remaining 60 to 70 percent require human judgement. A scanner report is raw input to a full report, not a substitute.
How often should we re-issue an accessibility report?
A full manual audit and report cycle every twelve months is the working baseline for most properties. A re-test on the previously-failed criteria at the six-month mark is good hygiene. Any significant template change, redesign, or framework migration should trigger a delta audit. Continuous monitoring runs between reports so regressions surface immediately.
Does WCAG require a specific report format?
No. WCAG specifies success criteria; it does not prescribe the format of any audit deliverable. The W3C publishes EARL and WCAG-EM as structural references, but neither is mandatory under the ADA, EAA, AODA, or any other regime. The regimes expect a report to name the standard, the scope, the methodology, and the verdict — the format around those facts is the auditor’s choice.
MethodologySection model derived from the WCAG-EM evaluation methodology, IAAP audit-report references, and 30+ published accessibility statements surveyed in /articles/accessibility-statement-audit-top-100/.
ScopeThis is a report-format guide, not a legal compliance checklist. Consult competent counsel for jurisdiction-specific reporting obligations under the ADA Title III, the EAA, or other applicable regimes.