Sample report · format example

Web Accessibility Audit

Tested against WCAG 2.1 Level AA · 6 October 2026 · prepared by Raman Popli

Sixteen accessibility problems were found. They trace back to four changes. After those four changes a re-test returned zero.

16
Problems found
4
Actual changes
0
After re-test
12
Checks passed

1. What was found

IssueSeverityInstances
Text is too faint to read (colour contrast)Serious16

People with low vision, reduced contrast sensitivity, or anyone using a phone in daylight cannot reliably read this text. Roughly one man in twelve has some form of colour vision deficiency.

2. The part most reports leave out

An automated scanner reports 16 problems across 6 colour combinations and stops there. Six combinations is not six decisions. Tracing each one back to the stylesheet gives this:

Reported as failingRatioElementsWhere it actually comes from
#a67c2e on white 3.795 The --gold brand variable
white on #a67c2e 3.791 Same variable, used as a background — not a second problem
#b07415 on white 3.924 The --warn brand variable
#c3bcbc on white 1.863 Not a colour in the stylesheet at all. It is --muted seen through opacity:.42 on the booked-date tiles.
#a49e9f on white 2.632 The same opacity:.42, this time over --ink
#9a8d8c on #fdf8f4 3.031 --muted through opacity:.7 on one footer paragraph
Why this matters commercially Three of those six "colours" do not exist anywhere in the stylesheet. Searching the codebase for #c3bcbc returns nothing, and a developer can lose an afternoon to that. The real cause is two opacity rules. Sixteen findings, six reported combinations, four changes.

3. The four changes

#ChangeFromToNew ratioFixes
1--gold #A67C2E #957029 4.546
2--warn #B07415 #A26B13 4.524
3.d.gone opacity.42.88 4.595
4footer paragraph opacity.7.9 4.601
A judgement call worth flagging Change 3 reduces the fading on booked dates, which was a deliberate design choice. The faded state was carrying meaning that a low-vision visitor could not perceive. The strike-through already present on those dates carries the same meaning and does not depend on being able to see a subtle difference in grey. Raising the opacity keeps the design intent and makes it readable — the kind of trade-off a scanner cannot make for you.

4. Re-test after the changes

MetricBeforeAfter
Problems found160
Serious160
Checks passed1212

Same tool, same page, same settings, after the four changes above. This re-test is included in every engagement, so the work is evidenced rather than asserted.

5. What this test does and does not cover

Automated testing reliably detects roughly 57% of accessibility issues by volume and covers 20–30% of WCAG success criteria. The remaining criteria — keyboard operation, focus order, screen reader announcement, whether alt text is actually meaningful, and error handling — require manual testing with assistive technology. Every finding above was additionally checked by hand to confirm the element is visible and the failure is real; findings caused by scroll animations, hidden elements or backgrounds the tool cannot resolve were excluded rather than reported.

Scope of this document This is a record of what automated testing, with manual verification of each finding, detected on the date stated. It is not a conformance claim, not a VPAT, and not legal advice. No manual assistive-technology audit is included. Pages tested and date of test are stated in the header.

6. Recommended next steps

Step one

Make the changes and re-test

Fix the serious items, then re-run the test and keep the dated result. That record is worth more than the report itself.
Step two

Commission a manual audit

Keyboard navigation, focus management and screen reader behaviour — the majority of success criteria that no automated tool can evaluate.
Step three

Re-test on a schedule

A theme update or a new section can reintroduce a failure. A quarterly re-test catches it before a customer does.