Findings per criterion
Location, screenshot, the decision and a fix hint for every failed criterion, grouped by component where they repeat.
For developers
Findings you can fix, not a score to argue about
Our report tells you which criterion failed, on which element, on which page, with a screenshot and a hint on how to fix it. And our free tools let you catch most issues before anyone else tests.
What a finding looks like
Each finding is tied to one WCAG 2.2 criterion and one location: page, element and, where possible, a selector. It comes with a screenshot and a fix hint that describes what the HTML or behaviour should be. Automatic findings from axe-core and our own measurements are marked as such; the reviewer’s decision is what counts.
A clean automatic run is a good start, not a pass. Many criteria cannot be measured: whether an alt text fits, whether the focus order makes sense, whether an error message helps. That is why a person decides every criterion in the audit.
Every criterion has its own page in our criteria library, with what it means, typical failures and how to test it.
What you get, and what is coming
Keyboard test
Our keyboard test shows a focus trail and walks you through a five-minute self-test of your own pages.
Contrast checker
The contrast checker tells you whether a colour pair passes and suggests the nearest shade that does.
Checklists
Role-based checklists for design, development and content, so issues are caught in review.
API and CI
There is no API or CI integration at the moment.
Issue tracker export
There is no export of findings to Jira or GitHub at the moment.
Who in the team does what
Accessibility is not added by a test at the end; every role builds it in. Typical criteria per role:
Design
Colours, contrast, a visible focus and targets that are big enough.
Development
Semantics, keyboard support and a clear name for every control.
Content
Alt text, clear headings and link text that makes sense on its own.
New in WCAG 2.2: six criteria worth checking now
- 2.4.11Focus Not Obscured (Minimum)
Sticky headers, cookie banners and chat buttons must not completely hide the focused element. Check with scroll-padding.
- 2.5.7Dragging Movements
Every drag action needs a single-pointer alternative, such as move buttons in a sortable list.
- 2.5.8Target Size (Minimum)
Pointer targets of at least 24 × 24 CSS pixels, or enough spacing around smaller ones.
- 3.2.6Consistent Help
Help links, contact details and chat must be in the same relative place on every page that offers them.
- 3.3.7Redundant Entry
Do not ask for the same information twice in one process; prefill or offer to reuse it.
- 3.3.8Accessible Authentication (Minimum)
No cognitive tests at login unless there is an alternative. Do not block paste in password or code fields.
A quick self-test before you ship
Unplug the mouse
Tab through the page. Can you reach and use everything, and do you always see where you are?
Zoom and narrow
Zoom to 200%, then make the window 320 CSS pixels wide. Nothing should be cut off or need sideways scrolling.
Run an automatic check
Use axe-core or a browser’s built-in accessibility audit, and fix what it finds first.
Listen once
Turn on VoiceOver or NVDA and go through your main flow. You will hear what is missing.
Frequently asked questions
Which tools does your scanner use?
axe-core for rule-based checks, plus our own measurements: a keyboard walk, reflow at 320 CSS pixels, 200% zoom, text spacing, forms, media and motion. Details are on our method page.
If axe-core reports zero violations, do we pass?
Not necessarily. Rule-based tools cover only part of WCAG. A person still has to judge alt texts, order, error messages and screen reader output.
Can I run your scanner in our pipeline?
Not at the moment. For now, the free tools and the self-test above catch most regressions early.
Related
Keyboard test
See and practise focus
Contrast checker
With the nearest passing shade
Criteria encyclopedia
All 55 WCAG criteria explained
Method
All 55 criteria, openly described