We run Deque's engine. The difference is what happens to the findings.
Our scanner is built on axe-core, which Deque develops and publishes openly. Their manual tooling, guided tests and training go far beyond ours. What we built is the reporting: fixes ranked by how much each one clears, a run-to-run comparison, and criteria nothing checked marked not checked.
Scan a public URL free · no credit card required
Choose Deque if
- Your obligation is a defensible conformance position rather than a shorter backlog. Deque sells manual auditing, expert services and training; we sell none of those.
- You want the checks automation cannot decide — Intelligent Guided Tests walk a person through precisely the majority of the standard no rule covers.
- You need a linter in the editor, mobile analysis, an MCP server, or site-wide crawling that reports upward.
- You want the people who write the engine on the other end of the support contract.
Choose TestKase if
- You want the same axe-core findings ordered by how many issues each change clears, with running totals.
- You want to know what this change introduced, not only what the total is today.
- You want criteria no rule covers reported as not checked rather than quietly counted as passing.
- You want the automated layer inside the same workspace as your device testing and your test cases, without a per-seat licence.
The head-to-head
Where the two genuinely differ. The first row is the one that makes the rest of the page checkable.
| Item | How the two compare | For us |
|---|---|---|
| The engine | The rules that decide whether an image lacks a text alternative or a control has an accessible name are axe-core. Deque wrote it, Deque maintains it, and Deque publishes it under an open-source licence that lets tools like ours use it. On the same page at the same standard, the same rules fire. | Shared |
| Guided manual testing | Intelligent Guided Tests walk a person through the checks a machine cannot decide. We flag where a human decision is needed and stop there. | Theirs |
| Editor and mobile tooling | A linter for VS Code, a Mobile Analyzer and an MCP server for driving checks from a development environment. We have a Chrome DevTools toolkit for working a page in the browser and nothing that reads your source or your native app. | Theirs |
| Site-wide discovery | axe Monitor crawls at organisation scale and reports upward. A scan here takes up to ten addresses that you choose; nothing discovers your site for you. | Theirs |
| Audit, VPAT and training | axe Auditor systematises manual testing so a team of humans produces consistent findings, and Deque runs formal training and sells expert audit services. We issue no VPAT, no audit letter and no legal opinion. | Theirs |
| Ordering the findings | Our fix plan ranks changes by how many issues each one clears, with severity as the tie-break rather than the sort key, and every row carries a running total and the selector the fault concentrates on. | Ours |
| Run-to-run comparison | Every run reports fixed, introduced and unchanged against the run before it, matched by a fingerprint of rule, page and element selector — so “fixed” means that exact problem is gone rather than the count happening to fall. | Ours |
| What a report may claim | Criteria with no automated rule are reported as not checked, never as passed, and the machine-checkable set is read from the engine's own rule tags at runtime rather than typed into a marketing page. | Ours |
| Pricing shape | Deque's extension is free, Pro is a per-seat subscription and the bundle is quoted by sales. Ours is not priced per person and every price is published. | Ours |
- WCAG 2.2 A and AA criteria with any automated rule behind them
- 23 of 55
- Of issues found, per Deque's published automated-coverage research
- ~57%
- Addresses per scan, on every plan including the free one
- 10
- Scan history and schedules kept
- 90 days
The first two figures measure different things and both are correct — see below. Deque's comes from their analysis of thousands of pages and hundreds of thousands of findings, read 11 September 2026; ours is read from the engine's own rule tags at runtime.
Start with the awkward bit: it is their engine
Naming the engine is what makes every other number on this page checkable.
The rules underneath our accessibility scanner are axe-core. Deque wrote it, Deque maintains it, and Deque publishes it under an open-source licence that lets tools like ours use it. A large share of the accessibility products you can buy do the same thing, and most of them are considerably vaguer about it than this paragraph.
We would rather lead with it. If you are comparing scanners and one of them will not tell you which rules it runs, that is the more interesting fact about that product. Naming the engine also makes every other number here checkable: when we say fewer than half of WCAG 2.2 AA has an automated rule behind it, you can go and look at the rule set yourself.
What that means practically is that the findings are not the differentiator. On the same page, at the same standard, the same rules fire. The difference is what happens to them afterwards.
Two true numbers that sound like they disagree
One counts issues, the other counts criteria. A report that quotes only the first implies far more assurance than it earned.
Deque publishes research putting automated coverage at roughly 57%, from an analysis of thousands of pages and hundreds of thousands of findings. We publish that automated rules reach 23 of the 55 WCAG 2.2 criteria at A and AA — well under half. Both are correct, because one counts issues and the other counts criteria.
Machine-detectable faults repeat. A missing label on a form component rendered on ninety pages is ninety findings from one rule, so the automatable share of a real audit's issue list is large. The automatable share of the standard is not, because whole criteria — meaningful alternative text, focus order matching reading order, error messages that explain the correction, a process completable without dragging — have no rule at all.
Our conformance summary marks every criterion with one of four statuses, and the set of machine-checkable criteria is read from the engine's own rule tags at runtime rather than typed into a marketing page. When the engine gains rules, the figure widens on its own, and when it does not, we cannot quietly widen it anyway.
- Failed — a rule fired on this pageEvidence of a problem
- No problems found — a rule ran and found nothingEvidence
- Needs a human decision — a rule ran and cannot settle it aloneReview
- Not checked — no automated rule covers this criterionNot a pass, not a failure
What we built on top of the same findings
Four things that happen after the rules fire.
| Item | What it does |
|---|---|
| A plan ordered by reach, not by alarm | The fix plan ranks changes by how many issues each one clears, with severity as the tie-break, page count next and the rule id last so the order never moves between runs. Every row carries a running total and the selector the fault concentrates on, which tells you whether the fix is one component or forty files. |
| What you introduced, not just the total | Every run is compared with the run before it and reports three numbers: fixed, introduced and unchanged. Identity is a fingerprint of the rule, the page and the element selector, so “fixed” means that exact problem is gone rather than the count happening to fall. |
| A real browser on real machines | Scans run in a desktop browser on the same fleet that serves manual sessions and automated suites, so a page that needs JavaScript to render is scanned after it has rendered. Scheduled scans run daily, weekly or monthly at a time in a named timezone. |
| Pages behind a login, handled carefully | Authenticated scanning signs in with cookies, headers or a form. Credentials are encrypted with AES-256-GCM under a key held outside the database, and the API returns cookie and header names only, never a value. |
Where Deque is ahead
Almost everything past the automated layer. Deque has been the most rigorous voice in this field for a long time, and the most honest one about the limits of automation — its own research is the reference most of the industry cites, including us.
- Intelligent Guided Tests — the checks a machine cannot decideNot ours
- A linter for the editor — problems caught before the page existsNot ours
- Mobile Analyzer — native app accessibilityNot ours
- axe Monitor — crawling at organisation scale, reported upwardNot ours
- axe Auditor — systematised manual testing for consistent findingsNot ours
- Training and expert services — including formal audits and a VPATNot ours
Per seat, or not
Who ends up holding the licence usually decides whether anything gets fixed.
| Item | How it is priced |
|---|---|
| Deque | The browser extension is free and genuinely useful on its own. The professional tier is a per-seat subscription and the full bundle — continuous integration, the linter, single sign-on, the reporting layer — is quoted by sales. That is a normal enterprise shape, and it has a normal enterprise consequence: accessibility tooling ends up on the desks of the people who asked for it, which is usually not the developers writing the markup. |
| TestKase Accessibility | Not priced per person. Scans take up to ten addresses each on every plan including the free one, results are shared with teams inside the workspace, and the device testing beside it is billed per parallel thread rather than per user, with every price published on the pricing page. Scan history and schedules are kept for ninety days. |
The rest of the category
Four answers to the same question, and what each of them is actually for.
| Item | What it is for |
|---|---|
| Deque | The deepest accessibility tooling available and the engine underneath most of the category, ours included. Guided manual tests, a linter, mobile analysis, an auditor product, training and expert services all reach past anything here. |
| Siteimprove and Level Access | Siteimprove and Level Access are governance platforms: they crawl whole estates and report upward to a programme office. Different job, different buyer, and a shape we do not have. |
| Overlays | Accessibility overlays sell compliance as an installable widget. They do not deliver it, and we do not sell one. |
| TestKase | The reporting layer on a shared engine: fixes ranked by reach, a run-to-run comparison that names what you introduced, criteria nothing checked marked not checked, scans in a real browser on our own machines, and no charge per person. |
What this does not do
- No guided manual testing.
- Deque's Intelligent Guided Tests cover ground automation cannot decide. We flag where a human decision is needed and stop there.
- No crawling.
- A scan takes up to ten addresses you choose. Nothing discovers your site for you.
- No certification, VPAT or audit service.
- We produce reports, not conformance claims, and nothing here is legal advice.
- No linter and no mobile analyser.
- There is a Chrome DevTools toolkit for working a page in the browser, and nothing that reads your source or your native app.
- Screen-reader behaviour is not simulated.
- What a screen reader announces is a separate question from what the markup implies.
- Comparison is against the previous run only.
- Fixed, introduced and unchanged — not a trend line, not a score over time. An element moved to a different selector reads as one fixed plus one introduced.
Frequently asked questions
Yes. The rules that decide whether an image lacks a text alternative or a control has an accessible name are axe-core, which Deque develops and publishes under an open-source licence. We did not write an engine and we are not going to imply we did. What we built is everything around it: what runs it, how the findings are ordered, how two runs are compared, and what a report is allowed to claim.
Many teams should. If you want the deepest accessibility tooling available — guided tests for the things automation cannot decide, a linter in your editor, mobile analysis, systematised manual auditing and formal training — that is Deque, and no page here is going to pretend otherwise. We are worth looking at if you want the automated layer inside the same workspace as your device testing and your test cases, without a per-seat licence.
Both, because they measure different things. Deque's figure counts issues: in a real audit, a majority of the individual findings are the kind a machine can detect, because machine-detectable faults repeat across a template. Ours counts criteria: fewer than half of the 55 WCAG 2.2 AA success criteria have any automated rule behind them at all. A scan can therefore find most of your findings while leaving most of the standard unexamined, and both sentences belong in the same report.
They are reported as not checked, never as passed. That is the single distinction the reporting is built around: a rule finding nothing and no rule existing are different facts, and only one of them is evidence. The criteria with no rule are not exotic either — whether alt text is meaningful, whether focus order matches the reading order, whether an error message explains the fix.
It is ranked by how many issues each change clears, with severity as the tie-break rather than the sort key. One code change usually clears every instance of a fault, so a moderate problem repeated forty times and a serious one on a single element are the same amount of typing for very different results. Each row also carries a running total, so a report can say three fixes clear 47 of your 61 problems.
No. A scan takes up to ten addresses that you choose, on every plan including the free one. Deque's monitoring product crawls at organisation scale and reports upward; ours is a developer tool aimed at the pages you are working on. If site-wide discovery is the requirement, we are the wrong shape.
No automated tool can, and neither of us claims to. Deque goes considerably further than we do towards a defensible conformance position, because it also sells manual auditing and expert services. We issue no VPAT, no audit letter and no legal opinion, and a clean scan from us means the machine-checkable subset is clean and nothing more.
Related
- TestKase vs SiteimproveA developer tool rather than a governance platform
- TestKase vs Level AccessAccessibility scanning without a services engagement
- Accessibility overlaysWhy we do not sell one, and what the evidence says
- All of Why TestKaseHow we compare with the tools you are probably already paying for
- PricingPer-seat test management and per-thread device testing, priced on the page
Same findings, read a different way
Scan a public address and look at what the report opens with, and at how much of the standard it admits it did not measure.