Laura Wissiak, CPACC for A11y News

Posted on May 7 • Originally published at a11ynews.substack.com on May 12

Unpacking the WebAIM Million report: The Unfinished Homepage Pandemic

#ux #a11y #uxdesign #webdev

New WebAIM Million report just dropped! And nobody is surprised.

Original post from A11y News

New WebAIM Million report just dropped! And nobody is surprised. The results are so similar that I can still use chunks from a draft about the previous report:

The Million report audited 1 million websites to give us a benchmark of progress in web accessibility over the years and the most common WCAG failures. (Spoilers ahead: It’s still low contrast.)

Low contrast takes the first place — once again — by a landslide with 83.9%, which is even a bit of an uptick from last year’s 81%. Our runner-ups — who would have guessed it — are missing alternative text and missing form labels, followed by empty links and empty buttons, and 6th place takes missing document language.

Graph of percentage of pages with most common errors from https://webaim.org/projects/million/

Now, these are not all issues detected, only the top 6 greatest hits of all time. And somehow neither their type nor ranking seems to change over the years:

Low contrast text 83.9%
Missing alternative text for images 53.1%
Missing form input labels 51%
Empty links 46.3%
Empty buttons 30.6%
Missing document language 13.5%

96% of all errors detected fall into these six categories. These most common errors have been the same for the last 7 years. Addressing just these few types of issues would significantly improve accessibility across the web.

Overall theme here: Most websites are unfinished.

But why? Why is it so hard to do it right?

In part, I believe, it is due to the increase in homepage complexity. Keep in mind that the Million report only evaluates homepages specifically. It also features a section on homepage complexity over the past 7 years, which has steadily increased: Since last year, complexity has increased by 22.5% and approximately doubled since the first report in 2019.

Sorry to say this, but, “it’s definitely a Dev issue”.

The last few years, I focused on the issues above. But since they aren’t changing, let’s redirect our attention towards the frameworks and libraries associated with them instead.

That’s not to say that the tech itself was responsible for the errors, but when I saw that the JavaScript library SweetAlert2, which is present on only 1% of the sample pages, was associated with a +81% up in errors, it made me stop for a moment. When I looked that library up, I almost spit out my matcha latte because it explicitly claimed to be accessible. Something’s not adding up here!

JavaScript Frameworks

The number of homepages is somewhat evenly distributed across frameworks, at least in comparison to the situation of the libraries. It’s also impossible to flat-out state that the issues stem from any specific part of the tech stack, but if you find your preferred tools in the red/+ category, maybe take it as a word of warning:

Pages using Astro, Next.js and React had significantly fewer errors than the average of 56.1 per page, and Nuxt.js had just slightly less. Stimulus, Vue.js, AMP, RequireJS all had more errors than the average, and AngularJS and Firebase were deep in the red with +36.4% and +47.7%

While AngularJS at least offers a developer guide on accessibility, Firebase either doesn’t have any official documentation on accessibility, or it is so well hidden that I can’t find it. In both cases, I would argue that it’s not a born-accessible product, meaning that accessibility has to be consciously built in. Which hinges on you, the developer.

It’s not that React is ‘better’ than AngularJS, it’s that the React ecosystem has matured to provide better guardrails, documentation, and tooling that help you catch these errors before they can reach production.

JavaScript Libraries

The most prominent libraries used were jQuery, tallying up over half a million, and jQuery Migrate with 180.000 homepages. Luckily, if you search for “jQuery accessibility” hit after hit pops up. The resources are out there, but you have to know them in order to apply them to your website.

It makes sense that popular libraries are associated with more errors because using them often requires at least some degree of customization. And with that comes the good old “hacking to make it fit”, which we love, unless it breaks pre-existing accessibility features.

Can we fix the Web?

So what do we do about this? Well, not one of the six greatest hits of web accessibility errors is new; so the good news is: there are already plenty of guides and tutorials on how to fix them. The bad news: if we already knew that missing alt text was a problem in 1999 ( WCAG 1.0), why is it still an issue 27 years later?

Look out for DX — Developer Experience

You know about UX (User Experience), and CX (the broader defined Customer Experience), but what about DX? What about the experience of building something on the web?

A truly great developer can probably take the ‘worst’ framework and libraries and still craft an AA-compliant webpage with them. Because they understand how the elements work together and what they need to do.

Some questions to ask yourself to evaluate your tech stack:

Is the framework’s documentation actually accessible?
Does the framework ship with accessible components out-of-the-box? And follow-up question: Does it only say that on the website, or is that claim verified through a software tester I trust?
Does it enforce patterns that prevent errors? Or does it encourage patterns that make accessibility harder to achieve?
Does the framework encourage “over-engineering” simple elements, e.g., turning a simple tag into a complex custom component? Does it increase the opportunity area for errors?
How does the framework handle Single Page Application (SPA) routing? Do they break skip links or focus management when navigating without a full page reload?

Surely, your answers are in part dependent on the maturity of a framework, if the library is being actively (and enthusiastically) maintained and community feedback is being taken into account, but also on how comfortable you are handling them. How you answer them will change over time, alongside your understanding of web technologies.

Low contrast text 83.9%

Why are we still here? Just to suffer? Every year, we see low contrast text in the top spot. How is the first thing you learn about in every web accessibility training still the number one issue worldwide?

On average, each home page had 34 distinct instances of low-contrast text.

No more excuses for it: WebAIM Contrast Checker

Missing alternative text for images 53.1%

Images without an alt attribute in the element count towards missing alternative text. It does not count alt="" (also called an "empty" or "null" alternative text) because that would mark the image as purely decorative and therefore safe to skip without losing any information on the page.

What I found particularly interesting was the extra side note on linked images:

45% of the images missing alternative text were linked images-resulting in links that were not descriptive. One out of every four linked images was missing alternative text.

And no-effort-made alt-text:

10.8% of images with alternative text had questionable or repetitive alternative text-such as alt=”image”, “graphic”, “blank”, a file name, etc., or alternative text identical to adjacent text or the alternative text of an adjacent image.

Missing form input labels 51%

We use forms, a lot of forms, everywhere. Technically, you may have even encountered one on your way to this article in the form of an email input field alongside a prompt to subscribe to A11y News.

We also covered this topic in the Trusted Tester study group: Have you ever been personally victimized by an inaccessible form?

Empty links 46.3% & Empty buttons 30.6%

I’m grouping these together because they work fairly similarly: No text is present to describe the function of the link or button. No anchor text and no aria-label.

Generally, a simple link looks like this:

<a href="https://website.com">Link Text</a>

And a bare bones button looks like this:

<button>Button Text</button>

The text does not only label it visually but also for assistive tech. Then why would one be left empty? Well, if we think back to missing alternative text and the fact that “45% of the images missing alternative text were linked images-resulting in links that were not descriptive”, we can link these three issues together: When you put images inside links or SVGs inside buttons (e.g. when linking to a company’s social media channels, or if you want the logo to also act as a home button/link), it will still need label text! Yet this is often left out because the visual render of the text is unwanted in these scenarios.

And also relevant to this topic:

15.2% of pages had ambiguous link text, such as “click here”, “more”, “continue”, etc. (an increase from 13.7% of pages in 2025, though down from 23.2% in 2020). These pages had 5.3 instances of ambiguous links on average (down from 6.8 in 2025).

17.1% of home pages had a “skip” link present, up from 15.3% in 2025. One out of every ten “skip” links were broken-either they were hidden in a way that made them inaccessible or the link target was not present in the page.

For a cheat sheet on links and buttons, check CSS Tricks: Links and Buttons Guide.

Missing document language 13.5%

It’s honestly a bit disheartening to see the report come out every year and see almost no progress being made. At least missing document language has been on a steady decline- going from 33.1% in 2019 to 13.5% in 2026 — so there is hope that we may see it leave the Top 6 at some point.

For the 87.3% of pages that had a document language defined, the report also features a table of homepages sorted by language and tallying up the average number of errors on them, as well as the percentage difference in errors from the overall average:

This is a reminder that most content on web accessibility is currently available in English. If you see your native language in the red/plus section, and have considered it before: Let me encourage you to start producing content about accessibility in your native language.

While English is still the dominant language in web development, we can’t afford to gatekeep knowledge behind it. The strongest developers are not necessarily English native speakers. We need to start laying the foundation for web accessibility education to become a globally accessible resource, that you can learn about in your native language.

Glossary

Previously published on A11y News.

DEV Community