Method
Four layers of audit. And a test bench that watches us.
Two analysis engines that overlap, paths tested all the way past the customer login, the official standard, then a human on everything the automated tools cannot see. And since an auditor has to accept being audited, our own toolchain takes the exam: a control site with known defects measures what it catches, and what it misses.
The audit
Four layers, each one covering the blind spots of the one before
- 01 · Two engines, on the page as rendered The page is loaded in a real browser, JavaScript executed, scrolled to the bottom to wake up lazy content, then analyzed by two independent engines: axe-core (Deque) and accessibility-checker (IBM). Each has its blind spots, and they are not the same ones. The results are then de-duplicated element by element: a defect seen by both engines counts once, not twice. Never an inflated count.
- 02 · The checkout flows, behind the login A public scanner stops at the login page. Your buyers carry on: account, cart, order, payment. We script those paths with Playwright, keeping the authenticated session from one step to the next, and every screen along the way goes through the same two-engine analysis. That is where the sale happens, so that is where we go.
- 03 · Mapping to the RGAA An engine rule ID means nothing to anyone. Every rule that fires is tied to the criteria of RGAA 4.1.2, the French accessibility standard, through the official mapping table published by the French government (DISIC, Licence Ouverte 2.0). Where our table stands: 53 rules encountered on real sites, 41 tied to a criterion (77.4%), and not one rule left unclassified. When the match is not clean, it is flagged “to verify”, never promoted to compliant.
- 04 · The human pass Keyboard-only navigation, focus order, reading with a screen reader, 200% zoom, labels that make sense out of context: the criteria that actually stop people from buying are tested by hand, on the templates your buyers go through. The first three layers draw the map; this one decides.
The limits, in numbers
What automated testing will never see, and how we know
Anyone selling you a “complete scan” is selling you a blind spot. The public numbers are stubborn: the Deque study measures that about 57% of the volume of problems can be caught automatically. The rest takes eyes, hands and a screen reader.
The UK government accessibility team ran the opposite experiment: a page built on purpose with 143 defects, run through 10 automated tools. The best one identified 41%, one of the most widely used 17%, and 42 defects (29%) escaped every tool put together.
So we stopped taking our tools at their word: we built a control site where we know every defect, 17 documented problems injected on purpose. Our toolchain catches 12 of them, that is 70.6%. Every miss is listed, explained, and handed to the human pass. That rate is recomputed on every change to the toolchain: the day it drops, we see it before you do.
A “zero errors found” report is not a compliance report. It is a tool report.
After the fix
Fixed is not enough: every delivery is replayed
A fix is not “done” because the developer says so. Before every delivery, an automated acceptance run replays the checks one by one: the probe goes back over the corrected pages, every criterion delivered has its own runnable check, and the whole thing produces a time-stamped report, check by check, passed or failed.
The rule is mechanical: as long as the acceptance run does not pass, we do not deliver. And an acceptance run with no verifiable criterion is rejected by design, so that an empty “all good” can never pass for proof.
The same mechanism serves the long haul: your theme changes, the probe replays, and an accessibility regression shows up in a dated report instead of surfacing six months later in a formal notice.
The doctrine
Selling without scaring anyone
The accessibility market has built itself a bad name on imaginary fines. We do the opposite, and we put it in writing: here is what you will never hear us say.
- “Fines are raining down” They are not. No EAA fine confirmed as of mid-2026, and we are the first to tell you. The real risks are elsewhere: injunctions carrying a penalty, lawsuits brought by nonprofits, and the sale lost every day to a checkout flow that drives people away.
- Case law that only goes one way Court rulings go both ways, and we quote both: the one that ordered full compliance under a penalty, and the one that dismissed an identical claim. You decide on the full map, not on the excerpt that suits the seller.
- “100% compliant, guaranteed” Nobody can guarantee that seriously, and the accessibility statement is still issued under your own responsibility. Our commitment lies elsewhere: that it be true, documented, and redone at no charge if a third-party audit fails a criterion we delivered.
- A number with no source Every number published on this site has a link, a court ruling or a measurement behind it. A number we cannot source is not published, even when it suits us.
Fear gets one signature. Proof is what makes people stay.
The tooling
Tools whose license we can show you
You will always know what your audit was produced with. Every component of the toolchain is entered in an internal registry with its exact license, read from the project repository, never assumed. A component missing from the registry is forbidden by default.
Scroll the table to the right.
| Component | Role in the toolchain | License |
|---|---|---|
| Playwright | Browser control, authenticated flows | Apache-2.0 |
| axe-core (Deque) | First analysis engine | MPL-2.0 |
| accessibility-checker (IBM) | Second analysis engine | Apache-2.0 |
| WCAG to RGAA 4.1.2 table (DISIC) | Mapping to the official standard | Licence Ouverte 2.0 |
| EXPawa toolchain (probe, flows, bench, acceptance run) | Orchestration, de-duplication, reports | EXPawa proprietary code |
This registry has teeth: viral licenses (AGPL) are ruled out on sight, and so are components copied and modified under a contaminating license, however popular they are. No code under a problematic license can end up in work that belongs to you.
And the check runs without us, on a fixed schedule: on every change to the toolchain, continuous integration verifies the license of every dependency and refuses to build if a forbidden license appears. We put it to the test by deliberately injecting a GPL component: build refused, as expected.
A method is told. An exposure report is shown.
The simplest way is to see it applied to your own site: a free exposure report, built on the page as it really renders, with your own lines of code.
One question keeps coming up: an independent, against an agency? Our honest answer, case by case.