All articles
WCAGCheck Editorial

87% of Websites Have Invalid HTML: What This Means for Accessibility

New research shows 87% of websites have invalid HTML and over a third fail accessibility checks. Here's what developers need to fix.

87% of Websites Have Invalid HTML: What This Means for Accessibility

New research from The Register reveals a stark picture of web standards adoption: 87.2% of websites contain at least one HTML validation error. Only 2.6% return zero errors and zero best-practice warnings.

More relevant for our purposes: over a third of sites failed accessibility checks.

These numbers aren't surprising if you've worked on legacy codebases or inherited projects from other agencies. But they're worth examining because invalid HTML and accessibility failures are often connected.

Why Invalid HTML Creates Accessibility Problems

Screen readers and other assistive technologies rely on the DOM (Document Object Model) to interpret page content. When browsers encounter invalid HTML, they have to guess what you meant. Different browsers guess differently.

Here's a common example:

<div role="button" onclick="submit()">
  <span>Submit form
</div>

That unclosed <span> tag might render fine visually. Chrome, Firefox, and Safari will all close it automatically. But the DOM each browser constructs may differ slightly, and screen readers may announce the content inconsistently.

More importantly, that div with role="button" is missing keyboard functionality. It fails WCAG 2.1.1 (Keyboard) because you can't tab to it or activate it with Enter or Space without additional JavaScript. A native <button> element gives you this for free.

The Three Most Common HTML Errors That Break Accessibility

1. Missing or Duplicate IDs

Form labels depend on the for attribute matching an input's id. When IDs are missing, duplicated, or mismatched, the programmatic association breaks.

<!-- Broken: label points to non-existent ID -->
<label for="email-input">Email</label>
<input type="email" id="emailInput">

This fails WCAG 1.3.1 (Info and Relationships). Screen reader users hear "Email" and then a separate, unlabelled input field.

2. Improper Nesting

Interactive elements nested inside other interactive elements cause unpredictable behaviour:

<!-- Invalid: button inside anchor -->
<a href="/products">
  <button>View products</button>
</a>

Keyboard users may get trapped or trigger the wrong action. Some screen readers will announce both elements; others will ignore one. This affects WCAG 4.1.1 (Parsing) in WCAG 2.1, though note this success criterion was removed in WCAG 2.2 because browsers now handle parsing errors more consistently. The accessibility impact remains, however.

3. Missing Alt Attributes

The research didn't break down specific errors, but missing alt attributes on images remain one of the most common validation warnings. An image without alt fails WCAG 1.1.1 (Non-text Content).

<!-- Invalid and inaccessible -->
<img src="chart-q3-sales.png">

<!-- Valid but still problematic -->
<img src="chart-q3-sales.png" alt="">

<!-- Accessible -->
<img src="chart-q3-sales.png" alt="Q3 sales chart showing 23% growth in Northern region">

The empty alt tells screen readers to skip the image entirely. That's correct for decorative images but wrong for content that conveys information.

Validation Is Not Accessibility Testing

Before you run your site through the W3C validator and call it done: valid HTML is necessary but not sufficient for accessibility.

This code is perfectly valid:

<div class="nav">
  <div class="nav-item"><a href="/">Home</a></div>
  <div class="nav-item"><a href="/about">About</a></div>
  <div class="nav-item"><a href="/contact">Contact</a></div>
</div>

But it's missing semantic structure. Compare with:

<nav aria-label="Main">
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
    <li><a href="/contact">Contact</a></li>
  </ul>
</nav>

Both validate. The second version lets screen reader users jump directly to navigation, understand it's a list of three items, and navigate between items efficiently.

A Practical Approach

  1. Add HTML validation to your CI pipeline. Catch errors before they reach production. Tools like html-validate or the Nu HTML Checker can run in GitHub Actions or similar.

  2. Run automated accessibility checks alongside validation. axe-core, WAVE, or similar tools catch the low-hanging fruit: missing alt text, empty buttons, insufficient colour contrast.

  3. Don't stop at automation. The research showing a third of sites fail accessibility checks is based on automated testing. Automated tools catch roughly 30-40% of WCAG issues. Keyboard testing, screen reader testing, and manual review catch the rest.

  4. Fix the HTML first. When debugging accessibility issues, start with validation. Invalid HTML can cause automated tools to report false positives or miss real problems.

The 87% figure is a reminder that the basics still matter. Clean, valid, semantic HTML is the foundation everything else builds on.

WCAGCheck scans your website for WCAG compliance issues and tells you exactly what to fix. Try it free at wcagcheck.co.uk