DEV Community: JagheterAlex

EN 301 549 is about to move to WCAG 2.2. Six criteria, one date, and one requirement that disappears.

JagheterAlex — Thu, 10 Sep 2026 14:00:58 +0000

If you are working to the European Accessibility Act, the standard you are
working to is EN 301 549 V3.2.1 (2021-03), and it adopts WCAG 2.1. That
is true today. It is scheduled to stop being true near the end of 2026.

Here is what changes, what does not, and the one thing worth doing about it now.

The date, and why it is the only date that matters

A standard becomes a legal obligation in the EU when it is cited in the
Official Journal, not when the body that wrote it publishes it. That
distinction is the whole story here.

The sequence, from ETSI's work programme and what has been published so far:

Milestone	When
V4.1.0 public-enquiry draft	November 2025 - done
V4.1.0 final draft	June 2026 - done
V4.1.1 published by ETSI, CEN and CENELEC	2 September 2026 - done
Cited in the Official Journal, replacing V3.2.1	Provisional: late November to mid-December 2026

So the standard itself now exists in final form. What is left is the step that
carries the legal weight: delivery to the European Commission and citation in the
Official Journal. Published estimates for the citation date currently sit between
30 November and 16 December 2026, and they have already moved by weeks as the
standard worked through review. For one point of comparison, V3.2.1 was published
in March 2021 and cited about five months later; on that precedent alone the date
could slip into 2027. Treat the quarter as the plan and the day as provisional.

Until that citation happens, V3.2.1 is the yardstick and WCAG 2.2 criteria
are good practice rather than obligations. Anyone selling you WCAG 2.2 remediation
as a legal requirement today is ahead of the law. Anyone telling you to ignore 2.2
is setting you up to do the work twice.

What actually changes

Clauses 9, 10 and 11 web, non-web documents and software move from WCAG 2.1
to WCAG 2.2 Level AA. For clause 9, that is six new success criteria at A and
AA.

3.2.6 Consistent Help (Level A)

If you offer a help mechanism contact details, a chat widget, a help link it
has to appear in the same relative order across pages. In practice this is a
layout consistency rule, and most sites with a stable header already pass it. The
ones that fail are the ones where help moves into a hamburger on some templates
and not others.

3.3.7 Redundant Entry (Level A)

Do not ask for the same information twice in one process. If the user typed their
address at step two, step four either pre-fills it or offers it for selection.
Checkout flows and multi-step onboarding are where this bites.

2.4.11 Focus Not Obscured, Minimum (Level AA)

When something receives keyboard focus, it must not be entirely hidden behind
sticky headers, cookie bars or floating chat bubbles. This is the criterion most
likely to fail on a modern site, because sticky elements are everywhere and almost
nobody tabs through their own page to check.

2.5.7 Dragging Movements (Level AA)

Anything you can do by dragging must also be doable with a single pointer action
that is not a drag. Sliders, kanban boards, reorderable lists, map panning. Add a
click alternative or a set of buttons.

2.5.8 Target Size, Minimum (Level AA)

Interactive targets must be at least 24 by 24 CSS pixels, with exceptions for
inline links in text and for targets with enough spacing around them.

This is the one people get wrong when they read old advice. WCAG 2.1 had a target
size criterion2.5.5, but it was Level AAA at 44 pixels, so it was never
in scope for EAA conformance. WCAG 2.2 adds a different, smaller criterion at
AA. If your design system standardised on 44px because a consultant said so, you
were never obliged to and you still are not. Twenty-four is the number that is
about to matter.

3.3.8 Accessible Authentication, Minimum (Level AA)

No cognitive function test in your login unless there is an alternative. That
means: do not require the user to solve a puzzle, transcribe a code from an image,
or remember something, without offering another route. Copy and paste must work in
one-time-code fields. Password managers must not be blocked.

This one has teeth, because a lot of authentication is deliberately hostile to
automation, and hostility to automation is usually hostility to assistive
technology as well.

The requirement that disappears

4.1.1 Parsing is obsolete in WCAG 2.2. Duplicate id attributes and unclosed
tags are no longer a conformance failure on their own browsers recover from them
predictably and the criterion no longer described a real barrier.

But it is still in force right now, because V3.2.1 adopts WCAG 2.1, and 2.1 still
contains it. So a duplicate id is a failure of the currently harmonised standard
today and will quietly stop being one after citation.

This is the only place where the new version makes your life easier, and it is
worth knowing about mostly so that you do not spend an afternoon close to
citation fixing something that no longer counts.

Two changes nobody mentions

Clause 6 gets much bigger. Real-time communication requirements broaden from
two-way voice to real-time bidirectional communication, formally taking in Total
Conversation voice, real-time text and video together with substantially
revised RTT requirements. If your product includes calling, messaging or support
chat, clause 6 deserves a read on its own, separately from anything WCAG says.

Annexes ZA and ZB are new, and they matter more than they sound. Annex ZB maps
the technical clauses onto the actual articles of the European Accessibility Act,
and Annex ZA does the same for the Web Accessibility Directive. V3.2.1 had no such
mapping, which is why demonstrating a presumption of conformity against the EAA has
been awkward: you were citing a technical standard at a legal instrument and hoping
the join was obvious. V4.1.1 makes the join explicit.

For anyone who has had to assemble a conformance argument by hand, that is the
most useful thing in the release.

What to do before citation

Do not remediate WCAG 2.2 as though it were law today. It is not, and you
will have spent budget ahead of the obligation.

Do not ignore it either. Six new criteria with citation expected around the
turn of the year is a plannable piece of work, and the two that usually require
real design changes focus not obscured, and dragging movements are cheaper to
fix while you are already touching a component than as a year-end emergency.

Measure the gap now, separately. You want two numbers: what fails against the
standard that binds you today, and what would additionally fail after citation.
One is a compliance obligation. The other is a roadmap item. Reporting them as a
single red total is how tools inflate a problem into a panic.

That separation is why I built Curbcut the way I did. It
reports findings as EN 301 549 clauses, and it keeps WCAG 2.2 criteria in their own
band visible, counted, and explicitly marked as not currently obligatory.

npx curbcut https://example.com --crawl

It is MIT licensed, runs on your machine, and uploads nothing. When the citation
lands, the mapping updates and the same criteria move bands, which is exactly the
event I would rather have handled in software than in a spreadsheet.

The honest caveat

Automated testing finds roughly a third of accessibility barriers, and several of
these new criteria are barely testable by machine at all. Consistent Help and
Redundant Entry are judgements about a flow. Accessible Authentication needs
somebody to actually try logging in with a password manager and a screen reader.

Curbcut prints the clauses it could not evaluate rather than omitting them,
because a silent pass is the most expensive kind of wrong answer in this field. A
scanner is where this work starts. It is not where it finishes.

This article reflects EN 301 549 V4.1.1 as published on 2 September 2026 and
ETSI's schedule for Official Journal citation as of September 2026; the citation
date in particular may still move. Nothing here is legal advice.

The accessibility statement template you copied is for a different law

JagheterAlex — Thu, 03 Sep 2026 13:28:34 +0000

Search for "EAA accessibility statement template" and you will find the same
twelve-section document over and over. Conformance status, non-accessible
content, preparation date, feedback mechanism, enforcement procedure. It looks
official because it is official.

It is also written for a different directive, aimed at organisations you are
probably not one of.

That template comes from Implementing Decision (EU) 2018/1523, which sets out
the model accessibility statement for the Web Accessibility Directive
(2016/2102). The Web Accessibility Directive applies to public sector bodies
ministries, municipalities, state hospitals, public universities.

The European Accessibility Act is a different instrument with a different scope,
and it does not prescribe a template at all.

Copying the public-sector model is not a disaster. Much of it is sensible, and
national transpositions differ yours may well ask for something close to it.
Check what your own member state actually enacted, because that is the text that
binds you, not the directive in the abstract. But if you copy the model believing
it is the EAA requirement, you will
confidently produce a document that satisfies a rule you are not subject to while
missing two obligations you are.

One caveat with a date on it, because I would rather flag this than have the
article age into a lie. The revision of EN 301 549 is being carried out under
Commission Standardisation Request M/587, which covers both the EAA and the
Web Accessibility Directive. Work under that mandate has included establishing a
model accessibility statement. So "the EAA prescribes no template" is true as I
write this and may not stay true. If a model arrives through the harmonised
standard, use it a template that carries a presumption of conformity is worth
more than any structure I can suggest.

Before any of this: does it apply to you?

Microenterprises providing services fewer than ten people, and annual turnover
or balance-sheet total not over €2 million are exempt from the EAA's service
obligations. That exemption does not extend to product manufacturers, and it does
not exempt you from other law.

If you are under those thresholds, the rest of this article is optional reading
rather than a compliance task. Publishing an honest statement is still a good
idea. It is just not the same as being obliged to.

What the EAA actually asks for

Article 13(2) puts the duty on service providers plainly: prepare the information
required by Annex V, and explain how the service meets the applicable
accessibility requirements.

Annex V then lists what that information contains:

A general description of the service in accessible formats.
Descriptions and explanations necessary for understanding how the service operates.
A description of how the relevant accessibility requirements in Annex I are met.

Three items. No conformance percentage, no prescribed headings, no template.

That is more demanding than it first appears, because point 3 is not "we ran a
scanner". Annex I is the accessibility requirements themselves. You are being
asked to walk through what applies to you and describe how you meet it.

The two obligations the public-sector template will not remind you about

It goes in your terms and conditions

The directive says the information assessing how your service meets the
accessibility requirements belongs in the general terms and conditions, or an
equivalent document.

The pattern you see almost everywhere is a page at /accessibility linked from
the footer, and nothing else. That page is useful and you should keep
it but on its own it is not where the directive says the information lives.

If your terms and conditions are a separate document a customer accepts at
checkout, that document, or something equivalent to it, is where this has to
appear.

It has to exist in oral format too

Article 13(2) requires the information be available in written and oral
format, and in a manner accessible to persons with disabilities.

Oral. This is the requirement I have seen discussed least and skipped most.

It does not mean recording a podcast. In practice it means somebody who telephones
your support line and asks how accessible your service is must be able to get the
answer that way which implies your support staff know it exists and can read it
out or explain it. A statement your own support team has never seen fails this
quietly and completely.

What makes a statement survive being read by a hostile expert

The three ways statements fail have nothing to do with formatting.

Claiming conformance you cannot support

"This website is fully compliant with WCAG 2.1 AA" is the single most common
sentence in generated statements, and it is almost never true.

Automated testing detects roughly a third of accessibility barriers. If nobody has
tested with a screen reader, nobody has tabbed the full checkout, and nobody with
a disability has used the thing, then the honest status is partially conformant,
and saying so costs you far less than the alternative.

The alternative is documented. In January 2025 the US Federal Trade Commission
brought a case against accessiBe over claims that its widget could make any site
WCAG compliant, and
approved a final order in April
requiring the company to pay $1,000,000. The complaint also covered reviews
presented as independent that were not. Different jurisdiction, same principle: an
accessibility claim is a claim, and unsupported claims are actionable.

Your statement carries your organisation's name, not your vendor's.

Being silent about what was never checked

A statement that lists three known issues implies the rest was examined and passed.

If your evidence is one automated run, several clauses were never evaluated at all consistent navigation, keyboard operability across a whole journey, whether alt
text actually communicates anything. Silence about them reads as a pass, and that
inference is the thing you did not intend to make and will be held to anyway.

Name them. "These were not assessed" is a defensible sentence. "We are fully
compliant" when they were not assessed is not.

Offering a feedback route that does not work

Every model statement includes a contact for reporting barriers. Most of those
addresses go to a mailbox nobody reads.

The feedback mechanism is not decoration. It is the thing a regulator will test
first, because it takes them thirty seconds and it tells them whether the rest of
the document is real. Send a message to your own accessibility contact and see
what happens.

A structure that works

Not a template to paste the EAA prescribes none, and your service is not mine.
But this order holds up:

What this service is, in plain language. Annex V point 1, and the place to be
concrete rather than corporate.

Current status, stated exactly as strongly as your evidence supports. If the
evidence is automated testing only, say that in the same sentence as the status.

How the requirements are met, walking the applicable parts of Annex I. This is
the substance, and it is the part a template cannot write for you.

What is not accessible yet, with what you intend to do and roughly when. A
known issue with a date attached reads as competence. The same issue undisclosed
reads as concealment.

What was not tested, named clause by clause rather than left to inference.

How to tell us, with a route somebody actually monitors and a response time you
will actually hit.

When this was prepared and how, including what tooling and what manual
testing. A statement with no date and no method is an assertion.

Where a tool helps, and where it does not

Curbcut drafts the evidence-based parts. It maps findings
onto EN 301 549 clauses, ranks them by regulatory exposure rather than by how
loudly a rule engine complains, and generates a statement draft.

The generator deliberately will not produce a full-conformance claim from scan
data, because scan data cannot support one. Everything requiring a human decision
stays a visible [bracket] until a human fills it in. Brackets in a draft are
annoying. Brackets are also the only honest output when the input is one automated
run.

npx curbcut https://example.com --crawl --statement

Or check a page in your browser with nothing installed,
which is the faster way to see what your evidence actually looks like before you
write anything.

The honest part

I am not a lawyer and this is not legal advice. Whether the EAA applies to you,
what your national transposition adds, and whether a particular statement
discharges your obligation are legal questions about your business.

What I can tell you is that automated testing reaches about a third of the
problem, that a statement is a public claim about the other two thirds, and that
the gap between those two facts is where organisations get into trouble.

Write the statement you can defend, not the one you would prefer to be true.

Everyone is getting ready for WCAG 2.2. Two thirds of Europe's biggest sites still fail 2.1 Level A.

JagheterAlex — Thu, 27 Aug 2026 09:47:26 +0000

The next version of the European accessibility standard is scheduled for citation on 30 November 2026. EN 301 549 V4.1.1 swaps WCAG 2.1 for WCAG 2.2, and six new success criteria arrive at levels A and AA. There is a small industry of readiness checklists for it already.

So I measured what the current version looks like first. The answer is that the deadline people are preparing for is not the one they have missed.

I scanned the most-visited websites on EU country domains and counted which clauses of EN 301 549 they fail today, under the version cited right now. Not the one arriving. The one in force since before the European Accessibility Act deadline passed in June 2025.

Sixty-four per cent fail clause 9.4.1.2, Name, Role, Value. It is Level A, the lowest bar the standard has, and it has been in every version of WCAG since 2008.

Here is the full picture, and then the reasons to distrust parts of it.

What was measured

Clause	Criterion	Level	Sites failing
9.4.1.2	Name, Role, Value	A	96 of 149 (64%)
9.1.4.3	Contrast (Minimum)	AA	66 of 149 (44%)
9.2.4.4	Link Purpose (In Context)	A	53 of 149 (36%)
9.2.5.8	Target Size (Minimum)	AA	51 of 149 (34%)
9.1.1.1	Non-text Content	A	35 of 149 (23%)
9.1.3.1	Info and Relationships	A	27 of 149 (18%)

Target size is the odd one out: it is a WCAG 2.2 criterion and not currently required. It is in the table because it is the only one of the six arriving in V4.1.1 that the rule engine used here has a check for, which is a point I will come back to.

Thirty-two sites of the 149, about one in five, failed nothing that automated testing can detect. That is not the same as passing.

Two of those rows are not independent. The rule that most often breaks Name, Role, Value is a link with no accessible name, and the same defect also fails Link Purpose. One missing label lands in two rows of that table. I am pointing this out because a table of six numbers implies six problems, and some of them are the same problem counted twice under different clauses — which is, incidentally, why conformance is claimed against clauses rather than rule counts.

What the failures actually are

Clause names are abstract. On a second pass I recorded which underlying rule produced each failure, so the table above turns into something you can picture. That pass covered the top 120 domains and measured 59 of them.

It is a worse-performing group than the full sample, and predictably so: it is the more-visited end of the list, which the section above already found does worse. Name, Role, Value fails on 73% of it against 64% overall. Read the shares below as proportions within that group, not as headline rates.

What breaks Name, Role, Value, on the 43 sites of 59 that failed it:

What is wrong	Share of the sites failing this clause
A link a screen reader announces as nothing	49%
An `<iframe>` with no title	30%
A button with no accessible name	28%
ARIA attributes that are invalid or not allowed	16%

The first one is usually an icon: a magnifier, a basket, a social media glyph, marked up as a link with an image inside and no text anywhere. The second is usually an advert. Neither is an architectural problem. Both are a missing attribute.

The rest are simpler still. In that same group, every single contrast failure came from one rule, every target-size failure from one rule, and every non-text-content failure was an image with no alternative text. Not a long tail of exotic problems. One thing, repeated.

None of this is hard. That is the uncomfortable part: it is not hard, and two thirds of the most-visited sites in Europe have it anyway.

The finding I did not expect

I assumed the biggest sites would do best. They have the most money and the most staff.

Splitting the measured sites at the median rank:

	Failing nothing detectable	Median clauses failing
More-visited half	11%	2
Less-visited half	32%	1

The more popular half is roughly three times less likely to come back clean. I cannot prove the mechanism from this data, but the plausible one is unglamorous: big sites carry more third-party widgets, more legacy, more teams shipping into the same page, and more of everything that goes wrong. Budget does not appear to be the constraint.

The one WCAG 2.2 criterion a scanner can reach

Thirty-four per cent fail target size, and that number needs a caveat before anyone repeats it.

A third of the sites showed a cookie consent dialog to an anonymous visitor, and on one in five the dialog covered more than 40% of the screen. I did not dismiss them. Clicking "accept all" on somebody else's site, unattended and at scale, is not something a research script should be doing, and it would also have changed what I was measuring.

So the target-size number partly describes consent dialogs. Splitting it:

Sites showing a consent dialog: 40% fail target size
Sites without one: 31%

The gap is real and the finding survives it. Consent dialogs are worse than the pages behind them, and the pages behind them are not fine.

The other five criteria arriving in November — focus not obscured, dragging movements, consistent help, redundant entry, accessible authentication — were not measured here at all. Each is a judgement about behaviour that the page source does not contain: whether a sticky header covers the control that just took focus, whether every drag has a single-pointer alternative, whether a login demands something a person cannot be expected to do. axe-core has no rule for any of them, and I am not aware of a scanner that does.

That is the single most useful thing to know about this transition. Five of the six need a person. Any tool advertising a WCAG 2.2 readiness check is checking one criterion in six and staying quiet about the other five.

Two loads, two answers

Every page was loaded twice, seconds apart, and only criteria that failed both times were counted.

That rule exists because the pilot caught a large retailer passing target size on one load and failing it on the next, with nothing changed in between. In the full run, nine sites of 149 disagreed with themselves that way. Six per cent.

Six per cent turned out to be the flattering number.

I ran a second, smaller pass over the top of the same list a few hours later. On the first 120 domains, the disagreement rate was 10% in the first run and 19% in the second. And 57 sites were measured in both passes, hours apart: eight of them, one in seven, produced a different set of failing clauses the second time.

Nobody deployed anything in the seconds between two loads. Rotating promotional content, A/B tests and consent variants move the geometry of a page across a threshold on their own. Over hours, an editorial site simply becomes a different page.

I would rather quote the six per cent. It is the number I found first and it makes the sample look tidiest. The other three come from the same data and they all say the effect is larger.

If you commissioned a dated accessibility audit, you bought a description of one moment. You can test that for nothing, and without believing me, because I sell a scanner and have an obvious stake in the answer: run any free checker over your own homepage twice in a row, then again this afternoon.

Half the sample never got measured

Of 300 domains sampled, 151 were excluded. This is where a study either tells you what it threw away or quietly rounds its own numbers up.

Reason	Count
Redirects to a different domain	43
A stylesheet failed to load	34
Blocked the request (HTTP 403)	32
Domain does not resolve	20
robots.txt disallows it	6
Connection, certificate or timeout errors	8
Blocked our test script via Content Security Policy	4
Other HTTP errors	4

Three of these are worth a comment.

The stylesheet exclusions are self-protection. A page that renders unstyled fails layout rules that the real page passes, and target size is exactly such a rule. I know this because it happened to me in August: a scan caught our own site mid-deploy and reported sixteen violations that vanished on the next run. Reporting invented failures is the same category of error as inventing a passing grade, so any page whose CSS did not arrive is thrown out rather than counted.

Eleven per cent of the sample blocked us outright. Bot protection does not distinguish between a scraper and an accessibility audit. If you are wondering why third-party research on this subject is thin, that is part of the answer.

Four sites were excluded because our scanner obeyed their Content Security Policy — and that turned out to be our bug, not their barrier. This paragraph originally said that a strict CSP prevents anybody from auditing your accessibility from outside. That was wrong, and it is corrected here on 22 August. A strict policy refuses to execute a <script> element appended to the document, which is exactly how this tool was loading its rule engine. Auditors built as browser extensions never had the problem, because they run outside the document. Neither do we any more: the loader was changed the same day to go through the debugging protocol instead, which is one line. Read those four as a limitation of the tool on the day, not as a property of the sites, and expect the category to be absent from the next dated run.

The exclusions are not random. A site with sophisticated bot protection is probably a different kind of organisation from one without. The 149 sites I could measure are the ones that let me in, and if anything I would expect that group to skew toward the simpler end.

What this is not

It is not a compliance rate. The EAA covers e-commerce, banking and payments, electronic communications, transport ticketing and information, audiovisual media services and e-books. It does not cover every website. A news portal is outside scope unless it sells subscriptions — and nearly every large European newspaper does, which pulls most of them back in, but "most" is not "all" and I did not check them one by one. Microenterprises under ten staff are exempt from the service requirements entirely.

So read the numbers as a picture of the European web, not as an audit of the regulated subset of it.

Failing a criterion is not the same as breaking the law. The harmonised standard gives a presumption of conformance. Missing it means you no longer have that presumption, not that a penalty follows.

Automated testing finds roughly 30 to 40% of WCAG failures. Every number here is a floor. The 21% that came back clean did not pass an accessibility audit; they passed the third of one that a machine can perform.

One page per site. The homepage. A conformance claim covers a service, and I measured a front door.

Clause 9 only. EN 301 549 has more than web pages in it. Clause 10 applies the same success criteria, through WCAG2ICT, to documents a service delivers rather than renders: the invoice, the ticket, the statement of account, the e-book. For most of the categories the EAA names, that is a large share of what a customer actually reads, and nothing here looked at any of it. So the 30 to 40% above is a share of failures in web content, not a share of the obligation — read it as generous rather than conservative.

Method

Sample: the Tranco research list, id 74V8X generated 21 August 2026, filtered to domains whose TLD belongs to an EU member state, taken in rank order. Tranco averages five ranking providers over thirty days specifically to resist the manipulation that single-source top-site lists suffer from, and it pins every list to an id so the sample can be reconstructed exactly.

Top 300 such domains. One page each, the apex URL, loaded twice with roughly a second between, and a criterion counted only when it failed both times. Detection by axe-core 4.13.0, with results mapped onto EN 301 549 clauses. robots.txt was respected, the user agent identified the crawler and pointed at a page explaining it, and no site was crawled beyond its front page.

A second pass a few hours later repeated the method over the top 120 domains and additionally recorded which rule produced each failure. It measured 59 sites. Every figure above says which pass it comes from; the headline table is the 300-domain run.

No company is named. Naming them would travel further and it would turn a measurement into an accusation from someone who sells the remedy. WebAIM has published the same shape of study annually for years without naming anybody, and that seems like the right precedent.

The data is published: every site as a row, with its rank bucket, its country, the clauses it failed, whether it disagreed with itself between loads, and for the 151 excluded ones, why. The rows carry no domains. That is not a hedge — the sample is reconstructible from the Tranco id and the selection rule above, so anyone can rebuild the exact list and re-run it, which is the part that matters for checking my work. The tool is MIT licensed and the script that produced this is in the repository at scripts/benchmark.mjs.

If this crawler turned up in your logs, the same page says what it requested and how to refuse it in one line of robots.txt.

The part that matters

November is a real deadline and the six criteria are real work, five sixths of which no tool will do for you.

But if you are choosing what to fund this quarter, the standard you are already measured against has been sitting there since June 2025, and two thirds of the most-visited sites in Europe do not meet its lowest bar. The unlabelled button is not waiting for a new version of anything.

Updated 31 August 2026. A reader pointed out that the piece said "EN 301 549"
while measuring clause 9, and that clause 10 the documents a service hands
you is both a large part of the obligation and a place no scanner is pointed.
He was right, and the omission flattered the numbers. The paragraph about it in
"What this is not" was added that day, along with the same admission in the
tool's own output, which named clause 12 and skipped clause 10 in exactly the
same way. Nothing else was changed: the figures are as first published.

Your accessibility scanner found 47 issues. A regulator will ask about clause 9.1.4.3.

JagheterAlex — Fri, 21 Aug 2026 08:49:16 +0000

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.