The Most Common WCAG Failures (And How to Fix Them)

Independent analyses of the top million home pages find that a small cluster of issues — low-contrast text, missing image descriptions, empty links, missing form labels, and missing document language — account for the overwhelming majority of detected errors, year after year. It is not that developers are careless. It is that these mistakes are easy to make, hard to see, and invisible to a sighted person using a mouse. Nobody notices a missing form label until someone tries to fill out the form with a screen reader.

One honest caveat before we start, because anyone who skips it is selling you something: automated scanning catches roughly 30–40% of WCAG success criteria. CompliaScan is built on axe-core (opens in new tab), the same engine behind most reputable tools, and it will find every failure on this list in seconds. But a green scan is a floor, not a finish line. The failures in this article are the ones worth fixing first precisely because they are common, high-impact, and machine-detectable — not because clearing them makes you “compliant.” For where the line sits, see our breakdown of automated vs manual testing.

This is where honest tooling and marketing part ways. The most common failures a machine cannot judge are often the ones that hurt real users most:

• Alt text that exists but says nothing. A scanner sees alt="image" or alt="DSC_0421.jpg"and passes it — the attribute is present. Only a human knows the alt text is useless. Our guide on how to write alt text covers what to actually say.
• Keyboard traps and broken focus order. Modals you can't escape, dropdowns you can't reach, and a focus ring that jumps around the page in a nonsensical order are largely invisible to automated checks but obvious the moment you unplug your mouse.
• Reading order and heading structure that lie. Headings chosen for their font size rather than their meaning produce a document outline that makes no sense to someone navigating by headings — technically valid HTML, practically a maze.
• Captions, transcripts, and error messages. A scanner can tell a <video>lacks a track element; it can't tell whether the captions are accurate, or whether a form error actually explains how to fix the problem.

None of this means automated scanning is a gimmick. It means the scanner's job is to clear the detectable failures fast and cheaply so your human review time goes to the judgment calls. That two-layer approach is exactly what a real accessibility audit looks like.

A quick reality check, because this is where a lot of tools get slippery. Clearing every failure on this list is real, valuable work — but no scanner, overlay, or widget can make your site “compliant” or “lawsuit-proof,” and any product that promises either is telling you what you want to hear. Compliance is a legal determination about the full, lived experience of your site; a tool can only report what it can measure. The one-line-of-code overlays are the worst offenders here — we walk through the evidence against them versus tools like accessiBe if you want the details.

Where CompliaScan can genuinely speed things up is the fix itself. Each detected failure comes with an optional AI-written remediation suggestion — and that runs on your own API key (OpenAI, Anthropic, or Gemini), billed by them at cost with no markup from us. You own the key, you own the spend, and you can turn it off entirely. The scanner finds the problem and points at the exact element; a human still decides whether the fix is right. That is the honest division of labor, and it is the only one that actually holds up.