Sample accessibility audit report
This is the kind of report you get from us. To avoid putting any real business on display, we audited a page the W3C built to be inaccessible for teaching: the Before and After Demonstration (BAD) inaccessible home page.
What's in an accessibility audit report
- Summary: what we tested, how, and the headline findings in a few sentences.
- Issues by severity: critical issues that block people come first, then serious, moderate, and minor.
- WCAG criterion: each issue is tied to a WCAG 2.2 success criterion, such as 2.1.1 Keyboard.
- Where: the page and the exact element, so your developer can find it fast.
- Why it matters: who is affected and how, in plain words.
- How to fix: a specific fix, with a before-and-after code snippet when it helps.
- Method and limits: the tools, browsers, and assistive technology used, and what wasn't covered.
Headline findings from the sample
- Keyboard focus is thrown away on 14 of the 20 links in the demo content, so keyboard users can't follow them.
- The image-based navigation menu has no text alternatives, so screen readers announce links with no names.
- The "quick menu" drop-down jumps to a new page as soon as you press the down arrow.
- The page has no language set, no headings in its content, and doesn't fit a phone-width screen without sideways scrolling.
The automated scan (axe-core) flagged 8 rule failures, and Lighthouse scored the page 53 out of 100 for accessibility. The manual keyboard pass found the most serious barrier, focus being thrown away, which axe-core doesn't flag as a failure.