For agencies

What belongs in an accessibility audit report

Most accessibility reports are either a wall of screenshots nobody reads or a score out of a hundred that means nothing. Here is a structure that has survived contact with real clients, and the sentences that keep you out of trouble.

1. What was tested, and how

Name the pages, the method, and the limits. For example: "Twelve pages were checked: the home page, the four templates, the checkout flow, and the contact form. Six were checked automatically by reading the HTML; three were tested by keyboard only; two were read with NVDA; colour contrast was measured on the template colours." A client who understands the method trusts the findings; a client who does not think you ran one script and sent an invoice.

Say plainly what you did not do. If you did not test with a screen reader, do not imply it.

2. Findings, one per row, each with the evidence

The useful unit is: page, what is wrong, who it affects, the evidence, the fix, and how much work it is. Keep the evidence literal — the line of HTML, a screenshot of the element, the contrast ratio and the two colours involved. A developer should be able to act without a meeting.

PageProblemImpactEvidenceFix
/checkout Card error message is announced nowhere A blind customer cannot tell why the payment failed, so they abandon the order Screenshot + the error element's markup, which has no role and no aria-live Give the error a container with role="alert" and move focus to it

Group by severity, not by page, if the client will only fund some of it. Group by page if the client is a developer who will work through it page by page. Ask which, rather than guessing.

3. What a machine can and cannot find

Say it once, clearly: automated checks catch the mechanical problems — missing alt text, empty links and buttons, unlabelled fields, heading structure, table headers, frame titles, zoom-blocked viewports. They cannot judge whether alt text is useful, see colour contrast unless they render the page, know the real keyboard order, or say how any of it sounds in a screen reader. If your report mixes both without saying which is which, a client will treat the scan output as the audit.

4. A plan, not a verdict

Finish with sequence and cost: what to fix this sprint, what to fix next, what to do in the next build, and how you will re-test. A re-test is the part clients remember, and it is the reason to keep working with you rather than the last freelancer.

Sentences to avoid

What to write instead: "The following twelve problems were found and fixed; the site now has no mechanically detectable errors of these kinds. Automated checks cover roughly a third of what a full audit finds, and we recommend keyboard and screen-reader testing of the checkout flow next."

Pricing the work, briefly

Charging by the finding is a trap: a bad page can produce two hundred findings. Charge for the audit as a fixed fee based on page templates, not pages, and charge for remediation separately, because you cannot know how a page builder will fight you until you start. Monitoring is the third line item and the one that pays every month: sites change weekly, and a client who pays for monitoring does not come back a year later with a lawsuit and a bad mood.

Where our tool fits

AccessAudit produces the mechanical part of this report automatically, with the offending markup quoted so anybody can check it, and it keeps monitoring your client sites and tells you what broke since last time. It deliberately stays silent about the parts only a person can judge, and it never writes the sentence "compliant" anywhere.