Checkpoints aren’t just in spy movies.
People often ask us what our coverage is for WCAG. What they often mean by that is, “What percent of WCAG success criteria do you have a validation for?”
It’s a reasonable question, but it’s missing something very important.
It turns out that there are a very, very large number of ways to fail a success criterion. Just as there are many ways to get an answer wrong on a history test, or many ways for your new car to get dinged in a parking lot. (Believe us, we know.)
So as far as we are concerned, an accessibility tool’s ability to detect defects cannot be measured properly without understanding its thoroughness, or what we call its “checkpoint depth.” A tool that can detect 100 different ways to fail a single criterion, all other things being equal, will be more useful than a tool that can only detect just 1 way to fail that same criterion.
So we thought it would be handy to summarize the differences in checkpoint depth between Evinced and, say, axe-core, a popular open source legacy solution. (By the way, Evinced includes all axe-core validations.)
Checkpoint depth summary for automated WCAG 2.2 coverage (August 2025)
| WCAG 2.2 Success Criterion (A, AA) | Conformance Level | Axe-core* | Evinced* |
|---|---|---|---|
| PERCEIVABLE | |||
| 1.1.1 Non-text Content | A | 7 | 8 |
| 1.3.1 Info and Relationships | A | 8 | 97 |
| 1.3.2 Meaningful Sequence | A | 0 | 3 |
| 1.3.5 Identify Input Purpose | AA | 1 | 1 |
| 1.4.1 Use of Color | A | 1 | 1 |
| 1.4.3 Contrast (Minimum) | A | 1 | 2 |
| 1.4.4 Resize Text | AA | 1 | 1 |
| 1.4.12 Text Spacing | AA | 1 | 2 |
| OPERABLE | |||
| 2.1.1 Keyboard Accessible | A | 2 | 39 |
| 2.2.1 Timing Adjustable | A | 1 | 1 |
| 2.2.2 Pause, Stop, Hide | A | 1 | 1 |
| 2.4.2 Page Titled | A | 1 | 1 |
| 2.4.3 Focus Order | A | 0 | 7 |
| 2.4.4 Link Purpose (In Context) | A | 2 | 2 |
| 2.4.7 Focus Visible | AA | 0 | 1 |
| UNDERSTANDABLE | |||
| 3.1.1 Language of Page | A | 3 | 4 |
| 3.1.2 Language of Parts | AA | 0 | 1 |
| ROBUST | |||
| 4.1.2 Name, Role, Value | A | 23 | 107 |
| * Excludes “Needs Review” and “Experimental” validations, and semi-automated tests like IGTs. | |||
The differences are not small.
To take just one example, axe-core has two fully automatic validations against the 2.1.1 Keyboard Accessible criterion. But Evinced has 39 fully automatic validations (including the two from axe-core) against the same criterion, which means we detect many, many more of the ways that a piece of code could be an accessibility bug.
At the end of the day, the reason we find so many more defects is because we’re looking for so many more defects. If you are relying on axe-core only, whether it’s via a browser extension or for that matter a vibe coding tool, you are going to be detecting radically fewer bugs automatically than with Evinced. And, since our work at Evinced has tended to focus on the most serious bugs, the bugs you are missing are likely the ones you can least afford to miss.
If you want to read about this in more detail, download this handy, super-detailed Excel file of all our checkpoints, compared to those for axe-core.