How to Fix the 5 Most Common WCAG Errors (With Code Examples)

96% of websites fail WCAG compliance. If you have ever run an accessibility scan and felt overwhelmed by the results, you are not alone. The good news: a small number of error types account for the vast majority of violations, and most of them are straightforward to fix.

We analyzed scan data from thousands of pages checked through PageAuditors and identified the five WCAG violations that appear most frequently. This guide shows you exactly what each error means, why it matters, and how to fix it with real code examples.

1. Insufficient Color Contrast (WCAG 1.4.3)

The most common violation we find. Color contrast failures appear on nearly every website we scan. The rule is simple: text must have enough contrast against its background so that people with low vision or color blindness can read it.

The Standard

WCAG 1.4.3 "Contrast (Minimum)" requires:

• Normal text: contrast ratio of at least 4.5:1
• Large text (18pt / 24px, or 14pt / 18.66px if bold): contrast ratio of at least 3:1

This is a Level AA requirement, meaning it is part of the baseline that courts and regulators expect you to meet.

Before (Failing)

<p style="color: #999999; background-color: #ffffff;">
  This light gray text on white has a contrast ratio of 2.85:1
</p>

<a href="/pricing" style="color: #7ab8f5;">
  View pricing
</a>

After (Passing)

<p style="color: #595959; background-color: #ffffff;">
  This darker gray on white has a contrast ratio of 7:1
</p>

<a href="/pricing" style="color: #2563eb;">
  View pricing
</a>

How to Fix It

1. Use a contrast checker tool to test your color combinations
2. Update your CSS color values to meet the 4.5:1 ratio for body text
3. Pay special attention to placeholder text, disabled states, and links, which designers often style with low contrast
4. If your brand colors fail contrast, adjust the shade slightly rather than changing the brand entirely

Common trap: Gray text on white backgrounds. Designers love light gray for a "clean" look, but #999 on #fff fails at 2.85:1. Bump it to #595959 or darker.

2. Links Without Discernible Text (WCAG 2.4.4)

Links that have no accessible name are invisible to screen reader users. This happens most often with icon-only links, image links missing alt text, and empty anchor tags.

The Standard

WCAG 2.4.4 "Link Purpose (In Context)" is a Level A requirement. Every link must have text that describes where it goes, either through visible text, an aria-label, or alt text on a linked image.

Before (Failing)

<!-- Icon-only link with no text -->
<a href="/settings">
  <svg class="icon-gear" />
</a>

<!-- Image link with no alt -->
<a href="https://twitter.com/pageauditors">
  <img src="/twitter-icon.png" />
</a>

<!-- Empty link -->
<a href="/dashboard"></a>

After (Passing)

<!-- Add aria-label for icon-only links -->
<a href="/settings" aria-label="Settings">
  <svg class="icon-gear" aria-hidden="true" />
</a>

<!-- Add alt text to linked images -->
<a href="https://twitter.com/pageauditors">
  <img src="/twitter-icon.png" alt="PageAuditors on Twitter" />
</a>

<!-- Add visible or screen-reader text -->
<a href="/dashboard">
  <span class="sr-only">Go to dashboard</span>
</a>

How to Fix It

1. Search your HTML for <a> tags that contain only icons, images, or are empty
2. Add aria-label to icon-only links (and aria-hidden="true" on the decorative icon)
3. Add meaningful alt text to any <img> inside a link
4. Use a .sr-only CSS class (visually hidden, screen-reader accessible) when you need invisible text

3. Small Touch Targets (WCAG 2.5.8)

Buttons and links that are too small to tap reliably affect everyone, but especially users with motor impairments, tremors, or who use assistive pointing devices. This is a newer criterion added in WCAG 2.2.

The Standard

WCAG 2.5.8 "Target Size (Minimum)" requires interactive elements to be at least 24 by 24 CSS pixels, or to have sufficient spacing from adjacent targets. This is Level AA in WCAG 2.2 (released October 2023).

While courts currently reference WCAG 2.1 AA for legal compliance, WCAG 2.2 criteria are increasingly cited in accessibility audits and will likely become the new baseline.

Before (Failing)

.inline-link {
  /* Small text link with no padding */
  font-size: 12px;
  padding: 0;
}

.icon-button {
  width: 16px;
  height: 16px;
}

After (Passing)

.inline-link {
  font-size: 12px;
  padding: 6px 0; /* Increases clickable area to 24px+ height */
  display: inline-block;
}

.icon-button {
  width: 24px;
  height: 24px;
  min-width: 24px;
  min-height: 24px;
}

How to Fix It

1. Set min-width and min-height of 24px on all interactive elements (buttons, links, inputs)
2. For inline text links, add vertical padding to expand the clickable area
3. Ensure spacing between adjacent targets is sufficient (if you cannot make the target 24px, leave at least 24px of gap between it and neighboring interactive elements)
4. Navigation menus and footer link lists are the most common offenders

4. Images Missing Alt Text (WCAG 1.1.1)

Missing alt text is the classic accessibility violation, and it is still one of the most frequent. Every meaningful image needs alternative text so screen readers can describe it. Without it, users hear nothing or hear the raw filename.

The Standard

WCAG 1.1.1 "Non-text Content" is a Level A requirement. Every <img> element must have an alt attribute. Meaningful images need descriptive text. Decorative images need an empty alt="" so screen readers skip them.

Before (Failing)

<!-- No alt attribute at all -->
<img src="/team-photo.jpg" />

<!-- Alt with just the filename -->
<img src="/hero-banner.png" alt="hero-banner.png" />

<!-- Decorative image missing empty alt -->
<img src="/divider-line.svg" />

After (Passing)

<!-- Descriptive alt for meaningful images -->
<img src="/team-photo.jpg" alt="The PageAuditors team at our New York office" />

<!-- Descriptive, not filename-based -->
<img src="/hero-banner.png" alt="Website accessibility scanner showing a compliance score of 94" />

<!-- Empty alt for decorative images -->
<img src="/divider-line.svg" alt="" />

How to Fix It

1. Run a scan to find every <img> missing an alt attribute
2. For each meaningful image, write alt text that describes what the image communicates (not what it looks like)
3. For decorative images (dividers, background shapes, spacers), add alt=""
4. Avoid generic alt text like "image," "photo," or "icon." Be specific.
5. Keep alt text under 125 characters. For complex images (charts, infographics), use a longer description via aria-describedby

5. Missing Page Language (WCAG 3.1.1)

This is the easiest fix on the list and one of the most commonly missed. Without a lang attribute on the <html> element, screen readers do not know what language to use for pronunciation. A French screen reader trying to read English text (or vice versa) produces gibberish.

The Standard

WCAG 3.1.1 "Language of Page" is a Level A requirement. The <html> element must declare the primary language of the page using a valid language code.

Before (Failing)

<!DOCTYPE html>
<html>
  <head>
    <title>My Website</title>
  </head>
</html>

After (Passing)

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>My Website</title>
  </head>
</html>

How to Fix It

1. Add lang="en" (or the appropriate language code) to your <html> tag
2. If you use a framework like Next.js, check your root layout or _document file
3. For multilingual sites, set the lang attribute dynamically based on the current locale
4. This is a one-line fix that affects your entire site

In Next.js App Router:

// src/app/layout.tsx
export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  );
}

What to Do Next

These five errors account for the majority of WCAG violations on most websites. Fixing them does not require a complete redesign. It requires knowing where the problems are and making targeted changes.

Here is a practical approach:

1. Scan your site to get a complete list of violations with their exact locations
2. Fix critical and serious issues first (missing alt text, contrast failures, missing link text)
3. Re-scan after each batch of fixes to verify the changes worked and catch any regressions
4. Set up recurring scans to catch new violations as your site changes

Every violation you fix is one fewer risk in an ADA lawsuit and one more user who can actually use your website.

Run a Free Scan Now

Want to see exactly which of these errors appear on your site? PageAuditors scans your pages against WCAG 2.1 AA and 2.2 criteria, highlights every violation with its location in the DOM, and gives you plain-English fix guidance.

No signup required. Results in under 30 seconds.