RatedWithAI

RatedWithAI

Accessibility scanner

Buying AccessibilitySeptember 16, 2026

An Audit Is a Photograph. Monitoring Is a Smoke Alarm.

These two products are sold into the same budget line and answer opposite questions. One tells you where you stand, in depth, on a date. The other tells you that something changed, shallowly, forever. Buying the wrong one first is the most common and most expensive mistake in accessibility procurement.

Depth
What an audit sells — criteria a machine cannot evaluate
Recurrence
What a subscription sells — the same shallow check, forever
Order
Baseline first, then the detector. Reversed, the dashboard means nothing

They Are Not Competing Products

A manual audit buys you depth on a sample. A person drives your interface with a keyboard and a screen reader, works through the journeys, and reports on criteria that require judgement: whether the alternative text describes what matters, whether focus lands somewhere sensible when a dialog opens, whether an error is announced as well as shown, whether a custom dropdown behaves like a dropdown to anything other than a mouse. It is expensive because it is human time, and it is out of date the moment you deploy.

A monitoring subscription buys you recurrence on breadth. It crawls, applies a rule engine and reports deltas. The rules are the machine-checkable minority of WCAG, and no amount of subscription tier changes that ceiling — a more expensive plan crawls more pages more often, not more deeply. What it gives you that an audit cannot is a dated trail and an alert when last Thursday's release removed the labels from your checkout form.

Stated plainly: the audit tells you where you are, and the subscription tells you when you move. Vendors blur this because the subscription is the recurring line, so a scan product gets described in the vocabulary of conformance. Read any "compliance score" as what it is — a count of machine-detectable defects, which can sit at a comfortable number on a site nobody can actually use.

The Ceiling on Automation, and Why It Matters for Sequencing

Automated rules catch a real and useful slice of accessibility failures — the ones that are structural, unambiguous and constantly reintroduced. They cannot catch the ones that require knowing what the page is for. An image with the alternative text "image" passes a presence check and fails a user. A focus order that jumps from the header to the footer passes every rule in the engine. A modal that traps nothing and announces nothing is invisible to a crawler and impassable to a screen reader user.

This asymmetry is the whole argument for sequencing. If you buy monitoring first, you get a number with no interpretation, trending sideways, generated by the layer that matters least. Teams in that position typically spend a year chasing contrast warnings and arrive at a complaint about a form they never tested. If you buy the audit first, you get a position, a backlog and a list of fixed issues — and then a monitoring product has something specific to protect.

The Question That Actually Decides It: Who Can Publish?

Skip the vendor comparison for a moment and count the people who can put something in front of a customer without a developer reviewing it. Marketing publishing landing pages in a builder, support editing help-centre articles, a documents team uploading PDFs, a product team shipping weekly behind flags. Every one of those is a source of accessibility regression that no amount of audit depth prevents, because the audit happened before the content existed.

A high count is the case for recurrence, and it is a strong one. A low count — a small team, a slow cadence, a static marketing site with a design system — points the other way: an annual audit with a mid-year retest, plus automated checks in the build pipeline, will cover you for a fraction of a platform subscription. Run the same test on volume. A hundred-page site has a different economics from a hundred-thousand-page catalogue where nobody has seen most of the templates in years.

  • Weekly releases plus non-developer publishers: recurrence earns its price.
  • Quarterly releases, one design system, few publishers: audit plus CI checks.
  • Large template estate nobody has inventoried: crawl breadth first, then audit deep.
  • Regulated or transactional journeys: depth is non-negotiable regardless of cadence.
  • Heavy PDF estate: neither product covers it — price document remediation separately.

Three-Year Arithmetic, Including the Part Nobody Quotes

Compare the two over three years rather than as line items, and include the costs that do not appear on either invoice. An audit programme is the audit fee, the retest, and the developer time to remediate — which is usually the largest number in the exercise and the one left out of both proposals. A subscription is the annual licence, plus integration time, plus the ongoing cost of triaging its output, which is real: a scanner that reports thousands of instances of the same component defect across a catalogue generates work that has to be deduplicated by a person.

Ask the questions that reveal the tail. How is the plan metered — pages, scans, domains, seats — and what happens when the site grows? Can findings be exported in an open format, on demand and at termination, or does the history live only in the dashboard? Does the platform bundle an overlay or a widget, and can it be disabled without losing the scanning? That last one matters more than it sounds: an injected accessibility widget is a separate product with a separate risk profile, and several monitoring products ship one by default.

A Sequence That Works for Most Teams

Scan first, before you buy anything, so you know the size of the machine-detectable layer and can recognise a bid that is quoting you for it. Then audit a named sample — templates plus whole journeys — to establish a position on the criteria a scan cannot reach. Remediate against that backlog, verify with a contracted retest, and only then decide whether the regression risk on your publishing surface justifies a recurring product. If it does, wire the code half into CI and buy scanning for the content half.

Done in that order, each purchase is legible: the audit produces a backlog, the retest closes it, and the subscription defends a known state. Done in the other order, you own a dashboard, a score and no idea what either means.

Questions Teams Ask When the Renewal Lands

Our monitoring score has been flat for a year. Is the product broken?

Probably not — it is more likely measuring a layer you already fixed while the criteria that move user experience sit outside its reach. A flat automated score is consistent with both a healthy site and a badly broken one, which is the core limitation. The diagnostic is cheap: take three complete journeys and try them with a keyboard only, then with a screen reader. If those are fine, the flat line is good news and you can drop to a lower tier. If they are not, the score was never the measurement you thought you were buying.

How often should we re-audit if we already monitor continuously?

Annually is the common cadence, with two triggers that override the calendar: any material redesign of a template or journey in scope, and any migration of the platform underneath it. The reason monitoring does not extend the interval is that it does not sample the same criteria — a year of green automated scans tells you nothing about whether the new checkout announces its errors. Where monitoring does help is making the re-audit cheaper, because the machine layer arrives already clean and the auditor's hours go to the judgement criteria.

The vendor offers audit and monitoring bundled at a discount. Worth it?

Often, provided the deliverables stay separable and the retest is independent of the party doing remediation. The bundle risk is not the price, it is that the conformance statement and the tool producing the score end up owned by the same vendor whose renewal depends on the number looking good. Ask for the audit findings in a portable format, keep the right to take the audit elsewhere next cycle, and confirm you can cancel the subscription without losing access to the historical findings.

We have an overlay widget already. Does that change the calculation?

It changes what you should ask the scanner to report. Overlays modify the page after load, so a monitoring product from the same vendor may be scanning the post-injection DOM and reporting on a version of your page that assistive technology users may not experience the way the dashboard implies. Ask explicitly whether scans run with the widget active or disabled, and request at least one run with it off. That number is the state of your actual markup, and it is the one a retest after remediation has to move.

What is the smallest sensible programme for a small team with no budget?

An automated scan of your top templates on a schedule you actually read, accessibility rules in the build pipeline so component regressions fail a pull request, a keyboard-only walk of your two most important journeys each quarter, and a dated note of what you found and fixed. That is not conformance and does not pretend to be, but it catches the constantly-regressing layer, covers the journeys that generate complaints, and produces the dated trail that matters if anyone ever asks what you have been doing.

Get the Baseline Before You Sign Anything Recurring

The machine-detectable layer is the part every subscription measures and the part you can see for free. Read it first — it tells you whether a monitoring quote is selling you coverage you do not have or a report you could already run.

Then decide on one question rather than on a feature grid: how many people can publish to production without a developer looking? That number, not the vendor comparison, is what makes recurrence worth paying for.