WebAIM Million 2026: the accessibility basics we still need to fix

Accessibility work can feel like a long list of edge cases. But WebAIM's latest analysis points to a more basic problem: familiar barriers are still appearing across a huge number of home pages. For a website team, the useful question isn't only how the overall numbers look. It's which problems you can stop from showing up in your own designs, content, and components.

Here, I explain the 2026 WebAIM Million report in my own words. The measurements are WebAIM's; the ideas for what teams might do next are my interpretation.

What the report measures

In February 2026, WebAIM evaluated one million home pages from the Tranco ranking. Its WAVE accessibility engine looked at each page after scripts and styles had been applied. That's useful context: the report examines what a browser renders, not just the HTML sent by the server. [1] [2]

It's worth keeping two limits in mind. These are home pages, not complete websites, and the results cover issues a tool can detect, not every accessibility barrier. Problems in a checkout flow, account dashboard, or keyboard interaction may not show up here. WebAIM also cautions that a page with no detected errors isn't necessarily accessible or conformant with the Web Content Accessibility Guidelines (WCAG). [2]

The headline numbers moved in the wrong direction

WebAIM found about 56.1 million errors, or an average of 56.1 per home page. That's 10.1% more than in 2025. The share of tested home pages with detectable WCAG failures also rose, from 94.8% to 95.9% (an increase of 1.1 percentage points). [3] [4]

I wouldn't read the remaining 4.1% as proof that those pages are fully accessible. It only means the automated analysis didn't detect a failure. A manual review could still find barriers. And an average error count can't tell us how hard a particular task is: one inaccessible submit button may matter more to someone than many smaller issues elsewhere.

Some results did improve. Fewer pages had missing image alternatives or a missing document language than in 2025. At the same time, contrast failures, unlabeled inputs, empty links, and empty buttons became more common. A change in one area doesn't make the other barriers go away. [4]

Six recurring barriers are a good place to start

Six categories made up 96% of detected errors. The percentages below show how many home pages had each issue, not how many individual elements failed. A page can show up in more than one row, so don't add the percentages together. [4]

If you maintain a design system, this gives you a useful place to start. Check text colors against their real backgrounds. Make sure controls have names that make sense, especially icon-only buttons. Connect form labels to their inputs. And set the page language in the base template so every page doesn't have to remember it.

Image alternatives need thought, not just markup. WebAIM found that 16.2% of images lacked alternative text, not counting images with an empty alt="" attribute. It also found some alternatives that were questionable or repetitive. Adding an attribute everywhere isn't enough: describe meaningful images in context, and leave the alternative text empty for images that are truly decorative. [5]

Forms are another place I'd look closely. In the sample, 33.1% of form inputs weren't properly labeled. That's not the same as the table's 51% of home pages with at least one labeling error; the numbers count different things. A placeholder isn't a substitute for a label. Start with a visible label connected to its input, then check whether the instructions and error messages make sense too. [6]

More markup is not an accessibility strategy

The average home page had 1,437 elements, 14.3% more than the year before. WebAIM cautions against using error density as an accessibility score. Add more elements and the ratio of errors to elements can go down without removing a single barrier. [7]

ARIA (attributes that add accessibility information to HTML) is a good example of why more isn't always better. Pages using ARIA averaged 59.1 detected errors, compared with 42 on pages without it. WebAIM also found that the pages using ARIA were more complex. That doesn't mean ARIA caused the errors. It does mean that counting accessibility attributes won't tell you whether a page works well. [8]

I would start with native HTML controls and add ARIA when an interaction needs it. A custom control still needs the right behavior, focus management, and keyboard support. Adding an accessible name won't take care of those things by itself.

Turn the findings into a repeatable workflow

I see the report as a guide to common problems, not a substitute for checking the tasks people do on your own site. Here's how I would use it to organize the work:

1. Check the important journeys, not only the home page. Look at navigation, contact forms, registration, purchases, or whatever matters most on your site. Note where someone might get stuck.
2. Fix shared causes in shared components. A contrast token, a form field pattern, or an unnamed icon button may affect many pages. Fix the shared source, then check a few places where it's used.
3. Give content authors examples they can use. Explain how to write image alternatives and descriptive links, using examples from your own site instead of a generic checklist.
4. Use scans and hands-on testing together. Scan for issues tools can detect, then try the key interactions with a keyboard, zoom, and screen reader. When you can, involve people with disabilities in evaluating the experience.
5. Keep track of barriers removed, not only scores. Record how to reproduce an issue, which task it affects, and whether the fix worked. A better score matters most when the experience improves too.

For a starting manual routine, see what automated accessibility scans miss.

For me, the clearest lesson isn't that teams need another tool. It's that familiar problems need a reliable way of being caught before they reach users. Use this report to decide where to look, then test your own site to understand what people need you to fix first.

Sources

The statistics in this article come from WebAIM's The WebAIM Million: The 2026 report on the accessibility of the top 1,000,000 home pages, which I accessed on October 8, 2026. The live report may change when a later edition is published.

1. Introduction — report year and evaluation timing.
2. The sample — ranking, rendered-page analysis, and automated testing limitations.
3. Detected errors — total errors, per-page average, and annual change.
4. WCAG conformance — failure prevalence, common categories, and year-over-year comparisons.
5. Images and alternative text — missing and questionable image alternatives.
6. Form labeling — prevalence of improperly labeled inputs.
7. Home page complexity — element counts and the limitations of error density.
8. ARIA — error-count associations and the complexity caveat.

← Back to all articles