Why 95.9% of Home Pages Still Fail Accessibility in 2026

Website accessibility failures are not exotic. The 2026 WebAIM Million report, released this February, found that 95.9% of the top one million home pages have detectable WCAG 2 failures — a regression from 94.8% in 2025 and the first uptick in six years. Six failure types account for 96% of all detected errors: low-contrast text, missing alt text, missing form labels, empty links, empty buttons, and a missing document language attribute. None of these need a redesign to fix. Most are a CSS variable change or a single attribute on an existing element.

Key takeaways

• The failure rate climbed in 2026 — from 94.8% to 95.9% — driven by larger pages and heavier ARIA usage rather than new accessibility problems.
• Six WCAG 2.2 failures cause 96% of detected errors: contrast (83.9%), alt text (53.1%), form labels (51%), empty links (46.3%), empty buttons (30.6%), and document language (13.5%).
• The European Accessibility Act came into force on 28 June 2025 and applies to any consumer-facing product or service offered in the EU — regardless of where the business is based.
• Federal U.S. website accessibility lawsuits jumped 27% in 2025 to 3,117 filings, reversing two years of decline.
• The fixes are mostly HTML attributes and CSS variables — not framework rewrites.

---

What the WebAIM Million 2026 Actually Says

The WebAIM Million is an annual automated scan of the top one million home pages, run by the team at WebAIM using the WAVE accessibility engine. It is the closest thing the industry has to a census of website accessibility failures, and the numbers have been remarkably stable since the project began in 2019.

In 2026, the failure rate ticked up. WebAIM detected 56.1 errors per home page on average, a 10.1% increase from 51 errors per page in 2025. The average home page now contains 1,437 elements — a 22.5% jump in one year and nearly double the element count of 2019. ARIA usage rose 27% year over year. Pages that use ARIA still average more than double the accessibility errors of pages that do not, because most teams reach for ARIA attributes when they should be using native HTML semantics.

WebAIM attributes the regression to two structural shifts: heavier reliance on third-party frameworks and component libraries, and the broader use of AI-assisted coding — what the report calls "vibe coding." Pages are bigger, more componentised, and built faster, but the underlying components are not audited for accessibility before they ship at scale.

One caveat that bears repeating — WAVE and every other automated scanner only catches roughly 30–40% of WCAG failures. The real number of accessibility issues per page is materially higher than the report shows. WebAIM's 95.9% is the floor, not the ceiling.

---

The Six WCAG Failures Behind 96% of Errors

Six failure categories dominate. They have been the same six for the last seven years. Below are the 2026 percentages, the WCAG 2.2 success criterion each maps to, and the typical fix.

1. Low-contrast text (83.9%)

Low contrast jumped from 79.1% to 83.9% in a single year. The WCAG 2.2 minimum is 4.5:1 for normal text and 3:1 for large text (24px regular or 18.66px bold and above). On a typical home page, WebAIM now finds 34 distinct instances of low-contrast text — up 15% from 2025.

The failure is rarely a deliberate choice. It is usually the result of a designer picking a brand grey that looks fine in Figma against a white card, then a developer using that same grey for body copy on a slightly off-white background. The contrast ratio collapses without anyone noticing.

Before:

.body-text {
  color: #999999;
  background: #ffffff;
}
/* Contrast ratio: 2.85:1 — fails AA */

After:

.body-text {
  color: #595959;
  background: #ffffff;
}
/* Contrast ratio: 7.04:1 — passes AAA */

The fix lives in your token system. Audit the design tokens, not the components. If --color-text-secondary resolves to a value that fails 4.5:1 against --color-surface, the entire product fails — and the entire product is fixed in a single PR.

2. Missing alternative text (53.1%)

WebAIM counted 66.6 million images across the sample — an average of 66.6 images per home page, up 13.6% in a year. 16.2% of those images had no alt attribute at all. Of the images missing alt text, 45% were linked — which means the link itself becomes unnamed for screen reader users, compounding the failure.

The fix is alt text that describes the image's purpose, not its appearance. Decorative images get alt="" explicitly so screen readers skip them. Functional images — icons inside links, logo links, status icons — get an alt value that describes the destination or state.

Before:

<img src="img_20260312_hero_final_v3.jpg" />
<a href="/cart"><img src="cart-icon.svg" /></a>

After:

<img
  src="img_20260312_hero_final_v3.jpg"
  alt="QA engineer reviewing a bug report dashboard on a laptop"
/>
<a href="/cart">
  <img src="cart-icon.svg" alt="View cart" />
</a>

The structural fix is to make the alt attribute non-optional at the CMS or component level. If your <Image> component accepts alt as an optional prop, you have a 53% failure rate waiting to happen.

3. Missing form labels (51.0%)

Form labels moved into third place in 2026 at 51%, swapping rank with empty links. This is a WCAG 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value failure, and it is the one that does the most damage to real users — every screen reader user who hits an unlabelled form field has to guess what input belongs there.

Placeholder text is not a label. It disappears the moment a user begins typing, fails contrast on most designs, and is not announced consistently by assistive technology.

Before:

<input type="email" placeholder="Email address" />

After:

<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email" required />

If the design requires a label-less aesthetic, use a visually hidden label that is still in the DOM:

<label for="search" class="sr-only">Search</label>
<input id="search" type="search" placeholder="Search" />

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

4. Empty links (46.3%)

An empty link is an <a> element with no text, no aria-label, and no alt text on any image it contains. Icon-only links — the social icons in your footer, the cart icon in your header, the hamburger menu on mobile — are the most common offenders. Screen readers announce "link" with no further context, leaving the user to guess.

Before:

<a href="https://twitter.com/crosscheck">
  <svg viewBox="0 0 24 24"><!-- X icon path --></svg>
</a>

After:

<a href="https://twitter.com/crosscheck" aria-label="Crosscheck on X">
  <svg viewBox="0 0 24 24" aria-hidden="true">
    <!-- X icon path -->
  </svg>
</a>

Two attributes. The aria-label gives the link an accessible name; aria-hidden="true" on the inner SVG prevents the screen reader from announcing the decorative path data on top of the label.

5. Empty buttons (30.6%)

The same pattern as empty links, applied to <button> elements. The most common cases are icon-only buttons in toolbars, "close" buttons in modals, and custom dropdown triggers.

Before:

<button class="close-modal">
  <svg viewBox="0 0 24 24"><!-- X mark --></svg>
</button>

After:

<button class="close-modal" type="button" aria-label="Close dialog">
  <svg viewBox="0 0 24 24" aria-hidden="true">
    <!-- X mark -->
  </svg>
</button>

A note on the often-overlooked type="button" attribute — when a button without an explicit type is placed inside a form, browsers default it to type="submit". That is a functional bug, not just an accessibility one.

6. Missing document language (13.5%)

The simplest fix in the entire report — a single attribute on a single element. Without it, screen readers fall back to the user's default voice profile, which means an English screen reader reads French content with English phonetics, and vice versa. The content becomes unintelligible.

Before:

<!DOCTYPE html>
<html>
  <head>
    ...
  </head>
</html>

After:

<!DOCTYPE html>
<html lang="en">
  <head>
    ...
  </head>
</html>

For multilingual content, mark the language shift inline:

<p>The French word for "bug" is <span lang="fr">insecte</span>.</p>

13.5% of home pages still ship without this attribute. There is no engineering reason for that number to be above zero.

---

Why the Failure Rate Refuses to Drop

Six identical failures, seven years in a row, on the majority of the public web. The persistence is structural, not a knowledge gap.

Accessibility is not enforced at the point of contribution. A developer writes a button component without an accessible name. Code review checks logic. Manual QA checks business flows. Design review checks visual fidelity. At no point in that pipeline does anything block the merge for an accessibility failure. The component ships, gets reused in 47 places, and now you have 47 instances of the same WCAG 4.1.2 violation.

Automated tools miss most of the surface area. The WebAIM report itself acknowledges that automated scanners catch 30–40% of WCAG failures. The six failures in the headline are visible precisely because they are the easy ones to detect with static analysis. The harder failures — focus management in a custom modal, logical reading order in a CSS Grid layout, ARIA live region announcement timing, keyboard interaction patterns for a custom combobox — are functionally invisible to Lighthouse and axe.

Design systems propagate failures at scale. This is the WebAIM 2026 finding in one sentence: complexity outpaced accessibility hygiene. Average page element count rose 22.5% in a year. A single inaccessible <Button> primitive in a shared library becomes thousands of inaccessible buttons across a product. The reverse is also where the fix has the most reach — repair the primitive, repair the product.

The feedback loop from disabled users is mostly silent. Users who hit an accessibility barrier rarely file a bug. They leave. The absence of complaints in your support inbox is not evidence that the product works — it is evidence that the people for whom it does not work have already gone elsewhere.

AI-assisted coding generates accessibility debt faster. WebAIM points directly at AI-generated front-end code as a contributing factor in the 2026 regression. LLMs trained on the existing web reproduce the existing web's accessibility failures, often with confident-looking ARIA attributes layered on top of broken semantics. The acceleration in code volume is not matched by acceleration in accessibility tooling.

---

What the Regulators Now Require

The legal picture changed materially in 2025.

European Accessibility Act — effective 28 June 2025. The EAA applies to any consumer-facing product or service offered in the EU, regardless of where the business is based. That includes websites, mobile apps, e-commerce, banking services, e-readers, and consumer electronics. The substantive standard is EN 301 549, which incorporates WCAG 2.1 Level AA for digital content. Micro-enterprises (fewer than 10 employees and €2M turnover) are exempt from service-related requirements but still bound by product rules. Member states define enforcement, and penalties include market withdrawal and fines. Products already on the market before 28 June 2025 have until 28 June 2030 to comply.

ADA Title III in the United States. Federal courts logged 3,117 website accessibility lawsuits in 2025 — up 27% from 2,452 in 2024, reversing a two-year decline. Website cases now represent 36% of all ADA Title III federal filings. California, Florida, and New York account for the majority. Roughly 40% of 2025's filings were pro se, with plaintiffs increasingly using generative AI to draft complaints — a dynamic that lowers the cost of bringing a case and raises the volume.

ADA Title II for public entities. State and local government entities with populations of 50,000 or more must conform to WCAG 2.1 Level AA by 24 April 2026. Smaller entities have until 26 April 2027. Federal penalties can reach $150,000 per violation.

The shape of the risk has shifted. Pre-2025, accessibility was a litigation-risk concern primarily for U.S. consumer businesses. Post-EAA, any company selling into the EU is in scope — and the obligations attach to the product, not the company's headquarters.

---

A Realistic Remediation Sequence

Comprehensive accessibility audits usually produce backlogs that get deprioritised and never finished. A more durable path looks like this.

Fix the six WebAIM failures first. Contrast, alt text, form labels, empty links, empty buttons, document language. Run an automated scan with axe DevTools, Lighthouse, or WAVE. The detectable failures will sort by frequency. Resolve them at the design-system level wherever possible — one component fix cascades across every page it appears on. For deeper coverage of the tooling, see the best accessibility testing tools for WCAG 2.2.

Audit the design tokens. Contrast failures almost always trace back to a small number of token combinations — --color-text-secondary on --color-surface-muted, that kind of thing. Fix the tokens, not the instances. Most contrast remediation work in a mature codebase reduces to a Figma variable update propagating into CSS.

Audit the foundational components. Every shared <Button>, <Input>, <Modal>, <Tooltip>, and <Combobox> needs a manual accessibility review. Native HTML element first, ARIA only when the native element cannot express the behaviour, keyboard handlers complete, focus management explicit. If you ship a component library that other teams build on, this is the highest-impact work on the list.

Wire accessibility into CI. Add axe-core or Pa11y to the pipeline. Fail builds on new violations. You will not catch everything — automation finds 30–40% — but you will stop the bleeding. Regression prevention is more valuable than batch remediation.

Run a keyboard-only test cycle every sprint. Unplug the mouse. Tab, Shift+Tab, Enter, Space, arrow keys. Walk through the critical flows: sign up, log in, submit the form, open the modal, complete checkout. Anything that traps focus, anything that you can't reach, anything that doesn't show a visible focus indicator — log it.

Run a screen reader cycle at least monthly. NVDA on Windows with Firefox, VoiceOver on macOS with Safari. Two to three hours per cycle. A QA engineer with no prior screen reader experience can reach competence inside a week.

Prioritise by user impact, not WCAG level. A Level A failure on the sign-up form is a P0. A Level AA failure on the marketing footer is a P3. Triage on traffic and severity, not on the conformance grade.

---

FAQ

What is the current website accessibility failure rate?

According to the WebAIM Million 2026 report, 95.9% of the top one million home pages have at least one detectable WCAG 2 failure. This is up from 94.8% in 2025 and reverses six years of small annual improvements.

What are the most common WCAG failures?

Six categories account for 96% of detected accessibility errors: low-contrast text (83.9% of home pages), missing alt text on images (53.1%), missing form labels (51.0%), empty links (46.3%), empty buttons (30.6%), and missing document language (13.5%).

Is automated accessibility testing enough?

No. Automated scanners detect roughly 30–40% of WCAG failures. They catch the six WebAIM categories well, but they miss keyboard interaction failures, focus management bugs, screen reader announcement issues, and logical reading order problems. Effective accessibility programs combine automated scanning with manual keyboard and screen reader testing.

Does the European Accessibility Act apply to U.S. companies?

Yes, if you sell consumer-facing products or services into the EU. The EAA applies based on where the product or service is offered, not where the company is based. It took effect on 28 June 2025. Existing products and services have until 28 June 2030 to come into full compliance.

What is the easiest accessibility fix to make today?

Add a lang attribute to your <html> element. 13.5% of home pages still ship without one. It is a single attribute on a single element, and it allows screen readers to apply the correct pronunciation profile for the document's language.

---

Start Filing Better Accessibility Bug Reports

When a QA engineer is running a keyboard or screen reader pass and finds a focus-trap bug, an ARIA live region that fails to announce, or a custom combobox that breaks under VoiceOver, the bug report has to be reproducible. Accessibility failures with poor reports get deprioritised. Accessibility failures with full reproduction packages — a screen recording, the console state, the network log, the exact browser and assistive technology version — get fixed.

Crosscheck is a free Chrome extension built for that handoff. It captures a screenshot or session replay, the browser console, network requests, and full environment details in a single click, and routes the report to Jira, Linear, ClickUp, GitHub, or Slack. For accessibility bugs that only reproduce under specific browser-plus-AT combinations, the replay closes the gap between "I saw it on my machine" and "here is exactly what happened, with the DOM and console attached."

The 95.9% number will not drop because of better reports alone. But your team's share of it will.

Try Crosscheck free and document your next accessibility bug with everything the developer needs to fix it.