An auditor sample report shows you exactly what you’ll receive after an audit is complete. It should include identified issues mapped to WCAG success criteria, severity ratings, page or screen locations, code-level details, and clear remediation guidance. A strong sample report reads like a working document your developers can act on, not a stack of jargon. Reviewing one before you hire is the fastest way to gauge an auditor’s depth and clarity.
Most buyers skip this step. The ones who don’t end up with better outcomes.
| Section | What It Should Show |
|---|---|
| Scope | Pages, screens, or flows evaluated and the standard applied (WCAG 2.1 AA or 2.2 AA) |
| Issue Detail | Description of the issue, location, affected element, and user impact |
| WCAG Mapping | Each issue tied to a specific success criterion and conformance level |
| Severity | Ratings that support prioritization (critical, serious, moderate, minor) |
| Remediation Guidance | Recommended fix with code snippets or design notes where useful |
| Evaluation Method | How issues were identified and what tools and assistive tech were used |
Why review a sample report before hiring?
A sample report tells you more about an auditor than any sales call. It reveals depth of analysis, writing clarity, and how practical the output will be for your developers.
Some reports are dense PDFs filled with copy-pasted WCAG text. Others read like a working punch list with screenshots, code, and direct fix recommendations. The difference shows up immediately when your team starts remediation.
Ask any auditor for a redacted sample. If they hesitate or only show you a marketing brochure, that’s an answer.
Scope and methodology
The report should open with a clear statement of scope. Which pages or screens were evaluated. Which standard (WCAG 2.1 AA is most common, WCAG 2.2 AA is rising). Which environments (desktop, mobile, both). Which assistive technologies were used.
Methodology matters because it sets the credibility of every finding that follows. A manual audit conducted by a trained auditor identifies the full range of issues. Scans only flag approximately 25% of issues, so a report built on a scan alone is incomplete by definition.
Issue detail and WCAG mapping
Each issue in the report should answer five questions: what is it, where is it, who does it affect, which WCAG criterion does it map to, and how do you fix it.
Look for a plain-language description of the issue, the exact page URL, screen name, or component affected, the HTML, ARIA, or design element involved, the WCAG success criterion (e.g., 1.4.3 Contrast, 2.4.7 Focus Visible), and the user impact, especially for screen reader, keyboard, and low vision users.
If the report only lists WCAG criteria without describing the user impact, the auditor is treating accessibility as a checklist rather than an experience.
Severity ratings and prioritization
Not every issue carries the same weight. A missing alt attribute on a decorative image is different from a keyboard trap on the checkout button. A useful sample report assigns severity so your team knows what to fix first.
Common severity tiers include critical, serious, moderate, and minor. Some reports also use Risk Factor or User Impact prioritization formulas to combine severity with frequency and visibility.
Prioritization is where audit reports either become roadmaps or remain reference documents.
Remediation guidance
This is where reports separate themselves. A strong auditor sample report shows fix recommendations developers can act on without further interpretation.
That can mean a corrected code snippet, an ARIA pattern reference, a design adjustment, or a content edit. The goal is to give the implementer enough context that they’re not guessing.
Reports that only say “add alt text” or “fix contrast” without specifics leave the work undone.
Evidence and screenshots
Visual evidence speeds up remediation. Annotated screenshots, highlighted elements, and short notes on what’s wrong reduce back-and-forth between auditor and developer.
For mobile app audits, expect device screenshots. For web audits, expect browser captures with the issue circled or highlighted. The absence of visuals doesn’t disqualify a report, but their presence is a strong signal of quality.
Format and usability
Spreadsheet, PDF, or live document. Each has tradeoffs. Spreadsheets are filterable and easy to assign. PDFs are stable but harder to track. Live documents and platforms support ongoing work as fixes are validated.
Whatever the format, the report should be sortable by severity, WCAG criterion, and page. If your team can’t quickly answer “what should we fix first,” the format is working against you.
What a sample report should not contain
A few red flags: issues listed only by tool output without human review, WCAG references without descriptions, no severity ratings, no remediation guidance, generic boilerplate that could apply to any site, and claims of “full conformance” or “certification” attached to a single audit.
An audit identifies issues at a point in time. It is not a certification. Any auditor implying otherwise is overstating what an audit delivers.
How long should an auditor sample report be?
Length depends on the size of the asset audited. A small marketing site might generate 15 to 40 pages of findings. A large web app can produce hundreds. What matters is depth per issue, not page count.
Should the sample report be redacted?
Yes. Reputable auditors redact client names and sensitive details before sharing. A redacted report still shows structure, issue depth, severity treatment, and remediation quality. That is what you’re evaluating.
Can I ask for more than one sample?
You can, and you should if the work involves multiple asset types. A website report and a mobile app report will read differently. Seeing both helps you judge whether the auditor has depth across environments.
Does the sample report tell me about the auditor’s training?
Often, yes. Look for evidence of methodology (NVDA, VoiceOver, JAWS, TalkBack), references to specific WCAG techniques, and the level of code-level detail. Trained auditors leave fingerprints in their writing.
Reviewing a sample report takes 30 minutes. It saves weeks of rework. Before signing any audit contract, ask to see one.
Looking for accessibility auditors who share sample reports openly? Contact Accessibility Base to find vetted professionals.