Common WCAG 2.2 Mistakes and How to Fix Them

Published Feb 14, 2026 5 min read

WCAG 2.2 introduced new success criteria and refined existing ones, but even experienced dev teams keep making the same mistakes over and over. I've analyzed thousands of accessibility scans, and I'll walk you through the 10 most frequent violations I see, each mapped to specific success criteria with code examples showing you exactly how to fix them.

The 10 Mistakes

WCAG 2.2 vs. Earlier Versions

WCAG 2.2 added 9 new success criteria on top of WCAG 2.1. I'm covering both the long-standing violations and the newer 2.2-specific requirements, like Target Size (SC 2.5.8) and Consistent Help (SC 3.2.6), that most sites haven't addressed yet. New to WCAG entirely? Start with my beginner-friendly explanation of what WCAG is before diving into the specifics here. If you want a broader overview of common pitfalls, check out my top 10 accessibility mistakes resource.

#1: Missing Alternative Text Critical

SC 1.1.1 Non-text Content (Level A)

This is the #1 violation I see in scan after scan: images without alt attributes. When a screen reader hits one of these, it either skips the image entirely or reads out the file name, which is completely meaningless to the user.

The tricky part isn't adding alt text. It's writing good alt text. I see a lot of sites where every image gets alt="image" or alt="photo", which technically passes automated checks but gives screen reader users almost nothing to work with. A product photo should describe the product. A chart should summarize the data. A team photo should say who's in it.

Fix

<!-- Bad -->
<img src="chart-q4.png">

<!-- Good: descriptive alt -->
<img src="chart-q4.png" alt="Q4 revenue chart showing 23% growth">

<!-- Good: decorative image -->
<img src="divider.png" alt="">

For detailed guidance, read our complete alt text guide or check out how to write effective alt text for a step-by-step walkthrough.

#2: Insufficient Color Contrast Serious

SC 1.4.3 Contrast Minimum (Level AA)

You'd be surprised how often this one shows up. If your text doesn't hit the 4.5:1 ratio for normal text (or 3:1 for large text), it fails. The most common offender I see? Light gray body text (#999) on white backgrounds. That only gets you 2.85:1.

Fix

/* Bad: 2.85:1 ratio */
.text-muted { color: #999999; }

/* Good: 4.54:1 ratio */
.text-muted { color: #767676; }

See our full color contrast fix guide and contrast reference.

#3: Missing Form Labels Critical

SC 1.3.1 Info and Relationships (Level A) / SC 3.3.2 Labels or Instructions (Level A)

If your form inputs don't have associated <label> elements, screen readers just announce them as "edit text," which tells the user absolutely nothing. And no, placeholder text doesn't count as a label. It disappears the moment someone starts typing and isn't reliably announced.

I've seen this mistake most often on login forms, newsletter signups, and search bars. Developers rely on the visual layout to make the purpose obvious, but that context is invisible to someone using a screen reader. The fix takes about 30 seconds per field, and I've put together a full guide on fixing missing form labels if you want the details on every approach (including aria-label and aria-labelledby for trickier cases).

Fix

<!-- Bad: no label, only placeholder -->
<input type="email" placeholder="Email">

<!-- Good: proper label -->
<label for="email">Email address</label>
<input type="email" id="email" name="email">

#4: No Visible Focus Indicator Serious

SC 2.4.7 Focus Visible (Level AA) / SC 2.4.13 Focus Appearance (Level AAA, new in 2.2)

This one drives me crazy. CSS rules like outline: none strip away the browser's default focus ring without giving users anything in return. And WCAG 2.2's new SC 2.4.13 raises the bar even further, defining minimum size and contrast requirements for focus indicators at Level AAA.

Fix

/* Bad */
*:focus { outline: none; }

/* Good: visible on keyboard, hidden on mouse */
:focus-visible {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
}

#5: Missing Page Language Moderate

SC 3.1.1 Language of Page (Level A)

This is one of the simplest fixes on the entire list, yet I still see it constantly. Without a lang attribute on your <html> element, screen readers have to guess the language, and they often guess wrong, which means garbled pronunciation for your users.

Fix

<html lang="en">

#6: Empty Links and Buttons Serious

SC 4.1.2 Name, Role, Value (Level A)

If you've got links or buttons that are just icons, like an SVG or image with no text and no aria-label, screen readers will announce them as "link" or "button" with zero indication of what they actually do.

Fix

<!-- Bad: icon-only, no accessible name -->
<a href="/cart"><svg>...</svg></a>

<!-- Good: aria-label -->
<a href="/cart" aria-label="Shopping cart (3 items)">
  <svg aria-hidden="true">...</svg>
</a>

<!-- Also good: visually hidden text -->
<a href="/cart">
  <svg aria-hidden="true">...</svg>
  <span class="visually-hidden">Shopping cart</span>
</a>

#7: Broken Heading Hierarchy Moderate

SC 1.3.1 Info and Relationships (Level A)

Jumping from an H1 straight to an H3, or using headings just because you want bigger text. This breaks the document outline that screen reader users depend on for navigation. Think of headings as a table of contents, not a styling tool.

Fix

<!-- Bad: skips H2 -->
<h1>Page Title</h1>
<h3>Section</h3>

<!-- Good: sequential levels -->
<h1>Page Title</h1>
<h2>Section</h2>
<h3>Subsection</h3>

#8: Missing Skip Navigation Moderate

SC 2.4.1 Bypass Blocks (Level A)

Imagine having to tab through every single navigation link on every page just to reach the content. That's what keyboard users deal with if you don't have a skip link. On sites with large menus, that's dozens of tab presses before they can read anything.

Fix

<body>
  <a href="#main-content" class="skip-link">
    Skip to main content
  </a>
  <header>...</header>
  <main id="main-content">...</main>
</body>

#9: Touch Targets Too Small Moderate

SC 2.5.8 Target Size (Minimum) (Level AA, new in WCAG 2.2)

This is a new WCAG 2.2 requirement, and a lot of sites aren't ready for it. Your interactive targets need to be at least 24×24 CSS pixels, or have enough spacing from adjacent targets. If you've got small links crammed together, they'll fail this criterion, and they're genuinely difficult for users with motor impairments to tap.

Fix

/* Ensure minimum 24x24px target size */
button, a, input, select {
  min-height: 24px;
  min-width: 24px;
}

/* Better: comfortable 44px for touch */
.nav a {
  padding: 10px 16px;  /* results in ~40px+ height */
}

#10: Inconsistent Help Location Moderate

SC 3.2.6 Consistent Help (Level A, new in WCAG 2.2)

Another new WCAG 2.2 criterion that catches people off guard. If your site has help mechanisms (contact info, a chat widget, an FAQ link), they need to appear in the same relative location on every page. If your support link is in the header on one page and the footer on another, that's a violation.

Fix

Place help mechanisms consistently:

  • Keep contact/support links in the same position in the header or footer on every page
  • If using a chat widget, ensure it appears in the same corner on all pages
  • FAQ and help links should be in the same navigation position site-wide

Scan Your Site for These Mistakes

Ready to see how your site stacks up? Run a free accessibility scan and I'll detect most of these WCAG 2.2 violations automatically: missing alt text, contrast failures, form label issues, heading problems, and more. If you want the full compliance picture, check out my ADA compliance checklist, or dive into how to fix color contrast specifically.

Find WCAG 2.2 Violations on Your Site

Run a free scan and I'll give you a detailed report with every issue and how to fix it.

Run Free Scan More Articles