The audit is finished and a document lands in your inbox: forty pages, a summary chart, and a long table full of numbers like 1.3.1 and 4.1.2. You paid for it, or your lawyer asked for it, and now you have to decide what to do with it. Most owners skim the summary, feel a little alarmed, and forward it to whoever maintains the site.
That is a reasonable start, but an accessibility audit report is more useful once you can read it yourself. You can then judge whether it is thorough, ask better questions, and make sure the fixes go in the right order. This post explains how to read an accessibility audit, section by section, and what should make you suspicious.
The sections a useful report contains
Formats vary, and that is fine. What matters is that you can find each of these somewhere in the document.
- Scope. Which pages, templates, user journeys and documents were tested, on what date. “The website” is not a scope. “Home, three service pages, blog post template, contact form, booking flow and two PDFs, tested in October” is.
- Standard and level. Normally Level AA, measured against version 2.1 or 2.2 of WCAG. The report should name the version.
- Method. Whether automated tools were used, which manual checks were run (keyboard, screen reader, zoom and reflow, content review), and by whom in general terms.
- Test environment. Browsers, devices and screen readers. Results can differ between NVDA with Firefox and VoiceOver with Safari, so this matters when someone tries to reproduce an issue later.
- Summary. A short plain-language account of the main barriers and their effect on users. This is the part you can hand to a board or a partner.
- Issue list. The bulk of the report, covered below.
- Exclusions and limits. What was not tested: logged-in areas, third-party widgets, a payment page hosted elsewhere. An honest report states its limits.
Anatomy of one issue
Every finding should give a developer enough to fix it without guessing, and give you enough to understand why it matters. A well written entry looks something like this:
| Field | Example |
|---|---|
| Title | Mobile menu button has no accessible name |
| Location | All pages, site header, below 768 pixels wide |
| WCAG reference | 4.1.2 Name, Role, Value (Level A) |
| Severity | High |
| Who is affected | Screen reader users on phones and small screens |
| Steps to reproduce | On iPhone with VoiceOver, open the home page in Safari, swipe to the menu icon; it is announced as “button” only |
| Expected | Announced as “Menu, button, collapsed”, then “expanded” when open |
| Recommendation | Add a text label to the toggle and update aria-expanded when the menu opens |
Notice that it says where, how to see it, what it should do instead, and roughly how to fix it. Some reports add a screenshot or a code snippet. If most of your entries are missing the steps to reproduce, the person fixing them will spend time rediscovering problems the auditor already found.
How severity is usually rated
There is no single official severity scale, so each auditor uses their own. Most look something like this, judged by the effect on a real person trying to complete a task.
| Rating | Meaning | Typical example |
|---|---|---|
| Critical or blocker | Some users cannot complete a key task at all | Checkout button unreachable by keyboard |
| High | The task is possible but very hard, or key information is missing | Form errors shown only in red, never announced |
| Medium | Causes confusion or extra effort | Several “read more” links with no context |
| Low | Minor friction, little effect on completing tasks | A decorative icon read aloud by screen readers |
Severity should be tied to where the problem is, not just what it is. Missing alt text on a decorative blog image and missing alt text on the only image that shows your opening hours are the same criterion and very different severities. A report that marks everything critical has not done the work of ranking.
Reading the WCAG references
The numbers point to WCAG success criteria. The first digit is the principle (1 perceivable, 2 operable, 3 understandable, 4 working with assistive technology), the second is the guideline, the third is the specific criterion. Each comes with a level. Level A and AA failures are what an AA audit is measuring; AAA items, if listed, are advice.
One problem can fail more than one criterion. An unlabeled custom checkbox might be listed under 1.3.1, 3.3.2 and 4.1.2. That is normal and not padding, though good reports group it as one issue with several references rather than three separate rows. If the numbers mean nothing to you yet, our plain explanation of what WCAG is and how it is organized will help, and the W3C publishes the full text of WCAG 2.2 with an explanation for every criterion.
Checking an issue for yourself
You do not need to verify every row, but checking a few tells you a lot about the report’s quality.
- Pick three issues: one high, one medium, one keyboard-related.
- Open the listed page in the listed browser.
- Follow the steps exactly as written.
- Compare what you see or hear with the “actual” description.
- If you cannot reproduce it, ask the auditor. The page may have changed, or the steps may be incomplete.
Keyboard findings are the easiest to confirm with no tools at all; our post on testing with only a keyboard shows the keys to use.
Red flags in an accessibility audit report
- It is just scanner output. Pages of automated results exported into a PDF, with no keyboard or screen reader findings. That is a scan, not an audit.
- No scope or no dates. You cannot tell what was covered or when.
- Vague issues. “Improve color contrast site-wide” without saying which text, where, or what the current ratio is.
- A score or a pass badge as the headline. WCAG conformance is not a percentage. A page conforms or it does not; a report can summarize issues by count, but a “92 score” on its own says very little.
- Promises of legal safety. An audit documents barriers. It cannot certify a site as ADA compliant, because there is no such official certification, and it cannot protect you from a claim.
- Everything recommends one product. If every fix is “install our widget”, the report is a sales document.
Turning the report into a plan
Once you trust the accessibility audit report, sort its issues by severity first, then by how many pages they touch. A header or footer problem fixed once in the theme can clear dozens of rows. Content issues such as alt text and link wording can often be fixed by your own staff while a developer handles templates and forms. Our accessibility remediation page explains how that division of work usually goes.
Keep the report and a record of each fix with its date. A retest against the same issue list closes the loop, and the results feed directly into an honest accessibility statement. If you received this report because of a demand letter, the legal reply is your lawyer’s job; this post is not legal advice. For the wider topic, our ADA website accessibility help hub links everything together, and the group guide on accessibility testing shows how the findings in a report are produced.
Frequently asked questions
Is a longer audit report a better one?
Not necessarily. Length follows scope and the number of problems found. A small site with a few templates may produce a short report, and a large store with many journeys a long one. What matters is that each issue is specific, located and reproducible, and that the scope and method are stated clearly.
Should the report include fixes or only problems?
A useful report gives at least a short recommendation for each issue, so a developer knows the direction to take. It does not need to include finished code. Some auditors also offer to retest after fixes, which confirms the work and gives you a dated record of what changed.
Can an audit report be used to fill in a VPAT?
Often, yes. A VPAT is a template, and the completed version is called an Accessibility Conformance Report, which summarizes how a product supports each WCAG criterion, often for procurement. The detailed findings in an audit report are the evidence behind each line of that summary, so ask the auditor to map every issue to its criteria.
What if two audits of my site disagree?
Different scopes, dates, tools and testers produce different findings, and severity is partly judgment. Compare the specific issues rather than the totals. If one report lists a problem the other missed, try reproducing it. The goal is the most complete picture of real barriers, not a winning report.
A report is only the map; the work is in confirming and fixing what it shows. If you would like the manual findings checked or retested by someone else, our manual accessibility testing service can go through your existing report against the live site.
Next in this series: Free ADA Compliance Checker Sites: What the Score Means
