Finish the accessibility report

The report is where the work becomes something other people can act on. A developer reads it to fix things. A manager reads it to decide what’s next. A tester reads it in three months to check nothing came back. Each of them needs to know what was tested, how, on what, what was found, what was fixed and what still isn’t.

A report that says “the page is accessible” answers none of that. A report that says “on 22 September 2026, build 4f2c9e1, six combinations, 23 findings, 19 fixed, 4 open with owners” does.

The skeleton

Here’s the report for our registration page, trimmed:

# Accessibility report: registration page

Scope: /register, build 4f2c9e1, tested 22 September 2026
Out of scope: /schedule/print, the payment provider iframe

## Methods
- axe-core via @axe-core/cli and @axe-core/playwright
- W3C HTML checker
- Manual matrix, 6 rows, tasks from tasks.md

## Environments
- macOS 15.6, Safari 18.6, VoiceOver
- Windows 11, Firefox 141, NVDA 2025.1
- iOS 18.6, Safari, VoiceOver
- Chrome 139: keyboard only, 400% zoom, Voice Control

## Findings: 23 total, 19 fixed, 4 open

| # | Task blocked        | Criterion | Before                  | After                  | Fix     |
| 1 | Register, keyboard  | 2.1.1 A   | Register never focused  | 8 keystrokes to submit | a1c3f77 |
| 2 | Recover from errors | 3.3.1 A   | red borders, no text    | summary + field errors | 9be02d4 |

## Open

| # | Finding                 | Criterion | Owner | Retest     |
| 4 | "Saved" announced twice | 4.1.3 AA  | Marco | 6 Oct 2026 |

## Not tested
JAWS, TalkBack, Dragon, braille displays.

Every finding row links a user task, a criterion, the before evidence, the after evidence and the commit. Anyone can go from a line in the report to the keystroke log or screenshot that proves it.

Scope and versions are not bureaucracy

The scope line is what makes the report honest. We didn’t test the payment iframe, so we say so. Someone will ask about it, and “not tested” is a better answer than a silence that reads as “fine”.

The versions matter because assistive technology changes. A VoiceOver behavior in one Safari release may differ in the next. When a user reports a problem, the first question is whether they’re on a combination we tested. Without the versions you can’t answer.

Show the before and after together

The most convincing section is a short comparison of the same task on both builds:

Task: register with one wrong email, keyboard only

               Before (flawed)            After (repaired)
Keystrokes     16, Register unreachable   8
Announcements  0 for errors               summary + 1 per field
axe            3 violations               0

Numbers like these travel well. They end the “was it really that bad” conversation, and they set the baseline for the next audit.

Hand it over

A report you can only explain in person isn’t finished. Give the report and the matrix to someone who wasn’t in the audit, ask them to retest finding 1 from the document alone, and watch where they get stuck. Fix the document there, not the explanation.

The shortcut to avoid is publishing a perfect score with no scope, no test conditions and no known limitations. It reads well for a week. Then a user hits a barrier you never tested for, and the report has already spent its credibility. Assign every open item an owner and a retest date, put those dates in the calendar, and the one-time cleanup becomes a practice.

Try this on your own project: write the scope, methods and environments sections before you start the next audit. The findings will have a home when you get there.