How it works
One loop: detect, fix, prove, keep
Four steps, each of which ends in evidence rather than an assurance. This page is the long version — every mechanism named, and nothing described that the product does not do.
01 — Detect
Scan the store a visitor actually sees
A scan renders your pages in a real browser, then runs three independent accessibility engines over the result: axe-core, HTML_CodeSniffer and IBM Equal Access. Three engines rather than one is not belt-and-braces for its own sake: they disagree, and the disagreement is information. Every finding records which engines saw it, so you can tell a three-of-three certainty from a single-engine judgement call.
On top of the engines, nine custom probes measure things no rule-based engine tests, because they need measurement rather than inspection: whether interactive targets are big enough, whether the page reflows at a 320-pixel width without sideways scrolling, whether text survives increased spacing without clipping, whether keyboard focus can get trapped, whether the focus indicator has been suppressed in a stylesheet, and whether content keeps animating after the visitor has asked for reduced motion.
Which pages
Home, a real product page, a populated basket and a hydrated checkout — plus whatever else page discovery finds worth looking at. The basket and checkout matter more than everything else combined, and they are exactly where most scanners stop: an empty basket renders nothing, and a WooCommerce block checkout is a React application that has to be waited for before it exists. The scanner adds a product, waits for hydration, and scans what a shopper meets.
Findings are attributed to the page they came from, and the scan states plainly whether checkout was reached with a real basket, an empty one, or not at all. A scan that could not reach checkout says so rather than quietly reporting on your home page and calling it a store.
What comes back
Two layers. A coverage map across the whole automatable WCAG surface — every criterion the engines flagged, with the rule ids and the engine agreement behind it — and a shorter list of actionable failure families, which are the things the product can do something about. All ten families are documented, with the real rules and the real tier for each.
There is no score. Not a grade, not a percentage, not a badge. A number like that compresses away the only thing that matters — which barrier, on which page, for whom — and it invites you to optimise the number instead of the store.
02 — Fix
Generate the real repair
Some fixes are arithmetic. A missing document language is answered by your site's own locale; a colour that fails contrast has a mathematically nearest passing shade that keeps your hue. Those are computed deterministically, because a model would only add uncertainty to a problem that has an exact answer.
Others need judgement — what a product photograph shows, what an icon-only link does, what an unlabelled checkout field is for. Those are drafted by a model with the surrounding page as context, and then audited by a second, different model whose only job is to disagree. The audit gate produces a confidence, and the confidence decides the route:
- High confidence — applied, then independently re-validated in the served page.
- Medium or low — sent to your review queue with the proposal filled in. You approve, edit or reject. Nothing goes live on a guess.
- Not answerable from the page — flagged for a human expert. A decorative flourish and a size chart look identical to a machine; only one of them should have alternative text.
What is applied automatically, and what is not
7 families can be applied for you once you approve the plan: missing document language, images without alternative text, links with no discernible text, buttons with no accessible name, form fields with no label, no skip link past repeated content, checkout fields missing an autocomplete purpose. 3 always wait for a human: text that fails colour contrast, landmark structure problems, ambiguous link text. That split is not a limitation we are apologising for — it is the difference between a tool that respects your store and one that edits it behind your back.
03 — Prove
Verify it in the page a visitor receives
The fix is applied by the Klarvo Access plugin, on your server, at output time. It is a targeted rewrite of the specific tag that failed — identified by a hash of its exact served bytes, so the plugin cannot touch the wrong element — with an integrity fail-safe that abandons the change rather than emitting something malformed. Your markup is never parsed and re-serialised whole, which is why block themes with inline SVG survive it intact.
Then the engine goes and looks. It re-fetches the live URL, cache-busted, and re-runs the specific check that failed against what actually came back. Only then is the fix marked validated and the issue resolved.
The cache is part of the truth
A fix that exists in your application but not in what Varnish, WP Rocket, LiteSpeed or Cloudflare is serving has not reached anybody. So verification runs against the visitor's view, and when the cache is still serving stale markup the fix is recorded as pending cache — an honest state, not a failure and not a success. It promotes itself when the cache turns over.
The paper trail
Every applied fix writes an append-only conformance record: what was found, what was generated, what was applied, what the re-validation saw, and when. Append-only matters — records are never rewritten, so the history of your store's remediation is evidence rather than a current-state dashboard. That is the artefact an auditor, a procurement team or a regulator will actually engage with.
An automated finding is evidence, not a certificate. Conformance is certified only by the professional audit — scoped, dated and signed by qualified humans.
04 — Keep
Stay fixed, provably
Accessibility is not a state you reach, it is a state you hold. A theme update, a new plugin, a marketing banner or a fresh batch of products can reintroduce in an afternoon what took a week to fix. So the store is re-scanned on a schedule — monthly, weekly or daily by plan.
A regression is detected by observation, not by assumption: a fix has regressed when the engine can no longer see its effect in the served HTML. When that happens you get an alert naming the fix, the page and what changed, and the loop runs again. When it recovers, the alert closes symmetrically — the same evidence standard, in both directions.
The accessibility statement your store serves is regenerated as the picture changes, so the public claim and the private state stay in step. A statement that says something your store stopped doing three months ago is worse than no statement at all.
The honest edge
What this loop cannot do
It cannot tell you whether your error messages are actually helpful, whether your form's reading order makes sense to someone who cannot see the layout, whether your alternative text is accurate rather than merely present, or whether a drag-and-drop interaction has a workable single-pointer alternative. Of 55 WCAG 2.2 A and AA criteria, 16 have no automated rule behind them anywhere in the industry, and we would rather list them than imply otherwise.
It also cannot make a store accessible that was built on inaccessible foundations. A fix applied at output time is a genuine repair, and it is not a substitute for a theme that was built properly. Where the honest answer is "this needs a developer" or "this needs a human audit", the product says so.
The professional audit is where the rest gets done, and it is the only thing here that can produce a statement of conformance.
FAQ
Questions this raises
Does the plugin change my theme or my database?
No. Fixes are applied to the HTML at output time, from a small store the plugin keeps. Your theme files, posts and product data are untouched, and deactivating the plugin returns your markup to exactly what it was.
What if a fix would be wrong?
Then it should not be applied, and usually it is not. Fixes generated by a language or vision model are checked by a second model before they go anywhere, and anything the check is not confident about is routed to your review queue instead of being applied. Colour changes are never applied automatically at all — a contrast fix is a brand decision, so a human always approves it.
How do you know a fix actually reached visitors?
Because we look. After the plugin applies a fix, the engine independently re-fetches the page — cache-busted, the way a fresh visitor would receive it — and re-runs the relevant check against what came back. If your full-page cache is still serving the old markup, the fix is recorded as pending cache rather than resolved. Saying "pending" is more useful to you than saying "done".
Does the scan reach the checkout?
Yes, and that is unusual. The scanner discovers a product, adds it to the basket, and scans the hydrated checkout as a shopper would meet it — including a WooCommerce block checkout, which most tools never render. On the Scale plan it can also sign in and scan account, basket and checkout as a logged-in customer.
What cannot be automated?
Plenty, and we publish the list. Of the 55 WCAG 2.2 Level A and AA success criteria, 39 have at least one automated rule or probe behind them and 16 have none, because they need human judgement — whether an error message is genuinely helpful, whether a drag interaction has a single-pointer alternative, whether alternative text is accurate rather than merely present. Those are what the professional audit is for.
Run the scan. Keep the evidence.
Three engines, your real pages, checkout included — free, no signup. If it finds nothing, you'll know. If it finds something, you'll know exactly what, where, and how it gets fixed.