Eight stages. The first three are automated, the middle three are your team’s, and the last two are what a lawyer asks for.
Automate what can be automated. Manage what requires humans. Prove what was fixed.
The eight stages
1
Discover
automated
What happens
A crawl of your registrable domain, obeying robots.txt and its crawl delay. Canonical URLs are normalised so one page is one page.
You see
4,182 pages · 1,180 documents, plus what was skipped and why
It produces
The page inventory and the document inventory
It cannot
Reach anything behind a login. Public pages only, by design — storing your credentials would move your data into a more expensive band of every state security framework.
The engines named in the footer attribution run on each sampled page at Desktop (1280 × 800) and Mobile (390 × 844), tagged wcag2a, wcag2aa, wcag21a, wcag21aa. The primary engine is version 4.13.0, and every finding records which engine and which version produced it.
You see
Violations and results needing review, with the rule id, the WCAG criterion and the failing element. There is no count of checks that succeeded, because the finding model holds no such value.
It produces
Raw findings — one engine result, on one page
It cannot
Detect most of what matters. Automated testing detects roughly 30–40% of real barriers. Manual testing covers the rest. 16 of the 50 WCAG 2.1 AA success criteria have any automated coverage — 32%.
Pages are clustered into templates by structural similarity, and findings are collapsed onto a fingerprint of engine, rule, template, DOM shape, viewport and platform.
You see
4,000 URLs are 12 templates; we scanned 8 pages of each. 27 issues across 4,182 pages.
It produces
Issues — the unit you act on — and occurrences, one per affected page
It cannot
Merge a desktop and a mobile defect. Viewport is part of the identity, so the same defect at two viewports is two issues, and the same defect on iOS and Android is two more.
4
Assign
your team
What happens
An issue is given an owner and a status, or it is deferred — with a written reason, a named owner and a review date.
You see
Assigned with the person's name, or Deferred with its owner, reason and review date, always shown together
It produces
An ownership record, and an event in the ledger
It cannot
Assign itself. Nobody is auto-assigned, and no issue is closed by the system.
5
Remediate
your team
What happens
Written guidance per issue, split by audience — content editor, developer, designer — and by effort: trivial, small, medium, large.
You see
The failing element, its DOM path and a fix description you can paste into a ticket unchanged
It produces
Nothing in your site. We never touch your site.
It cannot
Fix anything. No overlay, no injected script, no automatic remediation, and no generated alternative text — no code path in the product writes alt text, and a test greps for its absence on every build. The product makes no AI suggestions. If it ever does, they will be off by default, never applied on their own, never counted as verification, and labelled “AI suggestion — not verified. Review before applying.”
6
Retest
your team
What happens
The next scan re-checks every occurrence, and a person can verify by hand with a named method and a named assistive technology.
You see
Ready to verify means claimed. Verified means checked. They are two different states and they never look the same.
It produces
A verification event naming the actor, the method and the tool: Verified by Maria Sandu on 2 October 2026, manual method, NVDA 2026.1 with Firefox
It cannot
Confirm a criterion automation cannot test. A criterion checked only by an engine is never published as a conformance claim.
7
Prove
the record
What happens
Every change is appended to a hash-chained ledger, and the ledger is exported as an evidence packet.
You see
Chain intact — 2,341 events verified, 12 March 2026 to 8 September 2026; or Chain broken at event 1,987 — 8 September 2026; or Cannot verify, which is never silently reported as intact
It produces
An export a third party can verify without trusting us or running our code
It cannot
Assert conformance. The product never issues a verdict on a website's legal compliance — not in a report, not in a badge, not in an export.
8
Monitor
the record
What happens
Each asset is scanned on a schedule — weekly by default, or daily or monthly — and a scan can be compared with an earlier scan of the same asset, with each change between them classified.
You see
New, Regressed, Spread to more pages, Template broke — the last is the most severe
It produces
A comparison on screen, and email: a weekly digest of what changed, and an alert when a critical issue comes back, a template breaks, a scan fails three times running or a deadline is 90 days away. Nothing is sent when nothing changed.
It cannot
Watch your mobile apps. Mobile auditing is not built yet.
What automated testing can and cannot check
Real barriers detected by the best automated tool
30–40%
WCAG 2.1 AA criteria with any automated coverage
32%, 16 of 50
WCAG 2.2 AA criteria reliably flagged automatically
13%, 7 of 55
Individual errors detectable automatically, by volume
about 57%
12 WCAG success criteria, how much of each an automated engine can check, and what a person still has to do. Ordered by automated coverage, from most to least.
Success criterion
Automated
What a person still has to do
1.4.3 Contrast (Minimum)Level AA
AutomatedYes
What a person still has to doCheck text over images and gradients, which the engine skips
1.4.11 Non-text ContrastLevel AA
AutomatedPartly
What a person still has to doJudge which graphics are meaningful
1.1.1 Non-text ContentLevel A
AutomatedPartly
What a person still has to doDecide whether the alternative text is correct, not merely present
1.3.1 Info and RelationshipsLevel A
AutomatedPartly
What a person still has to doConfirm the visual structure matches the markup
4.1.2 Name, Role, ValueLevel A
AutomatedPartly
What a person still has to doOperate custom controls and listen to what is announced
3.3.1 Error IdentificationLevel A
AutomatedPartly
What a person still has to doSubmit the form wrongly and check what is said
2.4.7 Focus VisibleLevel AA
AutomatedPartly
What a person still has to doLook at every focusable element in every state
2.1.1 KeyboardLevel A
AutomatedNo
What a person still has to doOperate every control from the keyboard alone
1.4.10 ReflowLevel AA
AutomatedNo
What a person still has to doZoom to 400% in a 320 px viewport and read the page
2.5.8 Target Size (Minimum)Level AA (2.2)
AutomatedNo
What a person still has to doMeasure the controls people actually miss
1.2.2 Captions (Prerecorded)Level A
AutomatedNo
What a person still has to doWatch the video and read the captions
1.2.4 Captions (Live)Level AA
AutomatedNo
What a person still has to doAttend the meeting stream
Roughly two out of three real barriers require a human. That is why guided manual testing is in the product and in the same tables as the automated results — not sold separately, and not left to you.
What you get at the end
An evidence packetPDF, tagged, with a JSON sidecar
Every event with its actor, its timestamp and its hash; the scope statement naming what was and was not tested, including vendor systems; the methodology statement naming every engine and version; and the chain verification result.
A conformance reportVoluntary Product Accessibility Template (VPAT) 2.5Rev, as HTML and .docx
One row per success criterion, marked Supports, Partially Supports, Does Not Support or Not Applicable, with remarks on every row that is not Supports.
A remediation planHTML and CSV
Criterion, what fails, owner, effort and target date — one line per open item, in the five project phases: quick wins, template fixes, content remediation, documents, structural.
An accessibility statementHTML, published on your own site
What conforms, what does not, the date it was assessed, and a feedback channel that reaches a real person with a stated response time.
Every one of these is generated from the same ledger. None is written by hand, and none can say something the record does not support.
Where the numbers on this page come from
The 30–40% figure, the 32% coverage figure and the 57% by-volume figure are drawn from published research on automated accessibility testing, not from our own product. We do not publish a benchmark of our own engine against a commercial one — the licence terms of the tools involved forbid it, and a vendor’s self-run benchmark is not evidence anyway. Where a figure on this site cannot be sourced, it is not stated. If you think one of these numbers is wrong, write to us and we will correct the page or cite the source.
What we will not do
No injected script. We make no request to your site outside a scan you started, and we serve nothing from your domain. There is no snippet to install.
No score. There is no column in the schema that holds one, no percentage of the standard, no grade, and no ranking of one entity against another. A number that averages 1.4.3 with 2.1.1 means nothing.
No generated alternative text. No code path generates, suggests or applies it, and a test greps the codebase for its absence on every build.
No verdict on legal compliance. The product cannot emit one. No template, no export and no string table in it contains such a sentence.
Questions engineers ask
Which engines do you run?
The attribution in the footer of this page names all 3 of them. The primary one is version 4.13.0 and the second is IBM Equal Access 4.0.33/13July2026. Every finding records which engine and which version produced it, because violation counts move between engine versions without the site changing.
Why do you not run best-practice rules?
They are not WCAG requirements, and reporting them as issues inflates the count with things nobody is obliged to fix. We run wcag2a, wcag2aa, wcag21a and wcag21aa.
What happens when the engine version changes?
Any comparison across a version change carries a visible caveat, in these words: “Engine versions changed between these scans. Some differences may reflect the engine, not the site.” It is not dismissible, because a difference that moved with the engine is not a difference about your site.
How many pages per template do you scan?
A structured sample — one page per template, every page in a complete process, the home page and unique-functionality pages — plus a random sample. The sample and the reason each page was included are stored with the scan.
Will scanning slow our site down?
2 concurrent requests per host by default, rising to 8 only if you raise it yourself, with a minimum of 250 ms between requests. robots.txt is obeyed, including its crawl delay. Scans run on the asset’s schedule, at a time assigned to your organisation so customers’ scans are spread across the day, or when you start one. The full politeness table is on the crawler page. If your host still sees load, tell us and we will slow it further.
Is there an API and a CI check?
A versioned public API, at /api/v1, with API keys, signed webhooks and an OpenAPI 3.1 document; the API documentation prints its examples with the responses they get from the sandbox. The GitHub App is built and registered with GitHub; the settings screen that installs it is not built yet, so we send the installation link on request. The command-line tool is built and not yet published: it scans the pages you name with the same engines and configuration as the platform, compares them with the asset’s baseline, and exits 0, 1 or 2 — when the tool itself fails it exits 2, never 0. The GitHub App’s permission list is on the security page, so you can read what it asks for before anyone installs it.