What makes a good finding and what to avoid.

A good finding

A good finding has three properties:

1. Observable. Anyone can reproduce the issue from the description. "The submit button is unlabeled" is observable; "The form has issues" is not.
2. Criterion-linked. The problem clearly violates a specific criterion. If the link is unclear, either the criterion is wrong or the problem is misframed.
3. Actionable. The solution gives the developer enough to start work. Pointing to the failing element, naming the missing attribute, or sketching the markup are all useful.

Problem statement

State what is wrong:

• Identify the element (selector, visible label, or location on screen).
• Describe the user impact, not the auditor's frustration.
• Use plain language. Avoid jargon when a glossary term suffices.

Bad: "Bad alt text." Better: "The hero image's alt attribute reads 'image01.jpg', which does not describe the image content."

Solution statement

State how to fix it:

• Reference the specific change (attribute, role, structure).
• Reference the criterion's success technique when one applies.
• Provide a code snippet when the fix is small.

Bad: "Improve alt text." Better: "Replace alt='image01.jpg' with a description of the image content, e.g., alt='Photograph of the conference venue exterior'. If considered decorative, images should use alt=''."

Anti-patterns

• Verdict-only findings. A "Failure" with no problem text is unactionable.
• Restating the criterion. "Images must have alt text" is the criterion, not a finding.
• Tooling output dumped raw. The scanner's machine output should be translated into user-facing language.
• Compound problems. Each finding should be one issue. Multiple problems on one element should be split. Use numbered list for multiple problems, for instance.

When the scanner or the AI pre-fills

Automated results and AI fix suggestions are starting text, and both are stored as such so a reader can tell them apart from your own writing. The auditor always edits to:

• Remove jargon.
• Tie the description to the user impact.
• Add screenshots or specific selectors when missing.
• Adapt language to the person who will fix the issue.

A finding nobody rewrote is a low-quality finding.

When an automated result cannot be confirmed, the honest status is Needs review, not Success. See product / findings.