How to Read an ADA Audit Report Without Getting Overwhelmed

The report is a map, not a verdict

The first reaction to an accessibility audit report is usually the page count. Dozens of findings, codes like 1.4.3 and 4.1.2, severity columns, screenshots. It reads like a failing grade.

It is not a grade. It is a map of where visitors hit friction, drawn so that someone can fix the friction in a sensible order. Read it that way and the document gets dramatically smaller.

This article walks through the parts that matter, in the order a busy owner should read them.

Distinct issues versus instances

The single most important distinction in any audit report is between an issue and an instance.

An issue is a pattern: form fields are missing labels. An instance is each place the pattern appears: the same unlabeled search box, repeated in the header of ninety pages.

A report that says four hundred findings usually means a handful of issues with large instance counts. That is good news twice over. The problem list is short, and a fix at the template or component level clears hundreds of instances at once.

So before reacting to any total, find the number of distinct issues. That number is the real size of the project.

What severity actually encodes

Severity labels like critical, serious, and moderate rank how badly the barrier blocks a visitor.

A critical finding generally means someone cannot complete a task at all. A form that cannot be submitted from a keyboard. An image-only menu with no text alternative. A serious finding makes a task painful but survivable. A moderate finding adds friction.

Severity is about impact, not legal exposure, and an honest report will not pretend otherwise. The practical use is sequencing. Critical findings on the pages where customers contact, book, or buy come first. A moderate finding on the homepage may still outrank a serious one on a page nobody visits.

Severity multiplied by where the finding lives is the real priority. Good reports do part of that math for you by listing which pages each finding affects.

Decoding the WCAG references

Every finding should cite a WCAG success criterion, written like 1.4.3 or 2.1.1.

You do not need to memorize the standard. The references do two jobs for you. They prove the finding is grounded in the published standard rather than someone’s taste, and they give your developer the exact requirement to look up, complete with documented techniques for meeting it.

A loose translation guide helps. References starting with 1 concern whether content can be perceived, like text alternatives and contrast. References starting with 2 concern whether the site can be operated, like keyboard access and focus. References starting with 3 concern whether things are understandable, like labels and error messages. References starting with 4 concern whether the code speaks correctly to assistive technology.

Detected versus needs verification

A trustworthy report is explicit about how each finding was established.

Some checks are objective. A contrast ratio is measured. A missing alt attribute is a fact. These arrive as confirmed findings.

Other checks are detections that deserve a human look. Automated tools flag suspicious patterns that are sometimes legitimate in context, and an honest report labels these as needing manual verification instead of inflating the confirmed count.

If a report presents every automated flag as a proven violation, be skeptical. False positives in accessibility scanning are a known reality, and reports that acknowledge them are the ones taking accuracy seriously.

Turning findings into a work order

Here is the conversion that makes the report actionable.

Group the findings by pattern, which a good report already does. For each pattern, note the fix location: a theme file, a shared component, a template, or a vendor widget. Order the groups by user impact on the pages that earn trust or revenue.

The result is usually a one page work order: fix the form labels in the contact component, raise the gray text color in the theme, restore the focus outline, add alt text to the product images, replace the menu PDF with real text. Each line has a finding count attached, so progress is measurable.

Hand that to the developer with the report itself. The screenshots and code references in the full document answer the questions the one page summary raises.

If the site runs on a page builder or a purchased theme, send the work order to the vendor as well. Many findings live inside templates the business never wrote, and vendors respond faster when the request cites the specific WCAG criterion and the affected component instead of a vague complaint about accessibility.

What to expect after the fixes

Remediation ends with a retest, not with a deploy.

Re-scan the affected pages and compare against the original findings. Counts should drop where work happened, and an unchanged count is a flag that a fix missed its target. Keep the before and after reports. They document a pattern of diligence and improvement, which is worth having regardless of why the audit started.

One caution applies to every report from every vendor. An audit does not certify a website as legally compliant, and a clean scan does not guarantee protection from complaints. What a good audit does is identify real barriers, tie them to the published standard, and support remediation toward WCAG 2.1 and 2.2 AA with evidence.

If you want to see what this looks like before committing, the sample audit report walkthrough shows each section with real findings. A free scan gives you a first findings list for your own site in about a minute, and the pricing page explains exactly what the paid report adds.