When Can an Accessibility Result Be Called a Pass?
Pass or fail can be a valid assessment result, but one scan or badge cannot establish whole-site conformance. Read the criteria, scope, dates, untested areas, and retest results.
Last updated:
Summary
- A pass needs criteria, scope, and evidence that explain what was assessed.
- Passing one rule does not establish WCAG conformance for a full page or process, and a public statement is not a test result.
- Record untested, needs-review, and not-applicable items separately; do not count them all as passes.
First ask: passed what?
“This button has an accessible name” and “This site conforms to WCAG 2.2 AA” are conclusions at different levels. One may come from a rule check; the other needs a conformance evaluation, not a single button or automated scan.
Pass/fail is not inherently a problem. Omitting criteria, scope, environment, and dates can make a result appear to cover more than was evaluated.
Conformance evaluation has defined requirements
WCAG 2.2 AA covers all A and AA success criteria and the other conformance requirements, including full pages and complete processes. The standard also defines provisions for conforming alternate versions and accessibility support; adding up passed scan rules is not enough.
For a shopping task involving selection, cart, payment, and confirmation, testing only the homepage does not cover the process. Read the report’s defined scope, method, environment, dates, and limitations, not just a score or badge.
Do not collapse different states into one success count
These are useful maintenance categories, not new WCAG levels. Keep the reason for each judgment.
- Checked: record the criterion or rule, result, and evidence; identify affected content for findings.
- Needs review: a tool requests human judgment or evidence is insufficient; specify how to confirm it.
- Untested: pages, states, or environments that were not checked; not a pass.
- Not applicable: the criterion’s applicability conditions are absent, with a recorded reason; not a substitute for untested.
Read a hypothetical result
Suppose a scan finds an unnamed Remove item button. After adding the correct name, the same rule passes on rerun. Record that rule’s retest result, then also check the name’s meaning, keyboard activation, and focus and notifications after removal.
If authenticated pages were not tested, mark them untested. “No issue listed by the tool” cannot become “the signed-in flow passed,” and this rule retest cannot justify a whole-site conformance claim.
Keep each source in its proper role
A statement can provide limitations and contact options; a certification report must be read within its assessment scope; reports describe barriers; scans help locate some issues. These sources can complement each other without being interchangeable.
Signal shows supported public references and a reporting option. Private reports and Pulse scan summaries are for authorized maintainers. Assign reproducible issues, then retest the original task and relevant states, recording results and remaining untested scope.
Related pages
- How to interpret automated checks
- Plan repairs and retests
- What does web accessibility cover?
- W3C WCAG 2.2: Conformance Requirements
- Understanding WCAG check results
- Accesserty Signal
See traceable accessibility clues in search results and report barriers when they happen.
- Accesserty DevCheck
Run browser-based checks on local builds, staging pages, authenticated screens, and interactive states.
- Accessibility practice and maintenance guides
Browse guides by practical task: public signals, pre-release checks, post-launch maintenance, and standards limits.