DEV Community: JagheterAlex

The people an accessibility overlay is for rate it worse than everybody else

JagheterAlex — Thu, 24 Sep 2026 14:22:41 +0000

The pitch is close to irresistible. One line of JavaScript, no engineering work,
no audit, and a legal problem becomes a subscription line item. If it worked, it
would be the best value in software.

There is a lot of argument about whether it works. There is less argument among
the people it is supposedly for, and that is the part worth starting with.

One number

The WebAIM survey of web accessibility practitioners asked how effective overlays
are. Of 758 valid responses, 67% rated them "not at all" or "not very"
effective.

Among respondents who themselves have disabilities, that rose to 72%.
Only 2.4% of them called overlays very effective.

That survey is from January 2021, so treat the exact figures as of their date. I
am not aware of a later practitioner survey that reverses the finding, and if one
exists I would genuinely like to see it.

The shape of the result is the part that matters: the group with the most direct
experience of using these tools rates them worse than the general population
of practitioners does.

For any other product that finding would end the discussion. A wheelchair ramp
that wheelchair users rate worse than non-users do is not a ramp.

What the FTC order actually says

In January 2025 the US Federal Trade Commission brought a case against accessiBe
and approved the final order in April.
One million dollars.

The interesting part is not the money. It is the prohibition. The order bars
accessiBe from representing that its automated products can make any website
WCAG-compliant, or can ensure continued compliance over time, unless it has
evidence to support the claim.

Read that as a statement about the category rather than about one company. A
regulator looked at "automated tool makes your site compliant" and concluded it
could not be said without evidence, evidence that, in that case, did not exist.

The same complaint also covered third-party articles and reviews formatted to look
like independent opinions, where the company's connection to the reviewer was not
disclosed. If you evaluated overlays by reading reviews a few years ago, some of
what you read was not what it appeared to be.

Why it cannot work, mechanically

An overlay is JavaScript that runs in the visitor's browser and modifies the page
after it arrives. That single fact produces most of the limitations.

It has to guess. No script can know that an image of a chart is decorative in
one place and load-bearing in another, or that your heading structure is wrong
rather than unusual, or which of four inputs is the one labelled "Name" in the
visual layout. Automated remediation guesses, and a confident wrong label is worse
than a missing one: a missing label is a barrier somebody can work around, and a
wrong label sends them somewhere else entirely.

It fixes nothing at the source. The changes exist in the rendered page while
the script is running. They are not in your markup, not in your templates, and not
in the next page your team ships. Turn the subscription off and every fix leaves
with it.

It depends on somebody else's infrastructure. The script is served from a
vendor CDN. If that CDN is slow, blocked by a corporate proxy, or down, the
remediation is simply absent and absent precisely for the users least able to
compensate.

Some things are structural. Focus order, keyboard traps, whether a multi-step
checkout can be completed without a mouse, whether error messages are announced at
all. Those are properties of how the application is built. A layer painted over
the top does not change them.

The litigation data

According to UsableNet's 2026 midyear report,
about 20% of the companies sued over digital accessibility in the US already
had an accessibility widget or overlay installed.

That number does not prove overlays cause lawsuits. Sites that install one are
plausibly sites already worried about being sued, which is a selection effect and
should be said out loud rather than glossed over.

What it does refute is the marketing claim. Roughly one defendant in five had
already bought protection. Whatever the widget is, it is not a
shield and its presence is trivially detectable by anybody looking for
defendants.

Where the overlay vendors are not wrong

A fair argument has to include this part.

User preference controls are genuinely useful. Being able to raise text size,
increase contrast or reduce motion helps real people, and some users like having
those controls in one place rather than hunting through browser settings. That is
a legitimate feature and it is a pity it arrives bundled with a legal claim.

Some organisations have nothing at all. For a site with no accessibility work
whatsoever, a widget that adds a few keyboard shortcuts is not worse than nothing
in every respect.

The underlying problem is real and hard. Vendors did not invent the demand.
Companies genuinely are being asked to fix years of accumulated markup with no
budget and no expertise, and "one line of JavaScript" answers a real question,
just not truthfully.

The objection is not that the software exists. It is the compliance claim attached
to it, and that claim is now the subject of a regulator's order.

What to do instead, in order

Find out where you actually stand. Not a score out of a hundred: a list of
which clauses of the harmonised standard are failing, and how badly.

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

Or check a page in your browser with nothing
installed.

Fix the task-blockers first. An unlabelled password field in your checkout
outranks four hundred low-contrast footer links, however your tool sorts them by
default.

Get a person to test what automation cannot reach. Automated testing gets you
roughly a third of the way. The rest: keyboard journeys, focus order, whether alt
text says anything useful needs a human, and some of it needs a human who uses
assistive technology every day.

Write a statement you can defend. The template most people copy is for a
different law,
and an unsupported conformance claim is the first document anybody investigating
you will read.

The part where I declare my interest

I build an accessibility tool, so read all of the above knowing that.

Here is what mine does not do: it does not fix anything. It finds what automation
can find, maps it onto EN 301 549 clauses, ranks it by regulatory exposure, and
prints the clauses it could not evaluate rather than staying quiet about them. The
fixing is engineering work somebody has to do, and no product I could build would
change that.

More than a thousand accessibility practitioners including contributors to the WCAG,
ARIA and HTML specifications, and accessibility staff at Google, Microsoft, Apple,
Shopify, eBay and Target have signed the
Overlay Fact Sheet, which sets out the
technical case in more detail than I have here. Read it before you buy anything,
including mine.

Does the European Accessibility Act apply to you? Four questions, in order

JagheterAlex — Fri, 18 Sep 2026 16:12:32 +0000

Most articles answer this with one number: ten employees, two million euro. That
number is real and it is the last question, not the first. Asking it first is how
companies conclude they are covered when they are not, and how others conclude
they are safe when they are not.

Four questions, in the order that actually decides it.

1. Is what you provide on the list?

The EAA does not cover the whole economy. It covers a specific list of products
and services.

The services in scope are consumer banking, electronic communications,
e-commerce, e-books and their dedicated software, services providing access to
audiovisual media services, and transport passenger services including e-ticketing
and travel information.

The Act also reaches the answering of 112 emergency calls. That one sits on the
emergency call centres rather than on anyone selling to the public, so it is not a
question you have to answer here.

One entry does far more work than the others, and it is why this question settles
less than it looks. E-commerce is not a sector. Recital 43 of the directive
says the e-commerce obligations apply to the online sale of any product or
service.

So the question is not whether dentistry or construction appears on the list.
Neither does. It is whether you sell online at all and then, in question 2, to
whom. A construction firm with a brochure site and a manufacturer selling through
distributors are outside the scope because nobody buys from them on the web not
because their trade is missing from the list. A practice that takes bookings and
payment through its own site is doing e-commerce whatever is written on the door.

Having a website does not make you an EAA service provider. Selling through one
can.

Note the word service. Products have their own list: computers and operating
systems, payment terminals, ATMs, ticketing machines, smartphones, e-readers,
routers. If you make one of those, you are on a different path through this
article and the microenterprise exemption below does not help you.

2. Is your customer a consumer?

This is the question that decides most cases, and the one most guides skip.

E-commerce services are defined in Article 3(30) as services provided at a
distance, through websites and mobile device-based services, by electronic means
and at the individual request of a consumer, with a view to concluding
a consumer contract.

Those criteria are cumulative. Every one has to be true.

And consumer has a fixed meaning: a natural person acting for purposes outside
their trade, business, craft or profession.

So a genuinely B2B-only platform is generally outside the scope. If everything
you sell goes to companies, under business contracts, to people acting in their
professional capacity, the e-commerce limb does not catch you.

The trap in mixed models

"We are B2B" is a description of your sales team, not of your website.

The definition turns on who the counterparty is and what contract is being
concluded not on how you describe your market. A platform that sells to
businesses but has an open sign-up flow that never verifies business status, or a
booking system a private individual can complete, is where "we are B2B" stops
being obviously true.

I am not going to tell you those cases are definitely caught, because that is a
question for a lawyer looking at your actual contracts and your actual sign-up
flow. What I will say is that this is the point where the answer stops being
automatic, and if your response to "can a private individual buy from us?" is
"probably not, I think", that is the thing worth resolving before you decide you
are out of scope.

3. Are you a microenterprise?

Now the famous number.

A microenterprise employs fewer than 10 people and has an annual turnover
or an annual balance sheet total not exceeding €2 million.

Read that or carefully, because it is the word people talk themselves out of the
exemption with. The headcount and the money are separate tests and you have to
pass both, but the money test is satisfied by either figure. Turnover of €3
million does not disqualify you if your balance sheet total is under two.

Microenterprises providing services are exempt from the accessibility
requirements. That is the exemption in Article 4(5), and it is real.

Two things it does not do:

It does not exempt product manufacturers. A five-person company making
e-readers is not off the hook, though the paperwork burden on it is lighter.

It does not exempt you from everything else. Other law still applies
national disability legislation, and ordinary consumer protection rules about
misleading claims. And if you build or run something for a public body, the Web
Accessibility Directive binds that body rather than you, which is not the relief it
sounds like: it arrives in your procurement contract instead. "We are a
microenterprise" is an answer to one question.

If you clear the headcount test and either money test, and you provide services,
you are outside the EAA's service obligations. Building an accessible service is
still worth doing. It is just not, in your case, a legal requirement under this
directive.

The numbers above are the directive's. Your country's may not match.

On 6 May 2026 the tribunal judiciaire de Lille held that Auchan E-Commerce was
under no accessibility obligation at all not because it is a microenterprise,
which it plainly is not, but because the judge read the obligation through Article
47 of the French law of 11 February 2005, which carries a €250 million turnover
threshold, rather than through the directive's figures. The court accepted that
the site was not accessible and dismissed the claim anyway.

apiDV and Droit Pluriel, who brought it, have appealed to the cour d'appel de
Douai and call the reading a serious error of European law.

File that under unsettled, not under good news. It is a first-instance decision,
it is on appeal, and it binds one member state. What it demonstrates is the line
at the bottom of this article, which is easy to read as a formality: the directive
is not what binds you. Your country's transposition of it is, and the two can
diverge by two orders of magnitude.

4. When?

The deadline was 28 June 2025, and enforcement started immediately. Nine days
later the disability organisations apiDV and Droit Pluriel sent formal notices to
Auchan, Carrefour, E.Leclerc and Picard over inaccessible online shopping. Sweden's
telecoms regulator opened the first market surveillance that October. The French
cases reached court in November.

The first decision came on 4 June 2026, when the tribunal judiciaire de Caen
gave Carrefour six months to make its website and mobile app accessible, with a
penalty accruing for every day it overshoots.

But the directive contains transitional provisions that change the answer for a
lot of businesses, and they are barely discussed.

Service contracts concluded before 28 June 2025 may continue without
alteration until they expire, and no longer than five years from that date, so at
the latest 28 June 2030.

Products lawfully used to provide services before that date may keep being
used until 28 June 2030.

Self-service terminals lawfully in use before 28 June 2025 may continue to the
end of their economically useful life, up to twenty years from entry into use.
This one the directive leaves to each member state to grant or not, so check that
yours took it. Where it did, the ticket machine on the platform is not illegal
tomorrow.

Read those carefully rather than hopefully. They cover existing contracts and
existing hardware. They do not cover the new website you launched last month, and
they do not cover a new consumer signing up today.

The disproportionate burden defence, and why it is not a shortcut

Article 14 lets a provider argue that compliance would impose a disproportionate
burden. This gets quoted as an escape hatch. Read what it actually costs you:

The assessment must be carried out against the criteria in Annex VI, not asserted.
It must be documented, and the records kept for five years after the service was last provided.
It must be reassessed at least every five years, and sooner than that if you alter the service or an authority asks you to.
A copy goes to the authority on request.
And the part that surprises people when you rely on it, you must send information to that effect to the relevant authority. It is not a defence you keep in a drawer until challenged. Relying on it means telling somebody you are relying on it.

"It was too expensive" asserted after the fact, with no documentation, is not the
defence. The documented, notified, periodically renewed assessment is the defence.

Doing that properly is frequently more work than fixing the site.

If the answer is yes

Start by finding out where you actually stand, which is cheaper than most people
expect.

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

Or check a page in your browser with nothing
installed. Findings come back as EN 301 549 clauses rather than rule names,
ranked by what a regulator asks about first rather than by how loudly a rule
engine complains.

Then read
what an accessibility statement actually has to contain,
because the template most people copy was written for a different directive.

If the answer is no

Then you have just saved a budget cycle, and I would rather you learned that here
than after buying something.

Plenty of the accessibility industry is selling urgency to companies that are out
of scope. If you sell only to businesses, or you are a microenterprise providing
services, or you sell nothing to consumers online and are on none of the other
lists, you can put this down.

The parts worth doing anyway labelled form fields, sane contrast, a site that
works by keyboard are cheap, and they make you money by not turning customers
away. That is a better reason than fear.

I am not a lawyer and this is not legal advice. The EAA is a directive, which means what binds you is your own member state's transposition of it, and those differ. Read yours, or ask somebody qualified to.

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.