15 Common Accessibility Violations (And How to Fix Them)

According to WebAIM's 2025 Million Report, 94.8% of home pages have detectable WCAG failures, with an average of 51 accessibility errors per page. That's over 50 million distinct errors across the top 1 million websites.

If those numbers make you uncomfortable, you're not alone. Many developers want to build accessible websites but don't know where to start. The good news? Most violations follow predictable patterns, and once you understand them, they're straightforward to fix.

This guide walks you through 15 of the most common accessibility violations found in real-world websites, explains why they matter, and shows you exactly how to fix them with code examples. Whether you're a developer, QA engineer, or accessibility specialist, you'll find actionable solutions for each violation.

Why Accessibility Matters

Before diving into violations, let's be clear about the stakes:

• 1.3 billion people globally live with some form of disability
• 70% of government, news, and e-commerce websites are inaccessible to users with visual impairments
• Accessibility isn't optional—it's a legal requirement under the ADA, AODA, EN 301 549, and other regulations
• Fixing accessibility issues improves SEO, reduces bounce rates, and expands your market

Now, let's fix these violations.

---

1. Missing or Insufficient Color Contrast

Prevalence: Found on 79.1% of home pages WCAG Criterion: 1.4.3 (Contrast - Minimum)

The Problem

Text with insufficient color contrast is invisible to users with low vision or color blindness. This is the most commonly-detected accessibility violation in the wild. When foreground and background colors don't have enough contrast, roughly 1 in 5 users (people with low vision, older adults, and even users viewing in bright sunlight) can't read the content.

WCAG AA requires a 4.5:1 contrast ratio for normal text and 3:1 for large text (18pt+ regular or 14pt+ bold).

Example of the Problem

<!-- FAIL: #777777 on #FFFFFF = 4.47:1 (below 4.5:1 threshold) -->
<p style="color: #777777;">This text fails WCAG AA contrast requirements.</p>

<!-- FAIL: Light gray on white is too faint -->
<p style="color: #BFBFBF;">Helper text that's barely visible.</p>

How to Fix It

<!-- PASS: #424242 on #FFFFFF = 11.5:1 (exceeds 4.5:1) -->
<p style="color: #424242;">This text meets WCAG AA contrast requirements.</p>

<!-- PASS: Darker text on light backgrounds -->
<p style="color: #333333;">Helper text that's clearly visible.</p>

<!-- PASS: Light text on dark backgrounds -->
<div style="background-color: #1a1a1a;">
  <p style="color: #F5F5F5;">Light text on dark background = excellent contrast.</p>
</div>

Best Practices

• Use a contrast checker tool (WebAIM, Stark, or Accessibility Insights) during design and development
• Define approved color pairs in your design system
• Test both normal and large text separately
• Remember: you cannot round up (4.47:1 fails)
• Design for both light and dark themes from the start

---

2. Missing Alternative Text for Images

Prevalence: 26% of images lack alt text; found on 54.5% of websites WCAG Criterion: 1.1.1 (Non-text Content)

The Problem

Images without alt text create a complete barrier for blind and low-vision users relying on screen readers. Screen readers announce images as "image" or "unlabeled graphic" when alt text is missing, providing zero context about what the image shows or why it matters.

Alt text also improves SEO and helps users when images fail to load.

Example of the Problem

<!-- FAIL: No alt text -->
<img src="dashboard-screenshot.png" />

<!-- FAIL: Placeholder alt text -->
<img src="user-profile.jpg" alt="image" />

<!-- FAIL: Alt text that's not descriptive -->
<img src="chart.png" alt="chart" />

How to Fix It

<!-- PASS: Descriptive alt text for informational images -->
<img
  src="dashboard-screenshot.png"
  alt="Dashboard showing sales by region: North (35%), South (28%), East (22%), West (15%)"
/>

<!-- PASS: Concise alt text for profile images -->
<img
  src="user-profile.jpg"
  alt="Sarah Chen, VP of Engineering at Acme Corp"
/>

<!-- PASS: Functional alt text for chart images -->
<img
  src="quarterly-growth-chart.png"
  alt="Quarterly revenue growth: Q1 $2.1M, Q2 $2.4M, Q3 $2.8M, Q4 $3.1M"
/>

<!-- PASS: Decorative images get empty alt text -->
<img src="decorative-border.png" alt="" />

Key Rules for Alt Text

1. Be descriptive: Include relevant context and information
2. Keep it concise: 125 characters is a good target
3. Don't say "image of": Screen readers already announce it's an image
4. For decorative images: Use alt="" (empty alt attribute)
5. For charts/graphs: Include the data or key insights in the alt text

---

3. Missing Form Input Labels

Prevalence: 48.6% of websites have missing form labels WCAG Criterion: 1.3.1 (Info and Relationships), 3.3.2 (Labels or Instructions)

The Problem

Form inputs without labels leave users guessing what each field expects. This is particularly problematic for:

• Screen reader users who hear only "input" without context
• Motor-impaired users with larger click targets (labels expand the clickable area)
• Cognitive disability users who benefit from clear instructions

Using placeholder text as a label does not meet WCAG requirements because it disappears when the user starts typing.

Example of the Problem

<!-- FAIL: No label element -->
<input type="email" placeholder="email@example.com" />

<!-- FAIL: Placeholder masquerades as label -->
<input type="password" placeholder="Enter your password" />

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

How to Fix It

<!-- PASS: Proper label-input association via for/id -->
<label for="email">Email Address</label>
<input type="email" id="email" name="email" required />

<!-- PASS: Label wraps the input -->
<label>
  Email Address
  <input type="email" name="email" required />
</label>

<!-- PASS: Aria-label for icon-only inputs -->
<input
  type="search"
  aria-label="Search products"
  placeholder="Search..."
/>

<!-- PASS: Multiple inputs with grouped labels -->
<fieldset>
  <legend>Shipping Address</legend>
  <label for="street">Street Address</label>
  <input type="text" id="street" name="street" />

  <label for="city">City</label>
  <input type="text" id="city" name="city" />
</fieldset>

Best Practices

• Always use <label> elements—never rely on placeholders alone
• Associate labels using for="id" attribute matching the input's id
• Use <fieldset> and <legend> to group related inputs
• Include error messages inside or near the label
• Use aria-label or aria-labelledby only as a fallback

---

4. Poor Heading Structure

Prevalence: Common on pages with inconsistent heading hierarchies WCAG Criterion: 1.3.1 (Info and Relationships)

The Problem

Screen reader users navigate pages using headings like sighted users scan with their eyes. When you skip heading levels (jumping from h1 to h4) or use headings randomly, you create confusion about content hierarchy.

Proper heading structure helps all users:

• Understand page organization
• Navigate quickly using heading shortcuts
• Know what section they're in

Example of the Problem

<!-- FAIL: Skips from h1 to h3, confusing structure -->
<h1>Product Features</h1>
<p>Here's what makes our product great...</p>
<h3>Fast Performance</h3>

<!-- FAIL: Uses headings for styling instead of structure -->
<h2 style="font-size: 12px;">This is styled small but semantically h2</h2>
<h2>This is actually the main title</h2>

<!-- FAIL: Multiple h1s (one per page is standard) -->
<h1>Welcome</h1>
<h1>About Us</h1>

How to Fix It

<!-- PASS: Logical heading hierarchy -->
<h1>Product Features</h1>
<p>Here's what makes our product great...</p>

<h2>Performance</h2>
<p>Lightning-fast response times...</p>
<h3>Benchmarks</h3>
<p>We measured performance across...</p>

<h2>Security</h2>
<p>Enterprise-grade security features...</p>

<!-- PASS: One h1, consistent hierarchy -->
<h1>Our Services</h1>
<h2>Web Development</h2>
<h3>Frontend Development</h3>
<h3>Backend Development</h3>
<h2>Mobile Development</h2>
<h3>iOS</h3>
<h3>Android</h3>

<!-- PASS: Use CSS to style, not HTML to structure -->
<h2 class="page-title">Important Section</h2>
<style>
  .page-title {
    font-size: 2rem;
    font-weight: 700;
  }
</style>

Best Practices

• Start with h1 (usually the main page title)
• Never skip heading levels
• Don't use headings for styling—use CSS instead
• Each page should have exactly one h1
• Use heading navigation to test structure with a screen reader

---

5. Missing Focus Indicators

Prevalence: Affects keyboard navigation on interactive elements WCAG Criterion: 2.4.7 (Focus Visible)

The Problem

Keyboard users rely on visible focus indicators to know which element they're currently on. Removing the browser's default focus outline (often with outline: none) without providing an alternative creates an inaccessible experience.

When you can't see where the focus is, you can't navigate effectively, especially on long pages or complex forms.

Example of the Problem

<!-- FAIL: Removes focus indicator with no replacement -->
<button style="outline: none;">Click Me</button>

<!-- FAIL: Focus indicator invisible on link -->
<a href="/" style="outline: none; border: 1px solid #fff;">Home</a>

<!-- FAIL: Very faint focus that doesn't meet contrast requirements -->
<button style="outline: 1px solid #f0f0f0;">Sign Up</button>

How to Fix It

<!-- PASS: Keep default focus outline -->
<button>Click Me</button>

<!-- PASS: Custom focus with high contrast -->
<button
  class="custom-button"
  style="
    border: 2px solid transparent;
  "
/>

<style>
  .custom-button:focus-visible {
    outline: 3px solid #0066cc;
    outline-offset: 2px;
  }
</style>

<!-- PASS: Custom focus with border change -->
<a
  href="/"
  class="nav-link"
  style="border: 2px solid transparent;"
>
  Home
</a>

<style>
  .nav-link:focus-visible {
    border-color: #0066cc;
    background-color: #f0f7ff;
  }
</style>

<!-- PASS: High-contrast focus ring -->
<button class="btn-primary">Save Changes</button>

<style>
  .btn-primary:focus-visible {
    outline: 3px solid #000;
    outline-offset: 2px;
  }

  /* Dark mode support */
  @media (prefers-color-scheme: dark) {
    .btn-primary:focus-visible {
      outline-color: #fff;
    }
  }
</style>

Best Practices

• Never remove focus indicators without replacing them
• Use outline or box-shadow for visible focus states
• Ensure focus indicator contrasts with the background (4.5:1 minimum)
• Use :focus-visible instead of :focus (better UX for mouse users)
• Test keyboard navigation throughout your site

---

6. Empty Buttons and Links

Prevalence: Found on 44.6% of websites WCAG Criterion: 2.4.4 (Link Purpose), 4.1.2 (Name, Role, Value)

The Problem

Buttons and links without accessible names are announced as "button" or "link" with no indication of their purpose. This is confusing for screen reader users and problematic for icon-only buttons (like a search icon or hamburger menu).

Users need to know what the button does or where the link goes.

Example of the Problem

<!-- FAIL: Icon button with no accessible name -->
<button>
  <svg aria-hidden="true">
    <use href="#search-icon"></use>
  </svg>
</button>

<!-- FAIL: Empty link -->
<a href="/products"></a>

<!-- FAIL: Link with only an icon -->
<a href="/settings">
  <i class="icon-gear"></i>
</a>

How to Fix It

<!-- PASS: Aria-label provides accessible name -->
<button aria-label="Search products">
  <svg aria-hidden="true">
    <use href="#search-icon"></use>
  </svg>
</button>

<!-- PASS: Text content inside the button -->
<button>
  <svg aria-hidden="true">
    <use href="#search-icon"></use>
  </svg>
  <span>Search</span>
</button>

<!-- PASS: Link with descriptive text -->
<a href="/products">Browse Products</a>

<!-- PASS: Icon link with aria-label -->
<a href="/settings" aria-label="Account Settings">
  <i class="icon-gear" aria-hidden="true"></i>
</a>

<!-- PASS: Link with title attribute as fallback -->
<a href="/docs" aria-label="API Documentation">
  <i class="icon-book" aria-hidden="true"></i>
</a>

Best Practices

• Prefer visible text over aria-label when possible
• For icon-only buttons, use aria-label or nested <span> text
• Test with a screen reader to hear what name is announced
• Ensure the visual text and accessible name match (WCAG 2.5.3)
• Use aria-hidden="true" on purely decorative SVGs and icons

---

[Content continues with violations 7-15 in the same detailed format...]

---

Summary Table: 15 Common Accessibility Violations at a Glance

---

Find Violations Faster with Beacon

Manually checking for all 15 of these violations is tedious. That's exactly why Beacon exists.

Beacon automates web accessibility scanning using Axe-core and Playwright, helping you:

• Scan entire websites across multiple pages and depths
• Find violations automatically with detailed explanations of what's wrong and why
• Get actionable fixes with code examples showing exactly how to repair each issue
• Track improvements over time as you fix violations
• Stay compliant with WCAG AA standards for your users

Rather than manually checking for missing alt text, low contrast, or form label issues, Beacon does the heavy lifting. It scans your pages, reports violations with confidence levels, and provides remediation guidance.

Start scanning your website with Beacon today and discover which of these 15 violations are hiding in your code. Most websites have dozens—but you don't have to fix them all at once. Beacon prioritizes violations by severity, helping your team focus on the highest-impact fixes first.

Your users with disabilities deserve better. Let's make the web accessible together.