Accessibility audit report template, with a free sample PDF

Most accessibility audit reports fail at the first page. The client opens a PDF full of rule ids and selectors, cannot tell what is urgent, and forwards it to a developer who has even less time. The report that gets acted on is the one that answers three questions in order: how bad is it, what do we fix first, and what exactly do we change.

This page lays out a structure that does that. It is the structure the Websight Chrome extension uses for the reports it generates, but you can follow it in a Word document or a spreadsheet just as well. The sample below is a real generated report, not a mock-up.

The nine sections, in order

1. Cover: the answer before the question

The cover carries the client's name, the site, the date, the score and the issue counts by impact, plus who prepared it. That is all a client needs to decide how worried to be. Put your own logo and contact line on it: the report is a deliverable, and it should look like one.

Put the honesty line on the cover too. Websight prints "Automated tools find only part of the accessibility problems. This is not a certificate of legal compliance." on every page. It protects the client from over-reading the result, and it protects you.

2. Executive summary: four sentences a manager will read

What was scanned, when, what it scored, what the biggest problems are, and what fixing the top three would do. Written for someone who will never open the detail. Example from the sample:

We ran automated accessibility scans on 3 pages for Harbour Bakery on 21 October 2026. The average score was 48 out of 100 (many issues to fix). The scans found 8 issue types affecting 39 elements in total. By severity, the issue types are: 3 critical, 5 serious. 5 issue types appear on more than one page and are listed once in the site-wide section. Suggested first priorities: images must have alternative text; form elements must have labels; buttons must have discernible text.

3. Prioritised fix list: the order of work

One table. Each row is an issue type, with its impact, how many elements and pages it affects, and the score gain from fixing it. Sort by impact first, then by how many elements it touches. This table is what the developer prints out.

Where several elements share a pattern (the same card component on every page, for example), say so: "fix once in your template, 9 elements across 3 pages". A fix list that says "9 problems" when the real work is one line in a shared template will make the job look bigger than it is.

4. Site-wide issues: fix the template, fix every page

Issues that appear on more than one scanned page almost always come from a shared header, footer, navigation or stylesheet. List them once, with the pages they affect, rather than repeating them per page. For each issue give:

• What is wrong, in the words of the rule (for example "Images must have alternative text").
• Why it matters, in terms of a person: "Someone using a screen reader hears nothing useful, or just a file name, so they miss what the image shows."
• The WCAG 2.2 criterion and level (1.1.1 Non-text Content, level A), so the client can look it up and so the finding is traceable.
• How to fix it, as an instruction and ideally as a code snippet: the element's own markup, then a corrected version. Label it a draft: a suggested alt text generated from the file name is a starting point, not the answer.
• The affected elements: selector, a short HTML snippet, and if you can, a small screenshot of the element in place. Screenshots turn "img:nth-child(3)" into "the photo of the sourdough loaf".

5. Page-by-page issues

Then each scanned page in turn, with only the issues specific to that page, in the same format. Start each page with its own score and counts so progress can be tracked per page on the next scan.

6. Manual checks: what the scan could not decide

This is the section most reports leave out, and the one that makes a report honest. An automated engine cannot tell whether alt text is meaningful, whether the keyboard order makes sense, whether focus is always visible, or how a page sounds in a screen reader. Give the client a short list of those checks with tick boxes, so the report shows what still needs a person. Websight includes a 25-item list in every report; the free printable version is on this site.

7. Context: WCAG 2.2 and the law, carefully

One page of plain background: what WCAG is, what level AA means, and the legal landscape as general information. In the UK that is the Equality Act 2010 and the public sector regulations; in the EU the European Accessibility Act has applied to certain products and services since 28 June 2025, and its technical standard points to WCAG level AA. Say clearly that this is background, not legal advice, and that the report does not state whether the site meets any law. Then stop. Clients ask about the law; the honest answer is "here is the context, ask a qualified adviser about your situation".

8. Method and scoring

Which engine, which version, which rule set, which pages, and how the score is calculated. A score without a method is a number nobody can defend. Websight's method is published in full on how the accessibility score works; copy the idea if not the weights.

9. Appendix: raw data

For the developer: a CSV or JSON of every finding with page, rule, impact, selector, snippet and fix. It does not belong in the body of the report, but the person doing the work will thank you for it.

Writing it so it gets acted on

• Lead with people, not rules. "A screen reader user cannot tell which link goes to the menu" lands. "4.1.2 Name, Role, Value" does not, on its own. Include both, in that order.
• Count issue types, not elements, in the headline. Forty-two failing elements is often six problems. Say six, then show the forty-two.
• Give the fix as code where you can. A before-and-after snippet built from the element's own markup is faster to apply than a paragraph, and harder to misread.
• Show the score moving. "Fix these three and the score goes from 48 to 73" is the sentence that gets budget approved. It is also honest, as long as you say it is a projection from the automated score only.
• Say what you did not test. Which pages, which states (logged out only? no checkout?), and that automated checks cover only part of WCAG. The client's lawyer will ask; the report should already have answered.
• Date it and keep it. A dated series of reports is a record of progress. Re-scan after the fixes and send the difference.

Words to avoid

"Compliant", "certified", "guaranteed", "fully accessible", "passes WCAG". None of these can be supported by an automated scan, and some cannot be supported by any audit short of a full conformance evaluation. Use "found", "fixed", "remaining", "needs a person to check". If a client wants a conformance report in a formal format, that is a different, larger piece of work done by a specialist.

Questions

Or generate it

Websight builds every section above from a scan of the pages you open in Chrome, with your logo and name on the cover, on your computer. The scan, score and suggested fixes are free; the PDF report, multi-page audits and exports are in Pro, a paid upgrade with a free trial. See what is in Free and Pro.