By Web accessibility standards are not new. The Web Content Accessibility Guidelines have existed in some form since 1999, and most professional developers know the basics: images need alt text, buttons need labels, color contrast needs to be readable. Despite that, WebAIM’s eighth annual scan of the internet’s top one million home pages found that 95.9% still carry at least one detectable WCAG 2 failure. That is worse than the year before, when the rate was 94.8%, and it breaks six straight years of gradual progress.
The average home page now carries 56.1 accessibility errors, up 10.1% from 51 the prior year. Something changed to reverse years of steady gains, and the data points to a specific cause: pages have gotten far more complicated.
The Same Six Problems, Year After Year
The failures themselves are not mysterious. WebAIM has tracked the same six error types at the top of its list since 2019, and 2026 didn’t change the ranking. Low contrast text showed up on 83.9% of pages, up from 79.1%. Missing alt text appeared on 53.1%. Missing form labels showed up on 51%. Empty links accounted for 46.3%, empty buttons for 30.6%, and missing document language for 13.5%. Those six categories alone explain 96% of every WCAG failure WebAIM found.
Fixing any one of these is fast. One line closes a missing alt tag. Two lines add a missing form label. One attribute fixes an empty button. Seven years of the same failures topping the list reflects a process gap: most teams already know these rules exist but lack a consistent step that checks for them before a page goes live.
More Code, More Places to Fail
A typical home page held 1,437 elements in 2026. That is 22.5% more than a year earlier and close to double the 782 elements a typical page carried back in 2019. Every added element is another place an error can hide, and generative AI has sped up how fast that complexity grows. AI tools now produce images, documents, and written copy at high volume, and none of that output is accessible by default. As teams fold AI-generated material into their sites faster than they can review it, inaccessible content keeps piling up.
Regulators have taken note, at least according to accessiBe’s own reading of the situation. When the Department of Justice pushed back its ADA Title II digital accessibility compliance deadlines by a year, accessiBe’s analysis of the rule change points to the growth of AI-generated content as one of the emerging risks behind the delay, alongside resource limits and open questions about WCAG’s supporting materials.
Complexity Tools Aren’t Helping on Their Own
ARIA attributes, meant to make complex web components easier for screen readers to interpret, grew 27% in a single year and now appear more than six times as often as they did in 2019. The trouble is what happens next: a page with ARIA present averages 59.1 errors, roughly 17 more than the 42 errors a page without it typically carries. Adding the attribute correlates with worse outcomes on average, which sounds backwards until the mechanism becomes clear: teams add ARIA to signal that a component is accessible, then rarely verify the component actually behaves the way ARIA claims it does.
Specific libraries show the same drift. A page running Swiper averages 74 errors, 31.8% higher than the site-wide norm. FancyBox climbs further, averaging 90 errors, 60.3% above that norm. SweetAlert2 tops the group, averaging 101.6 errors per page. These tools handle visual effects and interaction well, but accessibility labels were never part of what they generate automatically. Adding them by hand is a step most teams skip.
Closing the Gap Takes More Than One Fix
Standards are documented. Legal exposure is real, spanning ADA Title III lawsuits, Section 508 enforcement, and European Accessibility Act requirements. What separates sites with low error counts from sites with 60 or 100 errors per page comes down to process: whether a team catches mistakes at each stage where they get introduced, while code is being written, after a site goes live, and in the harder cases automated tools cannot check on their own.
accessiBe built its three-part platform around exactly that idea. accessServices handles the cases automation struggles with: formal audits, VPAT documentation, and sessions with people who actually use assistive technology day to day. accessFlow checks code during development and routes findings straight into tools like Jira, Asana, and Azure Boards, so an accessibility fix becomes just another item in the sprint. accessWidget scans live sites every 24 hours to catch what changes after launch, whether that is a content update or a third-party script.
WebAIM’s report puts it directly: “improving accessibility at scale will require both better practices and simpler systems.” Seven years of consistent data back that up, and the fix has been available the whole time. It is a process most sites still don’t have in place.
