WebAIM's Million — an annual study of the one million most popular websites — consistently finds the same accessibility failures repeated across the web. The top six account for the majority of all WCAG Level A and AA failures. Knowing them means you can identify the most impactful accessibility bugs quickly, before reaching for specialist tools or advanced techniques.
The most common failures in the real world
% of websites with each accessibility failure — WebAIM Million (approx.)
These are not edge cases. They are the default state of the web. Most of them are one-line fixes once identified.
1. Low contrast text
The most widespread failure. WCAG 1.4.3 (Level AA) requires text to have a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold and above) requires 3:1.
Common offenders: light grey body text on white backgrounds, light-coloured placeholder text, disabled-state labels that are too faded, and blue links on a dark blue background.
Testing: use a contrast checker. axe DevTools and browser extensions like Colour Contrast Analyser flag these automatically. In Chrome DevTools, the Elements panel shows the contrast ratio when you inspect a text element.
Fix: increase the contrast ratio. This is a design change, but a one-line CSS change in most cases. color: #767676 on white passes at 4.54:1; color: #999 fails at 2.85:1. The difference is invisible to most sighted users and significant for low-vision users.
2. Missing alt text on images
WCAG 1.1.1 (Level A) requires all non-text content to have a text alternative. A screen reader encountering <img src="header.jpg"> with no alt attribute announces the filename — "header dot jpg" — which is useless.
Two cases, two different fixes:
- Informative images (a product photo, a chart, a diagram explaining a concept):
alt="Product: Acme Widget in blue, shown from the front"— describe the content and function. - Decorative images (background patterns, visual dividers, purely decorative icons):
alt=""— an empty alt tells screen readers to skip the element entirely. Omitting the attribute is not the same as an empty attribute.
Testing: in DevTools, inspect every image and check the alt attribute. Browser extensions like WAVE add visual indicators directly on the page. Or run axe DevTools and filter for image-related violations.
3. Missing form input labels
WCAG 1.3.1 (Level A) requires every form input to have a programmatically-associated label. Placeholder text is not a label — it disappears as soon as the user starts typing, and screen readers may not announce it at all.
<!-- Inaccessible: no label -->
<input type="email" placeholder="Enter your email">
<!-- Accessible: label explicitly linked via for/id -->
<label for="email">Email address</label>
<input id="email" type="email" placeholder="name@example.com">The for attribute on the label must match the id on the input. When linked, clicking the label focuses the input (a usability benefit for everyone) and screen readers announce the label text when the input receives focus.
Alternative patterns: aria-label="Email address" directly on the input (for cases where a visible label is not desired), or aria-labelledby pointing to another element that serves as the label.
4. Empty links
WCAG 2.4.4 (Level A) requires links to have descriptive text. "Click here" and "Read more" announce identically when a screen reader user pulls a list of all links on the page — which is a common navigation pattern. Fifty "read more" entries tell the user nothing about what any of them link to.
Empty links (<a href="/about"></a>) are even worse — the screen reader has nothing to announce.
Testing: use WAVE or run the page through a screen reader link list (in NVDA, press K to jump link to link). Are they all meaningful out of context?
Fix: make link text descriptive of the destination ("Read the annual report", "View account settings"). If the design uses "Read more" paired with a heading, use aria-labelledby to associate the link with the heading so the full context is available to assistive technology.
5. Missing document language
WCAG 3.1.1 (Level A) requires the <html> element to declare the page's primary language: <html lang="en">. Screen readers use this attribute to select the correct pronunciation engine. Without it, a French-language page might be read with English phoneme rules, producing completely unintelligible audio.
This is a common failure because it is invisible to sighted users, easy to forget in templates, and only shows up in assistive technology or automated scans.
Fix: add lang="en" (or the appropriate BCP 47 language tag) to the <html> element in every page template.
6. Empty buttons
Like empty links, buttons with no accessible name announce as "button" — no action, no purpose. Icon-only buttons without an accessible name are the most common form: <button><svg>...</svg></button> where the SVG has no title and the button has no label.
Fix options:
aria-label="Close"on the button<span class="sr-only">Close</span>inside the button (visually hidden but present in the accessibility tree)title="Close"— announced by some screen readers but not reliable as the sole accessible name
Other issues worth testing for
Beyond the top six: missing skip-navigation links (keyboard users must Tab through the entire navigation on every page load without them), non-semantic interactive elements (divs and spans used as buttons without role, keyboard handling, or focus management), missing focus indicators (outline: none removed without a replacement), and autoplay media (videos that start with sound are disorienting for screen reader users and everyone in a quiet office).
⚠️ Common mistakes
- Treating contrast as a design team problem. QA should verify the rendered contrast in the browser, not the design file values — CSS overrides, theme variations, and hover states regularly differ from what the designer specified.
- Accepting placeholder text as a substitute for a label. Placeholder text fails WCAG in multiple ways: it disappears, it often has insufficient contrast, and screen readers do not consistently announce it. No exceptions.
- Fixing only the automated findings. The six failures above can all be caught by axe or Lighthouse. The failures that are not caught automatically — keyboard traps, illogical focus order, dynamic content that does not announce — are often worse in terms of user impact. Automated tools clear the floor; manual testing finds the rest.
🎯 Practice task
Run a structured bug-finding exercise on any public website.
- Install the axe DevTools browser extension (free). Run it on three pages of a site you test regularly.
- Group the findings by the categories above. How many are contrast? How many are missing labels or alt text?
- For each finding, identify the one-line fix. Write it as a bug report: WCAG criterion, current state, expected state, proposed fix.
You will likely find real bugs — the WebAIM data shows that over 95% of tested websites have WCAG failures. The goal is to turn abstract standards into concrete, actionable bug reports.