Your scanner found 47 issues. A regulator will ask about clause 9.1.4.3.
Published 21 August 2026.
Enforcement of the European Accessibility Act started on 28 June 2025, and it started for real. French disability organisations issued formal notices to four major grocery retailers within days. Sweden opened market surveillance that October. The first EAA cases reached a French commercial court in November.
If you sell into the EU and you are not a microenterprise providing services, somebody can now ask you what you have done about it.
The awkward part is that the tooling most teams reach for does not produce an answer to that question. It produces a different, adjacent answer, and the gap between the two is where a lot of otherwise diligent teams are about to get caught.
The mismatch
You run axe, or Lighthouse, or Pa11y. You get output like this:
color-contrast 10 nodes serious
label 1 node critical
image-alt 1 node critical
link-name 1 node serious
html-has-lang 1 node serious
Correct, useful, and not a conformance claim.
Conformance under the EAA is claimed against EN 301 549, the
harmonised European standard, clause by clause. Nobody has ever been asked to
demonstrate conformance with color-contrast. They get asked about
clause 9.1.4.3.
So the translation has to happen somewhere. Usually it happens in a spreadsheet, by hand, by whoever drew the short straw, and it happens again every time the site changes.
Three things that make this worse than a naming problem
Not all of WCAG is binding, and the binding part is about to move
The harmonised standard today is EN 301 549 V3.2.1 (2021-03), which adopts WCAG 2.1. Criteria introduced in WCAG 2.2 — target size, dragging movements, accessible authentication — are good practice, not current EAA obligations. Plenty of tools report 2.2 findings with the same red badge as everything else, which inflates your problem and burns engineering time on work no regulator is asking for yet.
The word doing the work there is yet. EN 301 549 V4.1.1 adopts WCAG 2.2 and is expected to be cited in the Official Journal around the end of 2026. An obligation begins when a version is cited there, not when ETSI publishes it, so V3.2.1 is still the yardstick as I write this and will not be for much longer.
Anyone telling you 2.2 is already mandatory is wrong today. Anyone telling you to ignore it is setting you up for a rewrite.
Severity is not exposure
Rule engines sort by how confidently they can complain. Ten contrast failures in a footer will outrank one unlabelled password field in the checkout, and that ordering is exactly backwards from the one that matters. One of those stops a person from buying something. The other is real, required, and not an emergency.
A clean automated run is not a pass
Automated testing detects roughly a third of accessibility barriers. Keyboard traps, focus order, whether alt text actually says anything useful, whether a screen reader can make sense of your custom component — none of that is decidable by a rule engine. The clauses your scanner cannot evaluate do not appear in its output at all, which reads as silence, which reads as fine.
The part where money is being wasted
Two products are sold to make this go away, and neither does.
Overlay widgets. One line of JavaScript, a promise of compliance, and a subscription around $490 a year.
The US Federal Trade Commission brought a case over exactly that promise in January 2025 and approved the final order in April, requiring accessiBe to pay $1,000,000. The complaint also covered third-party articles and reviews formatted to look like independent opinions when the company had an undisclosed connection to them.
Separately, UsableNet's 2026 midyear report found that about 20% of the companies sued over digital accessibility in the US already had an overlay installed. The National Federation of the Blind has been saying this publicly for years. The widget is a liability, not a shield.
Updated 24 September 2026. This paragraph first cited 456 lawsuits, 22.6% of the total, from UsableNet’s 2025 midyear report. The page we linked to does not state those figures, so they are replaced with the 2026 number UsableNet publishes itself.
Free statement generators. They emit “this website is fully compliant” without testing anything. An accessibility statement is a public claim, and it carries your organisation's name, not the generator's. An unsupported one is the first document anybody investigating you will read.
What I built instead
Curbcut is a small MIT-licensed CLI that does the translation and nothing else. It runs axe-core in a real headless browser on your machine, then reports what it found the way a conformance claim has to be written.
npx curbcut https://example.com --crawl --pdf
Same findings as above, restated:
P1 Clause 9.4.1.2 — Name, Role, Value 3 elements
P1 Clause 9.1.1.1 — Non-text Content 1 element
P2 Clause 9.3.1.1 — Language of Page 1 element
P3 Clause 9.1.4.3 — Contrast (Minimum) 10 elements
P3 Clause 9.2.4.4 — Link Purpose (In Context) 1 element
Four things are deliberate here.
Bands are exposure, not severity. P1 means a person cannot finish what they came to do and the clause is in the harmonised standard. Ten contrast failures sit below one missing form label, because that is the order somebody will ask about them in.
WCAG 2.2 is reported separately. It is in the output, clearly marked as not a current obligation, so you can plan for the change rather than be alarmed by it or billed for it a year early.
It prints what it did not check. Every run lists the clauses no automated tool can evaluate — 9.2.1.1 keyboard operability across a whole journey, 9.3.2.3 consistent navigation, and so on — as never assessed, rather than omitting them and letting the silence imply a pass.
The statement draft refuses to overclaim. It will not produce a
full-conformance claim out of scan data, because scan data cannot support one.
Everything needing a human decision stays a visible [bracket] until a
human fills it in.
There is a --pdf flag that writes a dated A4 report you can hand to
a client or attach to an email. It is deliberately plain: no cover art, no score
out of ten, no badge. The words “not a certificate” and “not legal
advice” are on the first page, above the findings, because a document that
looks like a certificate would misrepresent what automated testing can establish.
That is the accessiBe mistake, and it is not one worth repeating in a smaller
font.
Try it against a known answer
Rather than ask you to trust a screenshot, there is a deliberately broken page published for this:
npx curbcut https://curbcut.org/demo/broken.html
It should report five failing clauses across sixteen elements — two P1, one P2, two P3. If it reports something else, that is a bug and I would like the issue.
If you would rather not install anything, the same engine runs in your browser. Paste an address, get the same clause mapping back. That version exists because the person who gets asked what the organisation has done about the EAA is usually not the person who can open a terminal.
Proving a fix actually happened
A single scan is a snapshot. It says nothing about direction, which is the thing an auditor, a client or your own manager is actually asking about.
npx curbcut https://example.com --crawl --json
# ... do the work ...
npx curbcut https://example.com --crawl --baseline curbcut-report/analysis.json
Findings are matched by clause, not by axe rule, because a clause can start failing for a different reason than it did last month. A rule-keyed diff would call that one fix plus one new break, which badly describes a page that never stopped failing 9.4.1.2.
And if the later scan reached fewer pages than the baseline, the comparison says so before anything else. Fewer failures can simply mean fewer pages were assessed, and presenting that as progress would be a lie by arithmetic.
What this does not do
It does not make you compliant, and you should be suspicious of anything that says it will. It finds what automation can find, names the clauses, and shows you the gaps it could not test. Closing those gaps is engineering work, and some of it needs a person using assistive technology.
I am also not a lawyer, this is not legal advice, and Curbcut is not affiliated with ETSI, CEN, CENELEC or the European Commission in any way. It is software that references a standard those bodies publish.
Source is on GitHub, MIT, and the clause mapping is the part worth reading critically. If a mapping is wrong, that is the highest-value bug you could file.
One postscript worth your time: the version of the standard quoted throughout this piece is scheduled to be replaced near the end of 2026, when V4.1.1 is cited and WCAG 2.2 becomes the yardstick. What changes, and what to do before then.