Begin with the evaluation contract
Put the scope at the front of the report. Name the website, application, or document set; the versions tested; the target standard and level; the sample; the environment; and the evaluation dates. Readers should not have to infer whether the report covers one checkout flow or the entire service.
The methods section should say which automated tools ran and which checks were completed by people. Include browser and assistive technology details when they affect the result. Record failed fetches, inaccessible test data, blocked resources, and states that the evaluator could not reach.
A finding needs more than a rule name
Consider a form field announced without a useful name. The report should identify the page and state, point to the field, state the expected and observed behavior, name the relevant requirement, and describe how to reproduce the issue. A short repair note can explain the desired outcome without prescribing code that the evaluator has not reviewed.
Example finding record
- Location: Checkout, delivery address, postal code field
- Observed: The field is announced as "edit text" without a name
- Expected: The accessible name identifies the requested postal code
- Evidence: DOM locator, accessibility tree excerpt, and test steps
- Owner: Checkout frontend team
- Status: Open, then fixed, then verified in the retest build
Separate the summary from the evidence
An executive summary can describe recurring barriers, affected journeys, and repair priorities. It should link back to the underlying finding records. If a summary says that form labels are the most common failure, a reader should be able to see which pages and controls support that statement.
Counts need context. Twelve failures may be twelve separate components or one component repeated across twelve pages. Grouping by a stable fingerprint helps a team repair the source component while keeping every affected occurrence visible.
Do not hide coverage gaps
An accessibility testing report should distinguish failure, pass, partial coverage, manual review, and tests that did not run. These states are not interchangeable. A report that turns all non-failures green makes it easy to mistake missing evidence for proof.
W3C's WCAG-EM Report Tool provides a structure for evaluation results and can export a report from evaluator input. It does not perform the evaluation. That separation is useful: reporting software can organize evidence, but the evaluator remains responsible for the evaluation and its conclusions.
Keep the retest attached
A repaired finding should retain its original evidence and gain a retest result. Record the build or document version, the person or engine that checked it, and the new observation. If the issue remains, update the status without erasing the history that explains the earlier decision.