How to Fix Common WCAG Failures (2026 Guide)

Why These Failures Keep Appearing

After scanning thousands of websites for WCAG compliance, we've identified the same issues appearing on the vast majority of sites. The WebAIM Million study confirms it: 96.3% of home pages have detectable WCAG 2 failures—and most of those failures come from a short list of common mistakes.

The good news? These failures are fixable. In most cases, you can resolve them in minutes with the right knowledge. This guide covers the ten most common WCAG failures, explains why they matter, and provides practical code examples for fixing each one.

Before diving in, consider running a free accessibility scan on your site to see which of these issues affect you. Then use this guide as your remediation playbook.

WCAG Criterion: 1.1.1 Non-text Content (Level A)

Missing alt text is the single most common accessibility failure, appearing on over 55% of all websites. When images lack text alternatives, screen reader users encounter "image" or "graphic" with no context about what they're looking at.

<!-- Missing alt entirely -->
<img src="product.jpg">

<!-- Placeholder alt -->
<img src="chart.png" alt="image">

<!-- Filename as alt -->
<img src="hero.jpg" alt="IMG_4521.jpg">

<!-- Keyword stuffing -->
<img src="shoes.jpg" alt="shoes sneakers running shoes athletic shoes buy shoes">

<!-- Descriptive alt text -->
<img src="product.jpg" 
     alt="Red Nike Air Max sneakers, side view">

<!-- Decorative image (empty alt) -->
<img src="decorative-line.svg" alt="">

<!-- Complex image with longer description -->
<img src="chart.png" 
     alt="Bar chart showing 40% increase in sales from Q1 to Q4 2025">

WCAG Criterion: 1.4.3 Contrast (Minimum) (Level AA)

Low contrast text appears on over 80% of websites, making it the most widespread accessibility issue. Light gray text on white backgrounds is the classic offender—trendy in design mockups but unreadable for many users.

WCAG Criterion: 3.3.2 Labels or Instructions (Level A)

Form inputs without proper labels leave screen reader users guessing about what information to enter. Placeholder text alone doesn't count—it disappears when users start typing and isn't announced consistently by assistive technology.

<!-- Placeholder instead of label -->
<input type="email" placeholder="Email">

<!-- Label not associated -->
<label>Email</label>
<input type="email" id="email">

<!-- Hidden label (sometimes okay) -->
<label class="sr-only">Email</label>
<input type="email">

<!-- Explicit label association -->
<label for="email">Email address</label>
<input type="email" id="email">

<!-- Implicit label (wrapping) -->
<label>
  Email address
  <input type="email">
</label>

<!-- With aria-labelledby -->
<span id="email-label">Email</span>
<input type="email" 
       aria-labelledby="email-label">

.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;
}

WCAG Criterion: 2.4.4 Link Purpose (Level A) and 4.1.2 Name, Role, Value (Level A)

Icon-only buttons and links are everywhere—social media icons, hamburger menus, close buttons, arrow navigation. Without accessible names, screen readers announce them as "button" or "link" with no indication of what they do.

<!-- Icon button without label -->
<button>
  <svg><!-- hamburger icon --></svg>
</button>

<!-- Empty link -->
<a href="/twitter">
  <i class="fa-twitter"></i>
</a>

<!-- Image link without alt -->
<a href="/">
  <img src="logo.svg">
</a>

<!-- aria-label for icon buttons -->
<button aria-label="Open menu">
  <svg aria-hidden="true">...</svg>
</button>

<!-- Visually hidden text -->
<a href="/twitter">
  <i class="fa-twitter" aria-hidden="true"></i>
  <span class="sr-only">Follow us on Twitter</span>
</a>

<!-- Alt text for image links -->
<a href="/">
  <img src="logo.svg" alt="RatedWithAI home">
</a>

WCAG Criterion: 3.1.1 Language of Page (Level A)

This is the easiest fix on the list but often overlooked. Without a language declaration, screen readers may use the wrong pronunciation rules, making content incomprehensible. French words read with English pronunciation? Not a great experience.

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

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

<!-- For other languages -->
<html lang="es"> <!-- Spanish -->
<html lang="fr"> <!-- French -->
<html lang="de"> <!-- German -->

For pages with mixed languages, use the lang attribute on specific elements. See 3.1.2 Language of Parts for details.

WCAG Criterion: 2.4.7 Focus Visible (Level AA)

Removing the default focus outline is one of the most common (and harmful) CSS practices. Without visible focus indicators, keyboard users can't tell which element they're interacting with. It's like hiding the mouse cursor.

/* This breaks keyboard navigation */
*:focus {
  outline: none;
}

button:focus,
a:focus {
  outline: 0;
}

/* Use :focus-visible for keyboard-only focus */
button:focus-visible,
a:focus-visible {
  outline: 2px solid #3b82f6;
  outline-offset: 2px;
}

/* Custom focus styles that match your design */
.btn:focus-visible {
  outline: none;
  box-shadow: 0 0 0 3px rgba(59, 130, 246, 0.5);
}

/* High contrast focus for dark backgrounds */
a:focus-visible {
  outline: 2px solid #fff;
  outline-offset: 2px;
  border-radius: 2px;
}

WCAG Criterion: 1.3.1 Info and Relationships (Level A) and 2.4.6 Headings and Labels (Level AA)

Headings aren't just for styling—they create a navigable document outline. Screen reader users jump between headings to scan content. Skipping levels or using headings inconsistently breaks this navigation pattern.

<!-- Skipping heading levels -->
<h1>Page Title</h1>
<h4>Section Title</h4>  <!-- Skipped h2, h3 -->

<!-- Multiple h1s -->
<h1>Logo</h1>
<h1>Page Title</h1>
<h1>Section</h1>

<!-- Using headings for styling -->
<h3>This small text looks nice</h3>

<h1>Page Title</h1>
  <h2>Section 1</h2>
    <h3>Subsection 1.1</h3>
    <h3>Subsection 1.2</h3>
  <h2>Section 2</h2>
    <h3>Subsection 2.1</h3>
      <h4>Detail 2.1.1</h4>

<!-- Style with classes, not heading level -->
<p class="text-sm font-semibold">
  This small text looks nice
</p>

WCAG Criterion: 1.4.1 Use of Color (Level A)

If links are only distinguished by color (no underline or other visual cue), color-blind users may not recognize them as clickable. This is especially problematic when links are embedded in paragraphs of text.

/* Only difference is color */
a {
  color: #3b82f6;
  text-decoration: none;
}

/* Underline + color */
a {
  color: #3b82f6;
  text-decoration: underline;
}

/* Or underline on hover with high contrast */
a {
  color: #3b82f6;
  text-decoration: none;
  font-weight: 600;
}
a:hover, a:focus {
  text-decoration: underline;
}

WCAG Criterion: 1.4.11 Non-text Contrast (Level AA)

UI components like form field borders, icons, and focus indicators also need sufficient contrast. A light gray input border on a white background may be too subtle for users with low vision to see.

WCAG Criterion: 2.1.2 No Keyboard Trap (Level A)

Keyboard traps occur when users can Tab into a component but can't Tab out. This is common with modals, embedded media players, and custom widgets that capture keyboard events. Users get stuck and have to refresh the page.

// 1. Trap focus inside the modal
// 2. Allow Escape to close
// 3. Return focus to trigger element on close

dialog.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') {
    closeModal();
    triggerButton.focus(); // Return focus
  }
});

// Use the native <dialog> element when possible
<dialog>
  <button onclick="this.closest('dialog').close()">
    Close
  </button>
</dialog>

Related Resources