What a Real $49 ADA Audit Report Looks Like (Section-by-Section)

Most accessibility audit reports are useless.

They list 200 errors. They cite WCAG criteria numbers with no context. They demand a developer read 80 pages of prose before touching a single line of code. And they are wrong about what actually needs fixing.

A good report is different. It tells you what is broken, what is systemic versus one-off, what comes from your code versus a plugin you installed, how to fix each issue with before and after code pairs, and what to escalate versus what to ignore. It treats your time as the constraint and your developer as the audience.

Here is exactly what the $49 report contains, section by section. If you have not seen the sample PDF yet, open it in another tab and follow along.

Cover page — the canonical audit binding

The cover carries four things that matter for auditability: your site URL, the accessibility risk score out of 100, the date of the scan, and the canonical audit ID. The canonical ID is the single source of truth that ties the PDF, the dashboard view, and the review demo together. If any two surfaces show different numbers for the same site, that ID is how you find out which one is wrong.

The score itself is a weighted technical risk indicator. Critical issues carry a 15-point penalty per instance. Serious issues carry 8. Moderate 3. Minor 1. It is not a legal determination. It is a prioritization tool.

Executive summary — one page, no prose

The executive summary tells you how many underlying issues were found, how many instances each propagated to, how many pages were scanned, and how the findings break down by severity. It also splits findings by ownership: site-controlled versus third-party. You will often find that a report claiming 94 errors actually resolves to 6 underlying problems. That framing matters. Six is a plan. Ninety-four is a panic.

The summary also states the engineering impact: how many component-level fixes will resolve multiple instances, how many page-specific fixes remain, and how many issues require vendor contact instead of developer time.

Priority findings — what to fix first

Findings split into four action buckets. Fix Now is verified failures that block assistive technology users. Fix Next is confirmed structural issues that degrade usability but do not fully block access. Review Before Assigning is anything that needs manual verification or involves design tradeoffs. Raise With Plugin Vendor is issues that originate in third-party markup and require a vendor conversation.

This is the most important framing in the report. It is the difference between a developer triaging 200 unrelated errors and a developer starting Monday with a clear sequence: fix the four template issues first, then look at the page-specific items, then send the three vendor emails.

Per-rule sections — the actual work

Each finding gets its own section with a consistent structure.

The section opens with a two-audience explanation. For owners describes who this affects and what they experience. For developers describes the technical remediation direction. Owners read the first, hand the report to their developer, and never have to translate a WCAG citation into English.

Root cause follows. This is where the report tells you whether you have ten separate issues or one template bug appearing in ten places. Most of the time it is the second. Fixing the template resolves all ten instances at once. The report says so explicitly.

Then a before and after code pair. Before (captured from your site) shows the actual markup that failed, with the failure summary axe-core returned. After (fix pattern) shows the remediation direction a developer can copy and adapt. When no code transform can be safely auto-generated — third-party markup, items needing manual verification, rules without a clean pattern — the After block still exists but carries guidance instead of code. You are never left with a before block and no after block.

The section closes with affected pages, user impact in one sentence, exceptions to the rule, and how to verify the fix worked.

Vendor emails — copy and paste

When the report flags issues coming from a third-party widget, embed, or plugin, it gives you a ready-to-send email template. Subject line, body copy, question list, and tone calibrated for vendor support teams. You copy, paste, and send. No writing, no guessing what to ask.

This is the single most commonly skipped artifact in other reports. Third-party issues are 10 to 30 percent of most sites' findings. Telling you "this is a YouTube embed issue" without giving you language to raise it with YouTube is a half-deliverable. The vendor emails close that gap.

WCAG criteria and remediation checklist

The back of the report lists every WCAG success criterion that was violated, with plain-English explanations of what each one protects and why it matters. This is useful for internal documentation, for responding to a demand letter, and for training a team going forward.

The prioritized per-instance repair checklist that follows is what your developer actually works from. Every instance the audit found, listed with its page URL, its CSS selector, its rule ID, and the fix direction for that specific element.

Closing page — next steps

The final page gives you three explicit paths forward. Open your review demo with a QR code and the 8-character key printed plainly. The review demo shows your site's most-affected pages rebuilt with the fixes applied, so you can see the corrected experience before anyone touches production. Ask about implementation if you want us to apply the fixes ourselves instead of handing the report to your developer. Run a free scan on another site for your second property, a client site, or a partner's domain.

What it does not do

The report is not a legal opinion. It is not a compliance certification. It does not guarantee that addressing every finding makes your site fully ADA compliant. Automated testing catches 30 to 40 percent of WCAG issues. The other 60 to 70 percent require manual testing with assistive technology, which you should do after the automated findings are resolved.

The report makes all three of these limits explicit on every disclosure page. Anyone offering you full compliance certification for $49 is selling something we are not.

Why this structure matters

A report's job is to cause action. The sections above are designed in sequence: understand your risk, see the priority bucket, look at the actual code, fix the template, send the vendor emails, run the review demo for internal buyin, move to implementation. Every section exists because skipping it is where most audits break down in practice.

You do not need a $5,000 consulting engagement to get this structure. You do not need a legal team on retainer. You need the report and a developer with a morning.