An accessibility report tells you almost everything you need to know about the person who wrote it. Before hiring an auditor, request a sample report and read it the way a client would read it. Look at how issues are documented, whether WCAG success criteria are cited correctly, and whether a developer could act on the findings without a follow-up call. A weak report signals a weak auditor. A clear, specific, actionable report signals someone worth hiring.
| Signal | What It Tells You |
|---|---|
| WCAG criterion mapping | Each issue tied to a specific success criterion and conformance level |
| Location detail | Page URL, element selector, and screenshot for every finding |
| Remediation guidance | Concrete recommendations a developer can implement |
| Severity or impact rating | Helps prioritize fixes by user impact and risk |
| Methodology section | Confirms the audit was conducted manually, not pulled from a scan |
What does a strong accessibility report actually look like?
A strong report reads like documentation, not a sales pitch. Every issue is a discrete entry with a WCAG success criterion, conformance level, location, description of the problem, and a recommendation. The reader does not need to interpret. They read the entry and know what to fix.
Weak reports tend to bundle issues into vague categories. A line that says “images need alt text” without listing the specific images or pages is not actionable. A skilled auditor identifies each occurrence and documents it individually.
How can you tell a manual audit from a scan dressed up as one?
Scans only flag approximately 25% of issues, and they cannot evaluate context. Look at the issue types in the sample report. If every finding is something a scan would catch (missing alt attributes, low contrast ratios, empty links), the report is likely a scan output with light formatting.
A real audit identifies issues that require human judgment: keyboard traps in custom components, screen reader announcements that do not match visible text, focus order that breaks the reading sequence, ARIA roles applied incorrectly. These findings cannot be automated.
Ask directly how the audit was conducted. The methodology section should describe assistive technology used, browsers evaluated, and the WCAG version and conformance level applied.
Does the report cite WCAG correctly?
Open the report and check the success criterion citations. Are they accurate? Does the auditor reference the correct level (A, AA, or AAA)? Does the WCAG version match what the client requested (2.1 AA or 2.2 AA)?
Misattributed criteria are a red flag. If an auditor labels a color contrast issue as 1.4.1 (Use of Color) instead of 1.4.3 (Contrast Minimum), they do not know WCAG well enough to produce reliable work. The success criteria have specific meanings and substituting one for another reflects guesswork.
Is the remediation guidance specific or generic?
Generic guidance reads like a WCAG glossary entry. Specific guidance tells the developer what to change and where. Compare these two:
Generic: “Add alt text to images for screen reader users.”
Specific: “The product image at /shop/widget-blue has an empty alt attribute. Add alt=\”Blue widget, side view\” to convey the product and angle shown.”
The second example demonstrates the auditor understood the page, the user need, and the fix. That is the level of detail worth paying for.
Are issues prioritized?
A report without prioritization leaves the client guessing. Strong reports include severity or user impact ratings so the team knows which issues to address first. This matters most when the issue count is large and the remediation budget is limited.
Some auditors apply Risk Factor or User Impact prioritization formulas. Others use a simpler high, medium, low rating. Either approach works as long as the logic is documented and consistent across findings.
What should you ask the auditor before hiring?
Read the sample report, then ask follow-up questions. The answers reveal as much as the document itself. Consider asking how many hours the audit took, what assistive technology was used during evaluation, how issues are validated after fixes are made, whether the same auditor will work on your project, and how remediation guidance maps to your development stack.
An experienced auditor answers these without hesitation. Vague or shifting answers suggest the work is templated or outsourced.
How long should it take to review a sample report?
Plan on 30 to 45 minutes for a thorough review. Read 10 to 15 findings closely, check the WCAG citations, evaluate the remediation guidance, and review the methodology section. That is enough to judge the auditor’s skill level.
Can I ask for a redacted client report instead of a generic sample?
Yes. A redacted real-world report is more revealing than a polished marketing sample. Most reputable auditors can share one with client identifiers removed. If they cannot produce any sample at all, that is a signal worth noting.
What if the report is well-written but the price seems too low?
Low pricing on a thorough manual audit is uncommon. A skilled auditor evaluating a website against WCAG 2.1 AA or 2.2 AA spends real hours on the work. If the price feels too low for the depth promised, ask how many hours are allocated and whether the audit is fully manual.
The sample report is the most honest preview of what you will receive. Read it carefully before signing anything.
Contact Accessibility Base to find vetted auditors and accessibility professionals: Contact Accessibility Base.