51 Errors per Homepage and Nobody Noticed

Every year, a major accessibility research project (such as the WebAIM Million annual survey) crawls the top one million homepages and counts accessibility errors. Every year, the results are sobering. According to the 2025 edition of that research, approximately 94.8% of homepages had automatically detectable WCAG failures. Not "could be improved." Not "might cause issues for some users." Failures. Hard, measurable, automatic failures.

The same study reported the average homepage had approximately 51 distinct accessibility errors. Fifty-one. On one page. That's not a misprint. Let that sit for a second.

I've been auditing websites for years, and I still find this number shocking. Not because I don't believe it, but because most of these errors are so preventable. They're not edge cases. They're not obscure WCAG 2.2 Level AAA requirements that require a philosophy degree to interpret. They're basic stuff that's been in the spec for two decades.

The Usual Suspects

Let's walk through the biggest offenders from the 2025 data, because understanding them is the first step to not being part of the 94.8%.

Low-Contrast Text (reported on ~79% of pages surveyed)

Nearly eight out of ten homepages have text that doesn't meet minimum contrast requirements. The WCAG AA standard is a 4.5:1 ratio for normal text and 3:1 for large text. That's not a high bar. And yet, the most common culprit is "trendy" light gray text on white backgrounds. You've seen it. Light #999 gray on white. It looks elegant in the design mockup. It becomes invisible to anyone over 40, anyone in bright sunlight, or anyone with even mild low vision.

Here's a real example of what this looks like in HTML:

<!-- Failing (ratio: ~2.4:1) -->
<p style="color: #999999; background: #ffffff;">
  Read our privacy policy
</p>

<!-- Passing (ratio: ~7:1) -->
<p style="color: #595959; background: #ffffff;">
  Read our privacy policy
</p>

Fixing this takes thirty seconds in your CSS. Typically just swapping a color token in your design system.

Missing Alt Text on Images (reported on ~18.5% of pages surveyed)

Almost one in five pages has at least one image with no alt attribute at all, or with an alt attribute stuffed with the filename like alt="hero-banner-v3-FINAL-FINAL2.jpg". Screen readers announce that verbatim. To a blind user, that's gibberish.

The rule is simple: if the image conveys information, describe it. If it's purely decorative, use alt="" (an empty alt attribute, which tells screen readers to skip it). What you should never do is leave the attribute out entirely or use the filename as the description.

<!-- Terrible -->
<img src="hero-banner-v3-FINAL.jpg">

<!-- Also terrible -->
<img src="hero-banner-v3-FINAL.jpg" alt="hero-banner-v3-FINAL.jpg">

<!-- Decorative image, handled correctly -->
<img src="squiggle-divider.svg" alt="">

<!-- Informational image, handled correctly -->
<img src="ceo-headshot.jpg" alt="Jane Smith, CEO of Example Inc">

Empty Links and Buttons

This one drives me absolutely up the wall. An anchor tag with no text. An icon button with no label. A "read more" link that just says "read more" with no context about what you're reading more of.

Screen reader users often navigate by pulling up a list of all links on a page. Imagine that list says: "Read more, Read more, Read more, Click here, Click here, Learn more, Read more." Useless. Completely useless.

<!-- Broken: icon with no label -->
<button><svg>...</svg></button>

<!-- Fixed: aria-label to the rescue -->
<button aria-label="Close menu"><svg aria-hidden="true">...</svg></button>

<!-- Broken: vague link -->
<a href="/blog/post-1">Read more</a>

<!-- Fixed: descriptive link text -->
<a href="/blog/post-1">Read more about our accessibility audit tool</a>

Missing Form Labels

Forms are where accessibility failures really hurt people. A sighted user can see that a text field is next to the word "Email." A screen reader user can't make that spatial connection unless you've actually associated the label with the input using <label for> or aria-label. Placeholder text doesn't count. It disappears when you start typing, and screen readers handle it inconsistently.

Missing Document Language

This one is almost funny because it's so easy to fix. Your HTML tag should declare what language the page is in: <html lang="en">. Without it, screen readers may use the wrong pronunciation rules and read your content in a completely different language's phonetics. It's one attribute. One.

Why Doesn't Anyone Fix This?

Honestly? Because these errors are invisible if you don't know to look for them. They don't break the page for the majority of users. The site "works." It loads, it sells, it converts. The failures are only visible to people who use assistive technology, and most dev teams don't include or test with those users.

The other problem is that accessibility audits sound expensive and complicated. They don't have to be. Running a free audit with a tool like SCOUTb2 takes about ten seconds and will surface the most common errors automatically. You don't need a consultant to tell you your contrast ratio is 2.4:1.

The annual accessibility survey data is a mirror, and the reflection is uncomfortable. But it's also an opportunity. If 94.8% of your competitors are failing at this, doing the basics well is actually a competitive advantage. That's a rare thing in web development.

Start with your homepage. Run an automated scan to identify the most common issues. Fix the contrast. Add alt text. Label your buttons. It's not glamorous work, but it matters to real people, and it's more achievable than the 51-errors average makes it sound.

Disclaimer: This article is for informational purposes only and does not constitute legal, professional, or compliance advice. SCOUTb2 is an automated scanning tool that helps identify common issues but does not guarantee full compliance with any standard or regulation.