What a finding is, what statuses mean, and how findings are documented.
What a finding is
A finding is the auditor's evaluation of one criterion on one sample. Each (sample, criterion) pair has at most one finding.
Statuses
| Status | Meaning |
|---|---|
| Success | The sample meets the criterion |
| Failure | The sample does not meet the criterion |
| Needs review | The result could not be confirmed and a human still has to look |
| N/A | The criterion does not apply to this sample (no matching content) |
| Derogation | An exemption applied, with a written justification |
| Not tested | The criterion has not been evaluated yet |
"Needs review" and "Not tested" both count as no verdict: neither advances the audit's progress, and neither is scored as a pass or a fail. "Needs review" exists so that an ambiguous scanner result, or an AI pass that could not verify a criterion, is marked as visited without being recorded as a false Success.
Failures and Derogations are what feed the report's issue list and the accessibility statement.
User impact
A Failure or a Derogation can carry a user-impact level: Low (minor friction, the task is still possible), Disturbing (the task is harder, slower or degraded), or Blocking (the task cannot be completed). Left unset it reads as Unknown.
Impact is a qualifier of a failure, not a status of its own, and it drives the order in which failures become actions in an annual accessibility plan. See accessibility plans.
Fix profiles
A failure can also name who has to fix it: development, design, content, project management, or QA. CheckFox suggests a default per criterion; the auditor can override it, including to "none of these". Profiles are carried onto the ticket when a finding is pushed to Jira, GitHub or Linear.
Finding fields
- Status (required)
- User impact and fix profiles, for failures and derogations
- Problem description, what is wrong, observable, in plain language
- Solution suggestion, how to fix it, code-referenced when possible
- Evidence images
- Flag for the report, with a short reason, so the finding is picked up in report sections that list selected issues
- Ticket reference, once the finding has been pushed to an issue tracker
Why both problem and solution
The accessibility statement and the report draw on these fields. A good problem description tells the user what is wrong; the solution tells them how to fix it. See methodology / finding quality.
AI fix suggestions
Workspaces with the AI add-on can ask CheckFox to suggest a fix for a failing criterion. The suggestion fills the solution text and is stored with the date and the model that produced it, so an AI-written solution is always distinguishable from an auditor-written one. Review it the way you review scanner output. See methodology / finding quality.
Where findings are edited
Open a sample from the audit's Samples tab. The sample view lists its criteria grouped by topic, and each criterion card holds the status buttons, the problem and solution text, the impact, the fix profiles and the evidence images.
Scanner-pre-filled findings
If the workspace has the scanner, automated results pre-fill problem and solution text where they map cleanly to a criterion, and the entry is marked as scanner-sourced. The auditor always validates or overrides. See integrations and procedures / use the scanner.
Related
- methodology / finding quality - what makes a good finding.
- propagate status - reusing one verdict across samples.
- audits, samples.