For six consecutive years, the WebAIM Million report told a cautiously encouraging story. The proportion of home pages with detectable accessibility failures was coming down - slowly, but in the right direction. The 2026 report ends that run. 95.9% of the top one million home pages now have detectable WCAG 2 failures, with an average of 56 errors per page. We look at what the data tells us about where things have gone wrong.
For six consecutive years, the WebAIM Million report told a cautiously encouraging story. The proportion of home pages with detectable WCAG failures was coming down – yes it was slow and inconsistent, but it looked like accessibility on websites was headed in the right direction. It wasn’t cause for celebration or seeing online accessibility as being solved, but it was movement.
The 2026 report reverses that trend.
95.9% of the top one million home pages now have detectable WCAG 2 failures, up from 94.8% in 2025. Across those million pages, WebAIM found 56 million distinct accessibility errors – an average of 56.1 per page, a 10% increase on the previous year. And those figures only capture what automated testing can find. The real picture, as the report acknowledges, is almost certainly worse.
So: what’s happening, and why does it matter?
A more complex web
One of the less headline-grabbing findings is possibly a factor in why accessibility has got worse. The average home page now contains 1,437 elements – a 22.5% increase in a single year. That’s a significant jump in the complexity of pages, in a very short space of time.
More elements means more opportunities to introduce errors. Accessibility isn’t just about what a page says or shows; it’s about how every interactive element, every image, every form field, every dynamic component is coded and communicated. As pages get more complex, the effort required to keep them accessible scales accordingly. If the processes and knowledge aren’t keeping up, the errors will.
Complexity alone doesn’t explain a 10% spike in errors in one year, though.
The next question therefore, is what is responsible for this spike?
The role of AI
The report identifies AI-assisted coding as a likely contributor. It’s a reasonable hypothesis and one that fits with the timeline seen for these changes. The tools that generate front-end code – from GitHub Copilot to the wave of AI builders enabling people without development backgrounds to create websites – are producing code that largely doesn’t account for accessibility.
This isn’t a technology problem as much as it’s a priority problem. AI code generation reflects what it’s been trained on and what it’s been asked to optimise for – this is a topic for another day, as there are already studies trying to look at the bias within AI. The point is that if accessibility isn’t in the brief, it won’t be in the output. And for many of the people now using AI to build websites, it isn’t something they’ve thought to include.
There’s also a false confidence issue. Generated code that looks correct can obscure the fact that it’s missing important accessibility attributes. A good developer who understands the code they’re reading will notice a missing aria-label or an unlabelled input. Someone using a tool to produce a page without fully understanding the output won’t. The code goes live instantly with no QA or testing, and the error doesn’t get caught.
None of this is an argument against AI in development. It’s an argument for understanding what you’re building and taking responsibility for it. It’s also an argument for better accessibility training within AI, but as I said above, that is a piece for another day.
The same six errors, seven years running
Another big detail in the report is that 96% of all detected errors still fall into the same six categories that have topped the list for seven consecutive years: low contrast text; missing alt text; unlabelled form inputs; empty links; missing document language; and empty buttons.
These aren’t obscure edge cases. They’re not the result of novel technology or unusual circumstances. They’re basic things that have been well understood, well documented, and widely discussed for years. Some of them are also incredibly easy for non-developers to address. The fact that they continue to account for nearly all detected errors says something about how much of the web is built and maintained, and about the priorities for the people behind the websites.
I do think that knowledge of what accessibility requires is a factor here, but also more general knowledge that accessibility is even a thing to consider. It is a case of they don’t know what they don’t know, as well as potentially being an element of deliberate incompetence.
Why this matters for the public sector
For private sector organisations, poor accessibility is a business and reputational risk. Users who can’t access your site will go elsewhere, and the legal exposure under the Equality Act is real, even if enforcement is inconsistent.
For public sector organisations, the stakes are different. The services people access on a council website, a health trust’s patient portal, or a government platform are often not optional. There isn’t an alternative site to go to. The duty to make those services accessible isn’t just a legal requirement – it’s the basic condition for them to function as public services.
The reversal in the WebAIM data comes at a point where public sector digital teams are under significant resource pressure, and where AI tools are being adopted partly as a way to do more with less. The risk is that efficiency gains in delivery are offset by accessibility debt that goes undetected until an audit or a complaint surfaces it.
What hasn’t changed
The path to an accessible website isn’t complicated, even if it does require deliberate effort. The six error categories that appear at the top of the WebAIM report every year are fixable without specialist knowledge. Sufficient colour contrast can be checked in any design tool. Alt text requires a decision about what an image communicates. Form labels are one attribute in the code. We also often get asked how much more it will cost to design and build an accessible website from scratch, and are met with surprise at how it will have very little impact on the total budget. So it shouldn’t be budgets holding organisations back.
What is required is someone asking the question right at the start of a project, and then at the design stage, the development stage, and through whatever review process exists before something goes live. They require accessibility to be an integral part of how a site is built, not a filter applied at the end.
The 2026 report is a reminder that good intentions and general awareness aren’t enough to move the numbers. Process matters. So does someone taking ownership.
In summary
Accessibility online is getting worse. This will mean you lose a number of your users. This is bad for everyone, so something needs to be done regardless of whether you just got your site redesigned and rebuilt, or whether you’re looking for updates or a complete refresh.
If you’re not sure where your website stands, we offer accessibility audits that cover both automated testing and manual review – the combination that gives you the clearest picture of what’s actually there. Get in touch if you’d like to talk through what that would involve.
