Andrei Kornev

Posted on Nov 8

The Web Got Less Accessible in 2026. Here's What Four Years of WebAIM Data Mean for React Devs

#a11y #react #frontend #webdev

For six years the web was slowly getting more accessible. In 2026 it stopped.

Every February, WebAIM runs an automated accessibility check on the home pages of the top one million websites. The 2026 run found detectable WCAG 2 failures on 95.9% of them, up from 94.8% a year earlier. The average page now has 56.1 detectable errors, up 10.1% from 51.

While writing my thesis on accessibility tooling for React, I went through the WebAIM reports from 2023 to 2025. When the 2026 report came out, I added it to the dataset. Here's what four years of data say, and what they mean if you ship React.

Four years in one table

Metric	2023	2024	2025	2026
Home pages with detected WCAG failures	96.3%	95.9%	94.8%	95.9%
Average detected errors per page	50.0	56.8	51.0	56.1
Average elements per home page	1,050	1,173	1,257	1,437

Two things stand out.

First, the failure rate barely moves. In four years it went from 96.3% to 95.9%. Almost every popular site still fails an automated check, and automated checks only find part of the real problems. WebAIM says this directly: the real level of conformance is lower than these numbers suggest.

Second, pages keep getting heavier. The average home page grew from 1,050 to 1,437 elements, +37% in three years. More elements means more places to get something wrong, and the error count follows.

The same six bugs, every year

About 96% of all detected errors come from just six types. Here's how often each one appeared on home pages:

Failure	2023	2024	2025	2026
Low contrast text	83.6%	81.0%	79.1%	83.9%
Missing image alt text	58.2%	54.5%	55.5%	53.1%
Missing form input labels	45.9%	48.6%	48.2%	51.0%
Empty links	50.1%	44.6%	45.4%	46.3%
Empty buttons	27.5%	28.2%	29.6%	30.6%
Missing document language	18.6%	17.1%	15.8%	13.5%

None of these is hard. None needs a specialist. They're the kind of bugs a linter or a single axe-core run catches in seconds.

The interesting rows are the ones that move:

Missing language is the only steady win. It dropped from 18.6% to 13.5%. My guess: framework starters and templates now ship with <html lang> set by default. One default in a template fixed it for thousands of sites.
Empty buttons go up every year. 27.5% to 30.6%. That's the icon button: a <button> with an SVG inside and no text or aria-label. Component libraries made icon buttons cheap to add, and nobody made them cheap to name.
Missing labels went up too. 45.9% to 51%. Placeholder-only inputs and custom selects are still everywhere. The lesson from the lang row works the other way as well. Fix a bug in a shared default, and it's fixed everywhere. Ship a bug in a shared component, and it's broken everywhere.

Is React the problem?

My thesis originally assumed that client-side frameworks make accessibility worse. The data didn't agree.

Framework	Avg errors, 2025	vs average	Avg errors, 2026	vs average
Next.js	38.6	−24.2%	40.9	−27.1%
React	42.4	−16.8%	43.5	−22.5%
Nuxt.js	45.2	−11.2%	54.7	−2.6%
Vue.js	58.7	+15.3%	64.6	+15.1%

React and Next.js pages had fewer detected errors than average in both years. In 2026 Astro had the fewest of all, 9.0 per page, 84% below average.

This is correlation, not cause. Sites built with React may simply have bigger teams and more QA. But it kills the easy excuse: "we use an SPA framework, so accessibility is hard" doesn't match the numbers.

What does correlate with more errors is complexity and the libraries piled on top. WebAIM's 2026 conclusion links the increase to heavier reliance on third-party frameworks and libraries, and to AI-assisted "vibe coding".

The ARIA paradox

ARIA is supposed to fix accessibility. On real pages it often goes the other way:

82.7% of home pages use ARIA (not counting landmark roles), up from 79.4%.
The average page has over 133 ARIA attributes, up 27% in one year.
Pages with ARIA averaged 59.1 errors. Pages without it averaged 42. Again, more complex pages use more ARIA, so ARIA isn't necessarily the cause. But it's a good reminder of the first rule of ARIA: if a native element does the job, use it. A <button> gets focus, keyboard support and a role for free. A <div role="button"> has to rebuild all of that by hand, and usually doesn't.

Why this is now a business problem

For a long time, accessibility lived in the "nice to have" column. That's changing.

The audience is big. The WHO estimates 1.3 billion people, about 16% of the world, live with significant disability.
Lawsuits are routine in the US. UsableNet counted 5,114 digital accessibility lawsuits in 2025. 70% targeted e-commerce. About 45% of federal suits hit companies that had already been sued before.
The EU has a law now. The European Accessibility Act has applied since June 28, 2025. It covers e-commerce, consumer banking, transport ticketing, telecoms and e-books, and points to EN 301 549, which is built on WCAG.
Overlays are not a fix. In April 2025 the US FTC finalized an order making accessiBe pay $1 million over claims that its AI widget makes any site compliant. A script on top of broken markup doesn't repair the markup. ## What this means for a React team

The six common failures map almost one to one onto checks you can automate today:

Failure	Lint (eslint-plugin-jsx-a11y)	Runtime (axe-core)
Low contrast	not visible in JSX	`color-contrast`
Missing alt	`alt-text`	`image-alt`
Missing labels	`label-has-associated-control`	`label`
Empty links	`anchor-has-content`	`link-name`
Empty buttons	`control-has-associated-label`	`button-name`
Missing lang	`html-has-lang`	`html-has-lang`

What I'd do, in this order:

Turn on the lint rules. They catch alt, label and empty-link bugs while you type. control-has-associated-label is off even in the recommended config, and that's the one that catches empty buttons, so check what your preset really enables.
Run axe-core in development and in CI. Contrast can't be linted, because the color depends on CSS at runtime. A runtime check is the only automated way to catch it.
Fix the shared components first. Your IconButton, Input and Link components are where the empty-button and missing-label bugs breed. One fix there is a fix on every page.
Keep contrast in your design tokens. Check token pairs once, and new screens can't drift below 4.5:1 by accident.
Still test by hand. Tab through the page, open a screen reader. Automation finds the boring 96%, not the rest. I wrote about how I built this kind of pipeline (lint, dev overlay and CI audit on one rule catalog) in my previous post. Next week: what happened when we ran it on a real production project, and how 427 violations became zero in three weeks.

Which of the six do you see most in your codebase? My bet is empty buttons.

DEV Community