An accessibility finding is useful when another person can reproduce it, understand its effect, and decide what to do next. A screenshot with a red circle rarely provides all of that. A long report without stable page references creates a different problem: the evidence exists, but finding the right part of it becomes work.
Build the handoff as a small, connected set of records. The scope explains what was examined. The inventory identifies the pages and states. Findings describe observed barriers. The retest record shows what happened after a fix.
Give every finding a stable reference
Use an identifier that stays the same when the title or priority changes. A reference such as A11Y-014 lets a report, issue tracker, release note, and retest entry point to the same observation.
Record the page address, the relevant interface state, the captured or tested version, and the time of observation. If a component appears on several pages, identify the shared component and the examples actually checked. Do not imply that every occurrence was tested just because the issue appears to be shared.
Keep the finding separate from its attachments. Screenshots, saved page content, and supporting notes can change as the investigation develops. The stable record should explain which attachment belongs to which observation and why a newer one was added.
Write a reproduction that another person can follow
A useful finding answers the same practical questions a developer will ask while investigating. Include the starting context, exact actions, observed result, expected behavior, and effect on the user.
Here is an illustrative finding format. It describes a fictional service form and should not be read as a result from a real customer website.
| Field | Example |
|---|---|
| Reference | A11Y-014 |
| Location | Appointment form, contact details step |
| Context | Agreed browser and screen reader combination; test release R17 |
| Reproduction | Leave the email field empty and submit the step |
| Observed behavior | A visual error appears, but the input's accessible description does not include it |
| User effect | A person using the tested screen reader may not receive the information needed to correct the field |
| Expected outcome | The relevant error is programmatically associated and available when the field is examined |
| Evidence | Capture reference, test notes, and relevant markup excerpt |
| Owner and status | Forms team; awaiting remediation |
Reference the applicable accessibility requirement after confirming the relationship. A checklist label without an explanation is less useful than a concise account of the actual behavior.
Use evidence formats for the questions they answer
A screenshot shows appearance at a moment in time. HTML can help explain structure and attributes. Preserved styles help investigate presentation. None of those alone proves how a keyboard or assistive technology interaction behaved through a complete task.
Attach the smallest useful evidence package, and include test notes for behavior that a still image cannot communicate. Where a recording is appropriate, avoid capturing unrelated personal information or credentials. Make sure the recipient can access the file and understand its context.
The HTML, CSS, and screenshot guide explains these distinctions in more detail. WAI's reporting guidance is also a useful reference when deciding how to communicate evaluation results and their scope.
Make ownership and priority actionable
Separate the impact of a finding from the team's delivery decision. A barrier affecting an essential task needs a clear explanation of that consequence. The agreed priority may also depend on exposure, available alternatives, and the timing of a release.
Assign an owner who can move the issue forward, not simply the person who received the report. Shared components often need a platform team; editorial issues may need a content owner. If ownership is unclear, make resolving ownership the next action.
Record duplicate relationships without deleting useful context. One shared navigation defect can have a primary issue and several observed locations. Keep those locations available for remediation and retesting rather than creating dozens of indistinguishable tickets or reducing everything to a single unexplained count.
Keep retest evidence separate from the original observation
Do not replace the original screenshot or rewrite the original finding to look as though the defect never existed. Add a retest entry with the new release, test conditions, actions, result, and reviewer.
Use statuses that distinguish fixed, partially fixed, still reproducible, and unable to retest. “Unable to retest” is not a pass. If a page was removed or a journey changed substantially, explain whether the old finding is no longer applicable and what new evaluation is needed.
The release retesting guide describes how to decide which earlier evidence a change may affect. The handoff should preserve that relationship so future reviewers can understand why an item was reopened or left unchanged.
Package the delivery around the recipient's next step
Provide a short entry document that links the scope, findings, inventory, attachments, and retest register. Include known gaps and instructions for interpreting automated results. Make filenames and references stable enough that recipients can discuss them without guessing which export is current.
Agree how long the package should remain available and who may access it. Preserve only information needed for the evaluation, and follow the organization's actual retention and sharing requirements. A saved snapshot is evidence of a capture, not an automatic legal certification or a guarantee of complete historical reproduction.
You can open and download the OnChange sample report to inspect an example of public page evidence and automated findings. Use it as a starting point for the discovery package, then add the human evaluation, ownership, and retest decisions needed for a complete handoff.