The EAA Has Been Enforced for a Year. Most Teams Still Can’t Prove Compliance

On June 28, 2025, the European Accessibility Act moved from deadline to enforcement. That was over a year ago now. 

If it doesn’t feel urgent anymore, that’s normal. Deadlines fade fast once nothing visibly breaks. But accessibility doesn’t fail like a server outage. The consequences show up later, as a lawsuit, a failed audit, a deal that stalls in procurement, and by the time they do, the root cause is almost always the same: someone couldn’t use what you built, and nobody caught it in time. 

But let’s not lose sight of what any of this is actually for. This isn’t just about satisfying an auditor. It’s about whether a real person can use the product. 

My father’s best friend has been blind since birth. Watching him in his kitchen, he moves through prep and cooking, faster and cleaner than most sighted people because he can ‘feel’ every surface and tool.  

If you were to hand him an iPhone to pay a bill through a banking app, none of that mastery carries over. A knife has weight and texture that give him feedback. A touchscreen has no way to feel whether his thumb landed on “Transfer” or “Cancel.” Whether he can finish that payment has nothing to do with his skill. It comes down to whether the team that built the app tested for him. 

Enforcement is society’s way of forcing that question to get asked in the first place. But the question itself was never really about enforcement. It’s about him, and everyone like him. 

That’s always been a misreading of what enforcement means, though. Enforcement isn’t a single date — it’s an ongoing posture. 

Enforcement doesn’t ask if you passed once. It asks if you can prove you keep passing 

The EAA requires that digital products, including mobile applications, meet accessibility standards for users with disabilities, with WCAG 2.2 as the technical baseline. But compliance in a regulatory context was never just about whether an application passed a check on launch day. It’s about whether an organization can demonstrate, consistently and over time, that accessibility validation is part of how it ships software. 

That’s a fundamentally different bar than “we ran a scan before the deadline.” It’s the same distinction that exists in every other compliance-driven testing domain: no auditor accepts “it passed once” as evidence of an ongoing control. Accessibility is no exception, and a year of enforcement has made that clear to the organizations now facing audits, procurement questionnaires, and in a growing number of cases — litigation. 

Website accessibility lawsuits in the U.S. just hit a historic high. The first half of 2026 produced the highest volume ever tracked, putting the year on pace to top 6,000 filings — roughly 20% above 2025, which had already jumped 27% over 2024 (UsableNet, 2026 Midyear Report).  

Between EAA enforcement in the EU and ADA litigation in the U.S., “we’ll get to accessibility eventually” has become one of the more expensive positions an engineering or compliance leader can hold. 

AI has made the problem bigger, not smaller 

The timing here matters. Enforcement arrived at the exact moment software delivery accelerated. In many enterprises, AI-generated code now accounts for 40–50% of output, and that share is climbing (Digital.ai, The Fourth Wave: AI Is Writing the Code. Who’s Testing It?). Coding tasks that used to take days now take hours. 

More code, shipped faster, means more accessibility surfaces to validate every sprint, and AI-authored code doesn’t get a pass on accessibility just because it was fast to produce. Missing alt text, broken focus order, unlabeled form fields, and interactive elements that fail keyboard or switch navigation are exactly the kind of regressions that move quickly through a high-velocity pipeline when nothing is checking for them systematically. 

Organizations that haven’t built accessibility validation into their standard release workflow aren’t holding steady. They’re accumulating compliance debt with every release, and the debt compounds faster than it did a year ago. 

Why most teams are still short of the bar 

Here’s the gap that shows up again and again: running a scan is not the same as being able to prove one ran. When accessibility results live in a separate dashboard, disconnected from the build, device, and test execution that produced them, teams end up with documents instead of records. An auditor’s question — which scan ran, against which build, on which device, as part of which test — needs a direct answer, not a reconstruction project. 

A year in, the window to figure it out is smaller than it was 

The EAA is enforced. ADA litigation is active and growing. WCAG 2.2 has raised the baseline everyone is measured against. None of that is new information at this point, but a year of living with it has made one thing clearer: the organizations that are struggling aren’t the ones that don’t understand the requirement. They’re the ones whose testing workflow was not built to produce ongoing, auditable proof that is easy to review and share. 

Closing that gap doesn’t require a new accessibility program from scratch. It requires treating accessibility validation the way mature organizations already treat functional testing as a standard, evidenced part of every release, not a separate initiative that runs alongside it. 

This is where Digital.ai comes in: automated WCAG scanning powered by Deque — the industry’s most widely used accessibility engine — with every result tied to the build, device, and test that produced it, closing the evidence gap. 

Somewhere, there’s a version of my father’s friend trying to use whatever your team just shipped. Compliance is the paperwork trail. He’s the reason any of it is worth building in the first place.