How to use notes for communicating with your team, document, or prepare your statements.

Why notes matter

Verdicts and findings record what. Notes record why. They externalize the auditor's reasoning for future-you, teammates, developers reading the report, and disabled users reading the public statement. CheckFox separates note levels so each one ends up in front of the right reader.

The three levels of notes

1. Audit-level notes (global)

Scope: the whole audit. Reminders for yourself or your teammates. Use for scope decisions, environmental context (browser, screen reader), open team questions, re-audit reminders. Not user-facing.

2. Sample-level notes

Scope: one sample. Use when something about the page itself applies across all of its findings: authentication state, page-specific quirks, or why this sample was selected.

3. Criterion-level notes (per-finding)

Scope: one (sample, criterion) pair. Mostly to argue a decision for yourself or a teammate later: justifying a borderline verdict, recording what was tested and how, capturing alternative interpretations the next auditor should know about. Typically internal — they explain the why behind the verdict.

Notes that travel: report notes vs. statement notes

Two categories are written to be published.

Notes for the report

Land in the audit report alongside findings and proposed solutions. The report is technical, addressed to the team that will fix or explain the issues. Treat report notes as the auditor's running commentary for the people doing the remediation work.

Notes for the statement

Land in the public Accessibility Statement. The audience is disabled users (and others) deciding whether they can use the service.

Write them to explain what is wrong, clearly and plainly — not to justify, not to minimize.

• Bad: "Some images may have suboptimal alternative text in certain edge cases."
• Better: "Several product images in the catalog do not have descriptive alternative text, so screen reader users may not know what the product looks like."

If an alternative way to access the same information exists, the statement note is the right place to mention it:

• "The interactive map on the Contact page is not accessible to keyboard users. The full address and opening hours are available in text directly below the map."
• "The video tutorial does not have captions yet. A written transcript is linked under the video."

That turns a statement from a wall of failures into something genuinely useful.

Anti-patterns

• Mixing levels. A team reminder doesn't belong in the public statement; a borderline-verdict justification doesn't belong in the developer report.
• Defensive statement notes. "We are committed to accessibility" is filler. State the issue plainly.
• Empty notes. "See finding" adds nothing.
• Hidden context. Reasoning that lives only in the auditor's memory is lost on the next round. Write it down at the criterion level.

Where to put what — quick reference

Related

• audit process — where notes fit in the audit phases.
• finding quality — finding text vs. note text: the boundary.
• statement quality — statement notes feed directly into it.