What accessibility tool pricing models tell you about the product

A prospect asked me last month why our pricing page has a table of token costs on it instead of a "contact sales" button and three tiers named after metals. The honest answer is that we tried the vague version first, and every demo call started with fifteen minutes of the buyer trying to reverse-engineer what they would actually be billed. It was faster to just publish the arithmetic.

That conversation stuck with me, because it points at something buyers underuse when evaluating accessibility tools. A pricing page is not just a number. It is a description of what the vendor thinks the valuable unit of work is — and by extension, what the product is built to do well. If you read a pricing model carefully, you can usually predict how the tool will behave once it is in your stack, and where it will start to hurt.

Here is how to read the common ones.

Per-page pricing

You pay per URL scanned, usually per month. Sometimes it is bundled as "up to 10,000 pages."

This model comes from the enterprise site-monitoring world, and it tells you the product is oriented around breadth of coverage. It is optimized for a marketing site or a large content estate where the pages are mostly static, mostly similar, and the question is "which of our 40,000 URLs have problems."

Where it gets awkward is application software. A single-page app might be one URL and forty screens. A dashboard behind a login might be three routes and hundreds of states. Per-page pricing systematically under-prices static content and over-prices, or simply fails to measure, the interactive product where most WCAG failures actually live — focus management, keyboard traps, form errors, live regions.

The question to ask a per-page vendor: how do you count a route that renders twelve different states depending on user data? If the answer is "one page," you are getting one page's worth of coverage.

Per-seat pricing

You pay per user with access to the dashboard.

Per-seat says the product's value is in people looking at it. That is a reasonable model for design tools, browser extensions, and manual testing platforms — things a human operates. It is a poor fit for automated remediation, because the natural way to use a scanner is to run it in CI where no human is sitting.

Per-seat also creates a bad incentive inside your own org. If seats cost money, you limit them, and accessibility becomes something two people can see. That is exactly backwards from what you want, which is every engineer seeing violations on their own pull request. Teams end up with a designated "accessibility person" who forwards screenshots — a bottleneck the pricing model created.

The question to ask: does running this in CI require a seat? And can a developer who has never logged in still see the finding on their PR?

Per-scan or credit-based

You pay per scan, or you buy a pool of credits and scans draw down against it.

This model says the vendor thinks the unit of value is the analysis run. It usually means the product is genuinely automated — nobody is charging per scan if a human is doing the work behind the curtain. It is also the most honest model for variable workloads, because a team shipping daily and a team shipping quarterly are not paying the same price for very different usage.

The tradeoff is forecasting. Credit models make it harder to answer "what will this cost next year" and they punish exploratory use — running the same scan three times to check whether a fix landed feels expensive in a way that a flat subscription does not. Good credit pricing publishes the per-action cost so you can do the math yourself. Bad credit pricing keeps the exchange rate fuzzy.

For transparency, ours: a web scan costs 2 tokens, a repo scan costs 8, and an auto-fix pull request costs 1. Starter is $29/mo for 40 tokens, Growth $99 for 200, Scale $349 for 800, Enterprise is quoted for 2,000+. Tokens do not roll over month to month, and when you run out, scans pause until you upgrade — I would rather say that plainly here than have you find out on a Thursday. Every plan gets every feature; the tiers differ only in budget. The full breakdown is on the pricing page.

Annual contract with a services component

You pay a yearly platform fee, plus an audit or remediation engagement, often with named hours.

This says the vendor's real product is expertise, and the software is the delivery vehicle. That can be exactly right — manual testing by people who use assistive technology daily finds things no automated tool catches, and if you need a defensible audit for a legal or procurement requirement, you need humans.

What to watch for is the ratio. If the software license is $12k and the services engagement is $80k, you are buying a consultancy with a login page. That is fine if it is what you wanted. It is a surprise if you thought you were buying a tool that scales with your team.

The question to ask: after the engagement ends, what does the product still do for us on its own?

Flat subscription with unlimited scanning

You pay a fixed monthly fee, scan as much as you like.

Attractive on the surface, and sometimes it is exactly what it says. But unlimited is only cheap for the vendor if the underlying operation is cheap, which tends to mean the scanning is shallow, cached aggressively, or rate-limited somewhere in the fine print. Nothing wrong with that — a fast static scan across many URLs is a real service. Just calibrate: unlimited usually signals detection, not remediation. Generating a fix costs real compute every time, and nobody offers that unmetered.

Free, funded by something else

Free tools exist and some are excellent. axe-core is open source and it is the detection engine underneath a large share of the commercial market, ours included. Browser devtools ship accessibility panels. Linters catch violations before commit.

The thing to understand is what the free tool is for. Open source detection engines are funded by the commercial products built on them, and the free tier stops where the vendor's business starts — usually at reporting, workflow, remediation, or scale. That is a fair trade, not a trick. But "we already use the free scanner" is not a pricing comparison; it is a scope comparison, and the honest version is that the free scanner does one part of the job well and does not attempt the rest.

What the model does not tell you

Pricing structure predicts product shape. It does not predict quality, and it is not a substitute for the questions that actually determine whether a tool works for you:

• What percentage of WCAG criteria can it evaluate automatically at all? Deque's published guidance on axe-core puts automated coverage at roughly 57% of issues; the rest requires human judgment. Any vendor implying otherwise is selling something.
• What does it do with a finding once it has one? A list is not a fix.
• What frameworks does it actually support today, not on the roadmap? Ours are HTML, CSS, JSX/TSX, and SCSS. Angular is roadmap.
• Where does your source code go, and for how long?
• Can you get out? Exported findings, or a dashboard you can never leave?

If you want the vendor-by-vendor version of this, we keep comparison pages that try to be fair about where we are behind — Siteimprove, accessiBe, axe DevTools, and TestParty. Pricing changes constantly, so check each vendor's own site for current numbers; we do not try to keep their price lists accurate on our pages.

A short exercise before your next vendor call

Open the pricing page. Do not look at the number first. Look at the unit — the thing being counted. Then ask yourself whether that unit is the thing you are trying to buy.

If you are trying to reduce the number of open WCAG violations in your codebase, and the unit being counted is pages crawled or people logged in, the model and the goal are not aligned. That misalignment does not mean the tool is bad. It means you will be paying for coverage of something adjacent to your problem, and the gap will show up six months in as a report nobody actions.

The tools worth your budget are the ones where the unit of billing is the unit of work you actually need done. Everything else is a proxy, and proxies drift.

More on how we think about scope and limits in the FAQ, and there are other posts on tooling and procurement over on the blog.

If you want to see what a repo scan and an auto-fix pull request look like against your own codebase before you commit to any of this, book a demo at inklu.io or email hello@inklu.io. Fourteen-day trial, 50 credits, demo required first — self-serve signup is coming but is not live yet, and I would rather tell you that now than in a footnote.