Most Common WCAG Violations (With Code Fixes for Each)

The same issues keep showing up

Every year, the WebAIM Million study analyzes the top one million websites for accessibility. And every year, the results tell a remarkably consistent story: a small set of issues accounts for the vast majority of failures.

In the 2024 report, 95.9% of home pages had detectable WCAG failures. But here's the thing - the top five error types alone accounted for over 95% of all issues found. That means fixing just a handful of common problems can dramatically improve your site's accessibility.

This post walks through the most common accessibility issues found in real-world scans, explains why each one matters, and gives you the exact code to fix it.

1. Missing image alt text

Why it matters

When an image lacks alt text, screen reader users hear something like "image" or the file name - "DSC_0492.jpg" - which conveys no meaning. For users who rely on screen readers, images without alt text are invisible at best and confusing at worst.

Missing alt text violates WCAG 1.1.1 Non-text Content (Level A), the most fundamental accessibility requirement.

How to fix it

Every image needs an alt attribute. What you put in it depends on the image's purpose:

Informational images - describe what the image conveys:

<img src="team-photo.jpg" alt="The AccessGuard team at our 2024 company retreat">

Functional images (like icons inside links or buttons) - describe the action:

<a href="/search"><img src="search-icon.svg" alt="Search"></a>

Decorative images that add no information - use an empty alt attribute so screen readers skip them entirely:

<img src="decorative-swoosh.svg" alt="">

The key principle: alt text should convey the purpose of the image, not just describe its appearance. "Photo of a woman" is rarely useful. "CEO Maria Lopez presenting quarterly results" tells the user what they need to know.

2. Low color contrast

Why it matters

Low contrast text is difficult or impossible to read for people with low vision, color blindness, or anyone using a screen in bright sunlight. It's one of the most common accessibility failures - the WebAIM Million study consistently finds it on over 80% of home pages.

Low contrast violates WCAG 1.4.3 Contrast Minimum (Level AA).

The required ratios

WCAG defines minimum contrast ratios between text color and its background:

• Normal text (under 18pt, or under 14pt bold): minimum 4.5:1 ratio
• Large text (18pt+, or 14pt+ bold): minimum 3:1 ratio
• UI components and graphical objects: minimum 3:1 ratio

How to fix it

First, check your current contrast ratios. You can use browser DevTools - Chrome's color picker shows the contrast ratio directly. You can also use online tools like the WebAIM Contrast Checker.

Common problem areas to audit:

• Light gray text on white backgrounds - a frequent design choice that almost always fails. color: #767676 is the lightest gray that passes 4.5:1 against white
• Placeholder text in form fields - browser default placeholder color often fails contrast requirements
• Text overlaid on images - without a solid background or text shadow, contrast varies by the underlying image content
• Links that are only distinguished by color - if links aren't underlined, the color difference from surrounding text must meet a 3:1 ratio

When adjusting colors, you don't need to abandon your brand palette. Often, using a slightly darker shade of the same hue is enough to pass. For example, if your brand blue is #5B9FD6 (which fails against white at 2.8:1), darkening it to #2B6CA3 passes at 4.8:1 while keeping the same feel.

3. Missing form labels

Why it matters

When a form input doesn't have a properly associated label, screen reader users don't know what information to enter. They hear "edit text" with no context - is it asking for their name, email, or credit card number? This creates a guessing game that makes forms unusable.

Missing form labels violate WCAG 1.3.1 Info and Relationships (Level A) and WCAG 4.1.2 Name, Role, Value (Level A).

How to fix it

Every form input needs a programmatically associated label. The most reliable method is the <label> element with a for attribute that matches the input's id:

<label for="email">Email address</label>
<input type="email" id="email" name="email">

Alternatively, you can wrap the input inside the label:

<label>Email address <input type="email" name="email"></label>

Common mistakes to avoid

• Using placeholder as a label. Placeholder text disappears when the user starts typing, removing the only indication of what the field is for. It also typically fails contrast requirements. Always use a visible <label> in addition to any placeholder.
• Using aria-label instead of a visible label. While aria-label is announced by screen readers, sighted users who rely on the label for context (including people with cognitive disabilities) won't benefit. Prefer visible labels whenever possible.
• Forgetting labels on select, textarea, and checkbox elements. Every form control needs a label - not just text inputs.

4. Broken heading hierarchy

Why it matters

Headings aren't just visual formatting - they create a structural outline of your page. Screen reader users rely heavily on headings to navigate: most screen readers let users jump between headings with a single keystroke, and many users scan headings first to find the section they need, just like sighted users scan visual hierarchy.

Skipping heading levels (jumping from <h1> to <h4>) or using headings purely for styling (making something an <h3> because you want smaller bold text) breaks this navigation and violates WCAG 1.3.1 Info and Relationships (Level A).

How to fix it

Follow these rules for a correct heading structure:

• One <h1> per page - this should be the main topic or title of the page
• Don't skip levels - an <h2> should be followed by <h2> or <h3>, never <h4>
• Use headings for structure, not styling - if you want smaller bold text, use CSS instead of a lower heading level

A correct heading outline looks like this:

<h1>Page Title</h1>
  <h2>Main Section</h2>
    <h3>Subsection</h3>
    <h3>Subsection</h3>
  <h2>Another Main Section</h2>

Think of headings like a table of contents. If the outline doesn't make sense when listed on its own, your heading structure needs work.

5. Missing document language

Why it matters

When the <html> element doesn't include a lang attribute, screen readers don't know what language to use for pronunciation. A French screen reader user visiting an English page might hear English words pronounced with French phonetics - rendering the content incomprehensible.

This is arguably the easiest accessibility fix, yet the WebAIM Million study found it missing on nearly 18% of home pages. It violates WCAG 3.1.1 Language of Page (Level A).

How to fix it

Add a lang attribute to your <html> element:

<html lang="en">

Use the appropriate IETF language tag for your content's primary language. Common values include:

• en - English
• es - Spanish
• fr - French
• de - German
• zh - Chinese
• ja - Japanese

If your page contains sections in a different language, add a lang attribute to those sections as well:

<p>The French word <span lang="fr">accessibilité</span> translates to accessibility.</p>

This one-line fix takes seconds to implement and immediately helps every screen reader user who visits your site.

The pattern behind these issues

Notice something these five issues have in common? They're all Level A violations - the most basic tier of WCAG compliance. They're also all straightforward to fix, often requiring just a single line of HTML.

The gap between inaccessible and accessible isn't a chasm of complexity. It's a collection of small, fixable oversights - missing attributes, forgotten labels, unchecked contrast. The barrier to meaningful improvement is awareness, not difficulty.

How AccessGuard helps you find and fix these issues

You could manually audit every page for each of these issues - but with a growing site, that's impractical. AccessGuard scans your pages against WCAG 2.1 standards and flags every instance of these common problems (and many more).

Each issue in your scan report includes the specific WCAG criterion violated, the severity level, the exact element on the page, and an AI-powered fix suggestion. Instead of reading through WCAG documentation, you get a prioritized list of issues with code-level guidance on how to resolve each one.

Start a scan today and find out how many of these common issues exist on your site - and how quickly you can fix them.