A French Court Just Ruled That 71% Accessible Is Not Accessible. Your AI Wrote the Other 29%.

Seventy-One Percent Was Not a Passing Grade

On 4 June 2026, the Tribunal judiciaire de Caen ordered Carrefour France to make both carrefour.fr and the Carrefour mobile application fully accessible to people with disabilities within six months, with a fine accruing for each day of delay past that deadline. Carrefour's defence was that it already met 71% of the applicable RGAA criteria. The court's answer is the sentence every engineering leader in Europe should read twice: the e-commerce site in question cannot just be somewhat accessible; it must be totally accessible.

That ruling did not come out of nowhere. The European Accessibility Act became enforceable across all 27 member states on 28 June 2025. Nine days later, France's DGCCRF sent formal notices to Auchan, Carrefour, E.Leclerc and Picard Surgelés, with a compliance deadline of 1 September 2025. When progress proved insufficient, disability rights organisations — ApiDV, Droit Pluriel and the Intérêt à Agir collective — filed emergency injunctions in November 2025. The Auchan case was dismissed at Lille in May 2026. Carrefour's was not.

The specific barriers the court found are almost aggressively ordinary: missing alt text on product images, decorative images being announced by screen readers, videos without captions or transcripts, text that breaks at 200% zoom, and navigation failures that prevented users from completing checkout. None of that is exotic. All of it is the kind of defect that a component library either prevents by construction or reproduces on every page that uses it.

The penalty architecture behind the injunction varies sharply by jurisdiction, which is its own planning problem. France caps at €25,000 per year per service. Germany runs to €100,000 per violation. Spain reaches €1,000,000, Hungary higher still, and Italy is expressed as up to 5% of annual turnover. Ireland attaches up to 18 months of imprisonment alongside a €60,000 fine. A company selling into eight member states is exposed to eight separate enforcement regimes over the same codebase, and the injunction route — as Carrefour discovered — bypasses the fine schedule entirely by ordering remediation on a clock.

The Web Got Less Accessible in the First Year Everyone Started Generating It

For six consecutive years, the annual WebAIM Million report showed slow, unglamorous improvement. In 2026 that reversed. The 2026 WebAIM Million detected 56,114,377 distinct accessibility errors across the top one million home pages — an average of 56.1 per page, up 10.1% from 51 in 2025. The share of home pages with detectable WCAG 2 failures rose from 94.8% to 95.9%.

The failure distribution is the same six problems it has always been, accounting for 96% of everything detected: low contrast text on 83.9% of pages (up from 79.1%), missing alt text on 53.1%, missing form input labels on 51%, empty links on 46.3%, empty buttons on 30.6%, and missing document language on 13.5%. There is nothing novel here. These are the errors that automated tooling has been able to catch reliably for a decade.

Two secondary findings are more diagnostic than the headline. Average home page element count rose 22.5% in a single year, to 1,437 elements. And ARIA usage grew 27% year over year to 133.6 attributes per page, with 82.7% of pages now using ARIA — while pages using ARIA averaged 59.1 errors against 42 on pages without it. More ARIA correlated with worse outcomes, which is exactly what you would expect if ARIA is being applied as decoration rather than as a deliberate accessibility contract.

WebAIM's own commentary points at increased reliance on third-party frameworks and libraries and on automated or AI-assisted coding practices. That is a careful, correlational statement and it deserves to be read as one. But the shape of the regression — more elements, far more ARIA, more of the six easiest-to-detect errors — is precisely the shape you get when a large volume of UI is being produced quickly by something that has learned its defaults from the existing web.

Why the Model Writes Inaccessible Markup by Default

The mechanism is not mysterious, and it is not a flaw anyone needs to be embarrassed about. A language model trained on public web code learns the statistical centre of that corpus. When 95.9% of the corpus fails WCAG, the centre is a failing page. Research presented at the Web for All conference on how LLM-generated code perpetuates user interface accessibility barriers states it directly: because the models are trained on code that already contains accessibility issues, using them to generate web code replicates those patterns as defaults rather than producing accessible alternatives.

The failure profile is specific and worth internalising, because it tells you where to look. Evaluations across Claude, GPT-4 and Gemini using axe DevTools plus expert human review found the models comfortable with structure and consistently weak on interaction: missing focus management, unlabelled form controls, absent skip-navigation links, missing landmark roles, and incomplete heading hierarchies. A benchmark of AI-generated HTML against accessibility standards that tested components including skip links, select-only combo boxes, accordions, login forms and data tables found critical violations at Level A — including complete absence of skip navigation, which fails WCAG 2.4.1 Bypass Blocks outright.

There is a complementary asymmetry in the other direction. Work investigating whether ChatGPT generates accessible source code found it could repair a substantial number of issues across diverse WCAG principles, but with success rates that varied by guideline and were weakest under the Operable principle — the one that covers keyboard access, focus order, and everything a mouse user never notices. Models are decent at the perceivable, textual, structural things. They are unreliable at the things you can only verify by putting the keyboard down and tabbing through.

The most actionable finding across this literature is also the least surprising: there is a measurable gap between accessibility-oriented and accessibility-agnostic prompts. Explicitly asking for WCAG-conformant output meaningfully improves what comes back. That is genuinely useful — but it is a mitigation, not a control. It relies on every engineer remembering to ask, every time, and it produces no evidence that anything was actually verified. Prompting is a nudge on the input side of a system whose output nobody is measuring.

The Overlay Trap

Faced with a compliance deadline and a large surface area, the tempting purchase is a JavaScript widget that promises to fix accessibility at runtime. This is the single most expensive mistake available in this space, and the evidence against it is now unusually direct.

In January 2025 the FTC required accessiBe to pay $1 million to settle allegations that it misrepresented what its accessWidget product could do, finding claims that the AI-powered plug-in could make any website WCAG-compliant to be false, misleading, or unsubstantiated. The order bars the company from claiming its automated products can make any site WCAG-compliant, or keep it compliant over time, without evidence. The Commission approved the order as final in April 2025.

The litigation data says the same thing from the other end. More than 1,000 businesses — over 25% of all digital accessibility lawsuits — have been sued while running an overlay. In the first half of 2025, 456 ADA filings, 22.6% of the total, targeted sites with overlay widgets installed. Analysis of overlay risk in 2026 notes that filings increasingly cite the failure of the widget itself, arguing that it forces users into a separate, inferior interface and frequently interferes with the assistive technology the user already has configured.

That last point is the engineering objection, independent of the legal one. An overlay is a foreign script mutating your DOM after your own code has run, with no knowledge of your component semantics and no ability to fix a keyboard trap it did not create. It converts a set of static, testable defects into a dynamic, untestable interaction between two systems. It is the accessibility equivalent of pointing a WAF at a SQL injection instead of parameterising the query — and unlike the WAF, it hands the plaintiff a reproducible demonstration of the barrier.

What EN 301 549 Actually Requires — and What Changes This October

The EAA is a directive; the technical detail lives in EN 301 549, the harmonised European standard. Version 3.2.1, the currently referenced version, incorporates WCAG 2.1 Level AA in full — but EN 301 549 is broader than WCAG. It extends requirements to software, mobile applications, digital platforms, multimedia content and hardware, and it includes clauses WCAG simply does not cover. Conforming to WCAG 2.1 AA on your website is necessary and not sufficient.

The scope question catches more organisations than most teams assume. The EAA covers e-commerce, consumer banking, e-books, electronic communications, transport services, and the terminals and self-service machinery attached to them. It applies to any business placing covered products or services on the EU market, regardless of where that business is headquartered — a US or UK SaaS company selling to European consumers is in scope. The microenterprise exemption is narrower than it sounds: fewer than 10 employees and turnover or balance sheet total under €2 million, and it applies to services only, not to products.

The date worth putting in the roadmap is October 2026. EN 301 549 v4.1.1 is anticipated to be referenced in the Official Journal of the EU around then, replacing v3.2.1 as the harmonised standard and raising the baseline from WCAG 2.1 AA to WCAG 2.2 AA. That adds success criteria including Focus Appearance, Dragging Movements, Target Size, Consistent Help, Redundant Entry and Accessible Authentication. Once referenced, conformance to v4.1.1 creates the presumption of conformity with the EAA.

Look at that list of new criteria against what the research says AI-generated UI is worst at, and the overlap is close to total. Focus Appearance is focus management. Dragging Movements is keyboard-and-pointer alternative paths. Accessible Authentication forbids cognitive function tests without an alternative — the sort of thing a generated login form will cheerfully violate. The standard is moving toward exactly the operability requirements that generated code handles least reliably, in the same year enforcement went live.

For organisations with US exposure, the parallel timeline shifted in your favour but did not disappear. The DOJ extended the ADA Title II web accessibility deadlines by one year on 17 April 2026: large public entities now have until 26 April 2027, smaller entities and special districts until 26 April 2028, with WCAG 2.1 AA unchanged as the binding standard. Notably, the rule expressly reaches web content that public entities make available through contractual or licensing arrangements with private vendors — so if you sell software to European public sector buyers or US state and local government, this lands in your contracts before it lands in your product.

Automation Covers About a Third of the Problem

The natural engineering instinct is to add axe-core to CI and declare the problem instrumented. Do that — it is genuinely the highest-leverage single hour of work available here, and it catches the six failure types that make up 96% of what WebAIM detected. But be honest about the ceiling.

Automated accessibility testing catches roughly 20-40% of WCAG issues, with around 70% of WCAG success criteria requiring some degree of manual review. Scanners reliably find programmatic defects: missing alt attributes, colour contrast ratios, absent form labels, broken heading structure. They cannot evaluate whether alt text is meaningful, whether reading order is logical, whether link text makes sense out of context, whether a custom component's keyboard interaction matches user expectation, or whether an error message actually tells someone what to do.

This is a familiar shape. It is the same gap that exists between unit test coverage and product correctness, and it fails in the same direction: a green pipeline that certifies the absence of the problems you could automate, read as evidence for the absence of problems generally. A page can pass axe cleanly and still be impossible to check out on with a keyboard. That is very close to a description of what the Caen court found.

The practice that works in 2026 is unglamorous and layered. Automated scanning in CI for regression detection and continuous monitoring. Manual keyboard-and-screen-reader testing on every critical user journey — not every page, but every path that leads to money or to a legally required action. Periodic testing with actual disabled users, paid for their time. And component-level accessibility tests in the design system, so a fix lands once rather than on 400 pages.

The reason this needs owners rather than a tool subscription is durability. Sites change weekly, design systems evolve, content teams publish daily. In the enforcement era, a clean audit from last year is not a defence if this quarter's releases introduced new barriers — and a court that has already dismissed 71% conformance is unlikely to be impressed by a point-in-time report. Regression prevention is the deliverable, not the audit.

Accessibility Debt Compounds Exactly Like Technical Debt

The cost asymmetry here is one of the largest in software engineering and one of the least budgeted for. Fixing accessibility defects after deployment is widely estimated at 10x or more the cost of addressing them during design, with higher-end estimates reaching 30x when the fix has to propagate through a component library and every consumer of it. Embedding accessibility checks across the development lifecycle rather than at the end is reported to cut remediation cost by around 75%.

Why the multiplier is so steep becomes obvious once you have done one of these projects. Accessibility defects are systemic, not local. A modal that traps focus is not one bug; it is one bug replicated everywhere that modal is used. A colour token that fails contrast is not a page-level fix; it is a design system change with visual regression consequences across the entire product. A form component without programmatic label association breaks every form you have. Retrofitting means changing the primitives, and changing primitives late means re-testing everything built on them.

This is why the AI code generation dynamic matters more than the raw error counts suggest. Generated UI code multiplies the number of one-off, hand-rolled components in a codebase — a bespoke dropdown here, a custom tab panel there, each one plausible-looking, each one carrying its own focus-management defect. It is the opposite of consolidating on a small set of audited primitives. The volume goes up, the reuse goes down, and the remediation surface expands faster than anyone is tracking.

The organisational failure mode is equally predictable, and it is the same one that afflicts test coverage, observability and dependency hygiene: accessibility work loses every sprint prioritisation argument it enters, because it competes with features and nothing visibly breaks when it is deferred. It stays deferred right up until a regulator, a customer, or a court makes it urgent — at which point it is a six-month remediation programme under a judicial deadline instead of a background discipline.

Where a Dedicated Team Changes the Economics

Accessibility remediation is close to a worst-case fit for internal product teams and close to a best-case fit for a dedicated nearshore team, for reasons that are structural rather than promotional.

It is sustained, unglamorous, cross-cutting work with a hard external deadline and no feature output. It requires specialist knowledge — EN 301 549 clause structure, ARIA authoring practices, screen reader behaviour differences between NVDA, JAWS and VoiceOver — that is expensive to build for one project and wasteful to let lapse afterwards. It touches the design system, which means it needs people with enough seniority and enough context to change primitives safely. And it needs to keep running after the audit closes, because the enforcement standard is durability.

This is how we structure it at StepTo. Accessibility is treated as a quality function inside the delivery team rather than a compliance engagement bolted on at the end: axe-core gates in CI from the first sprint, accessibility acceptance criteria written into stories alongside functional ones, keyboard and screen reader passes on every critical journey before a release goes out, and audited primitives in the design system so a focus-management fix lands once rather than four hundred times. Where clients are generating UI code with AI assistants — most are, and we do too — the review gate is the control, not the prompt. Generated components get the same component-level accessibility tests as hand-written ones, because the research is unambiguous that the model's defaults are the web's defaults.

The timezone point is not incidental for this particular kind of work. Remediation under an injunction or a supervisory deadline is high-frequency collaboration: legal counsel interpreting national transposition, design deciding what a compliant focus indicator looks like within the brand, product deciding which journeys are critical, engineering implementing. That is a same-business-day conversation. A senior engineer in Serbia is in your working hours; the alternative is a 24-hour round trip per clarification on a programme measured in weeks.

And the continuity argument is the strongest one. An accessibility practice is an accumulated asset — the audited component inventory, the documented keyboard patterns, the regression suite built from real defects, the knowledge of which of your journeys are legally load-bearing. That asset walks out the door with whoever built it. A dedicated team that stays with the system is what turns a remediation project into a practice that still holds in month eighteen, which is the only timeframe an enforcement regime actually cares about.

A 90-Day Plan If You Are Starting From Nothing

If your product is in EAA scope and you have no accessibility practice, the useful move is not a full audit. It is establishing a floor, then working upward from the journeys that carry legal and commercial weight.

Weeks one to three: scope and baseline. Determine precisely which of your products and services fall under the EAA and in which member states, because that determines which national penalty regimes and supervisory authorities apply. Run axe-core across the full site and app to get a defect count and a distribution. Expect the six WebAIM categories to dominate; if they do not, your scanner is misconfigured. Identify your critical journeys — registration, authentication, search, checkout, support contact, account management — and treat everything else as second wave.

Weeks four to six: fix the mechanical majority and gate the pipeline. Contrast tokens, missing alt text, unlabelled form inputs, empty links and buttons, and missing document language are high-volume, low-judgment fixes that scanners find reliably and that made up 96% of detected errors in the WebAIM data. Do them at the design system level wherever possible. Then put axe-core in CI as a blocking check so the number cannot go back up while you work on the harder part.

Weeks seven to nine: manual passes on critical journeys. Keyboard-only completion of every critical journey, then screen reader passes across at least two combinations. This is where the defects that scanners never see live — focus traps, illogical reading order, custom components that respond to click but not to Enter, error messages announced nowhere. Audit your ARIA while you are in there and delete more than you add; the WebAIM correlation between ARIA volume and error count is a warning, not a coincidence.

Weeks ten to twelve: durability. Write accessibility acceptance criteria into your definition of done. Build component-level accessibility tests for every primitive in the design system. Book paid testing with disabled users on the two highest-value journeys, because that is the only method that finds the problems no checklist encodes. Publish an accessibility statement with an honest conformance claim and a feedback mechanism, which several national transpositions require and which is evidence of good faith if you are ever asked. And put WCAG 2.2 AA on the roadmap now rather than in October, since the six new criteria are mostly focus, target size and authentication — the things generated code gets wrong.

The test of whether any of this survives is the same one that applies to every quality discipline: who owns it in month seven, and will their manager defend the time when the roadmap is under pressure. If the honest answer is nobody, that is the argument for bringing in a partner who is contractually accountable for it — not because the work is beyond your team, but because it is exactly the category of work that internal prioritisation reliably starves.