Public documentation
Results and severity model
How severity, source, confidence, and user impact should be interpreted together.
Severity is not a verdict by itself
Severity helps prioritise review, but it is not a complete accessibility verdict. A high-severity confirmed issue still needs context and retesting; a lower-severity item can still block a user journey depending on placement and task.
Fields to evaluate together
| Field | Meaning | How to use it |
|---|---|---|
| Classification | Confirmed, needs review, advisory, limitation, or diagnostic | Determines whether the item can be treated as defect evidence. |
| Severity or impact | Estimated user-impact priority from source rule or custom logic | Use for triage order, not certification. |
| Source engine | axe-core, A11Y Cat module, spelling, diagnostics, or review workflow | Use to trace why the result exists. |
| Source rule ID | Rule or check identifier | Use for remediation research and reproducibility. |
| Selector and snippet | Element or evidence context | Use to locate the issue; verify stale selectors after page changes. |
| WCAG/POUR mapping | Relevant accessibility principle or criterion where available | Use as context; it is not a conformance certificate. |
Priority workflow
- 1
Filter confirmed issues first
Use confirmed issue rows as remediation candidates, especially where severity is high and the user journey is important.
- 2
Review needs-review queues
Inspect ambiguous items before deciding whether a defect exists.
- 3
Check limitations and diagnostics
Understand what the scan could not inspect before making coverage statements.
- 4
Retest after changes
Rerun the scan and manual checks after remediation, state changes, or responsive layout changes.