Most Common WCAG Violations (With Code Fixes for Each)

Originally published at AccessGuard.

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 2026 report, 95.9% of home pages had detected WCAG 2 failures, at an average of 56.1 errors per page, and 96% of all detected errors fell into just six categories: low contrast text, missing alt text, missing form input labels, empty links, empty buttons and missing document language. That means a handful of common problems account for nearly all of what an automated scan will find. It also means the count went the wrong way this year: WebAIM records a 10.1% rise in detected errors per page since its 2025 analysis.

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 2026 WebAIM Million found it on 83.9% of home pages, which makes it the single most common failure type.

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, it fails against white at 2.85:1. Darkening it to #2B6CA3 gives 5.56:1, which clears 4.5:1 with room to spare and keeps the same feel. Our color contrast checker explains how the ratio is calculated, and meeting AA without killing the design covers the palette work in more detail.

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 2026 WebAIM Million found it missing on 13.5% 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? Four of the five are Level A failures, the most basic tier of WCAG, and low contrast is Level AA. They are also all straightforward to fix, often needing a single line of HTML. For the ones that need more than that, accessible forms and how to write alt text go deeper.

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 audit every page by hand, but on a growing site that stops being practical. AccessGuard runs automated WCAG 2.2 AA checks in a real browser and flags every instance of these common problems and many more. You can try it on any page with a free accessibility scan.

Each issue in the report names the WCAG criterion it fails, its severity, and the exact element on the page. On paid plans it also writes the fix. Reports go out white-labelled under your agency's name, and every client site sits in one account so you can see what broke and what got fixed since the last scan.

What a scan cannot do is tell you the site conforms. Automated checks find many real problems, and whether alt text is accurate, whether focus order makes sense in a real flow and whether an error message actually helps still need a person. The check pages set out what each test covers, for example the alt text checker and the form labels checker, and the accessibility audit checklist covers the manual steps that go around the scan.