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 2025 midyear report
counted 456 US accessibility lawsuits, 22.6% of the total, filed against sites
that 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.
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 decide rather than be alarmed.
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.
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.
