10 WCAG Issues Behind ADA Website Lawsuits (& How to Fix)

The ten failures the Department of Justice's web guidance and the WebAIM Million both point at, with the WCAG criterion and the fix for each.

Published

ADA web accessibility complaints keep landing on the same short list of failures. The US Department of Justice's guidance on web accessibility and the ADA names the barriers it puts first: poor color contrast, using color alone to carry information, missing text alternatives on images, videos without captions, inaccessible online forms and pages that only work with a mouse.

The prevalence data points the same way. The 2026 WebAIM Million, an automated analysis of the top one million home pages, found detected WCAG 2 failures on 95.9% of them, an average of 56.1 errors per page, and reports that 96% of all detected errors fall into six categories: low contrast text, missing alternative text, missing form input labels, empty links, empty buttons and missing document language.

This guide takes the ten failures those two sources point at, says what each one breaks for real users, and gives you the fix. One caveat from WebAIM's own method note, which applies to every scanner including ours: automated tools cannot detect every failure, and the absence of detected errors does not mean a page is accessible or conformant. These ten are where to start, not where to stop. You can also read the background in our post on ADA website lawsuits.

1. Missing or Inadequate Image Alt Text

The screnshot from AccessGuard showing error missing alt text

WCAG Criterion: 1.1.1 (Non-text Content)
The 2026 WebAIM Million found images missing alternative text on 53.1% of the home pages it analyzed. When images lack descriptive alt text, screen reader users have no way to understand what the image shows. For e-commerce sites, this means blind customers literally cannot see your products.
What goes wrong:
  • Images with no alt attribute at all
  • Placeholder alt text like "image" or "IMG_1234.jpg"
  • Decorative images that aren't marked as decorative
How to fix it:
For informative images, write a concise description of what the image shows:
HTML
<!-- Bad -->
<img src="hero.jpg">
<img src="product-42.jpg" alt="image">

<!-- Good -->
<img src="hero.jpg" alt="Team collaborating around a whiteboard in a modern office">
<img src="product-42.jpg" alt="Navy blue wool overcoat, front view, with brass buttons">
For decorative images that don't convey information, use an empty alt attribute so screen readers skip them:

Pro tip: If you have hundreds of product images that need alt text, AccessGuard's AltWizard feature generates SEO-friendly descriptions using AI. You can drag and drop up to 10 images at a time.


2. Insufficient Color Contrast

WCAG Criterion: 1.4.3 (Contrast Minimum)
Low contrast text was found on 83.9% of the top one million home pages in the 2026 WebAIM Million, up from 79.1% the year before. It was the most commonly detected issue in that analysis, and it is one of the easiest to fix.
The requirements:
  • Normal text: minimum 4.5:1 contrast ratio
  • Large text (18pt+ or 14pt bold): minimum 3:1 contrast ratio
  • UI components and graphics: minimum 3:1 contrast ratio

Common offenders:
  • Light gray text on white backgrounds
  • Text placed over images or gradients without an overlay
  • Placeholder text in form fields
  • Links that aren't visually distinct enough from body text

How to fix it:
Test your color combinations using a contrast checker. Then update your CSS:
CSS
/* Bad: ratio 2.5:1, fails WCAG AA */
.subtitle {
 color: #999999;
 background: #ffffff;
}

/* Good: ratio 7.0:1, passes WCAG AAA */
.subtitle {
 color: #595959;
 background: #ffffff;
}
For text over images, add a semi-transparent overlay:
CSS
.hero-text-overlay {
 background: rgba(0, 0, 0, 0.6);
 padding: 1rem 2rem;
}
 

3. Missing Form Labels

WCAG Criterion: 1.3.1 (Info and Relationships), 4.1.2 (Name, Role, Value)
Missing form input labels were found on 51% of home pages in the 2026 WebAIM Million. Checkout, registration and search fields are the usual offenders.
What goes wrong:
  • Input fields that rely on placeholder text instead of <label> elements
  • Labels that aren't programmatically associated with their input
  • Error messages that don't identify which field has the problem
How to fix it:
HTML
<!-- Bad: placeholder is NOT a label replacement -->
<input type="email" placeholder="Enter your email">

<!-- Good: visible label associated with input -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" placeholder="[email protected]">
For error handling, be specific about what went wrong:
HTML
<!-- Bad -->
<p class="error">There was an error.</p>

<!-- Good -->
<p class="error" role="alert">Please enter a valid email address in the Email field.</p>


4. Keyboard Navigation Issues

WCAG Criterion: 2.1.1 (Keyboard)
Users with motor disabilities often navigate entirely with a keyboard. If your site requires a mouse for essential functions, like opening dropdown menus, clicking modal buttons, or navigating carousels, those users are locked out.
What goes wrong:
  • Interactive elements that only respond to mouse clicks
  • Missing or invisible focus indicators
  • Custom components (dropdowns, modals, tabs) that trap keyboard focus
  • Skip-to-content links that are missing or non-functional

How to fix it:
Make sure all interactive elements are focusable and operable:
HTML
<!-- Bad: div acting as button, not keyboard accessible -->
<div class="btn" onclick="submit()">Submit</div>

<!-- Good: native button element, keyboard accessible by default -->
<button type="submit" class="btn">Submit</button>
Never remove the focus outline without providing an alternative:
CSS
/* Bad: removes focus indicator entirely */
*:focus { outline: none; }

/* Good: custom focus style that's still visible */
*:focus-visible {
 outline: 2px solid #0066cc;
 outline-offset: 2px;
}
Add a skip navigation link as the first focusable element:
HTML
<a href="#main-content" class="skip-link">Skip to main content</a>


5. Missing Document Language

WCAG Criterion: 3.1.1 (Language of Page)
The 2026 WebAIM Million found a missing document language on 13.5% of home pages. Screen readers use the language attribute to determine pronunciation rules. Without it, a German screen reader might try to pronounce English text phonetically, or vice versa. It's a one-line fix that many sites miss.
How to fix it:
HTML
<!-- Add the lang attribute to your html element --><html lang="en"><!-- For multilingual pages, mark sections in different languages --><p>The French word for hello is <span lang="fr">bonjour</span>.</p>


6. Empty or Non-Descriptive Links

WCAG Criterion: 2.4.4 (Link Purpose)
Empty links were found on 46.3% of home pages in the 2026 WebAIM Million. Links that say "click here" or "read more" tell a screen reader user nothing about where the link goes. When a blind user pulls up a list of all links on a page (a common screen reader feature), they get a list of 15 identical "click here" links.

How to fix it:
HTML
<!-- Bad -->
<a href="/report">Click here</a>
<a href="/pricing">Read more</a>

<!-- Good -->
<a href="/report">Download the 2025 accessibility report</a>
<a href="/pricing">View pricing plans</a>
For icon-only links (like social media icons), add descriptive text that's visually hidden but available to screen readers:
HTML
<a href="https://twitter.com/yourhandle">
 <svg aria-hidden="true"><!-- twitter icon --></svg>
 <span class="sr-only">Follow us on Twitter</span>
</a>


7. Improper Heading Hierarchy

WCAG Criterion: 1.3.1 (Info and Relationships)
The 2026 WebAIM Million found skipped heading levels on 41.8% of pages. Screen reader users navigate pages by headings the way sighted users scan visually. If your headings skip levels (jumping from H1 to H4) or are used purely for styling, the page structure makes no sense to assistive technology.

How to fix it:
HTML
<!-- Bad: skips levels, used for styling --><h1>Our Products</h1><h4>Running Shoes</h4> <!-- Skipped h2 and h3 --><h2>About Us</h2><!-- Good: logical hierarchy --><h1>Our Products</h1> <h2>Running Shoes</h2> <h3>Men's Running Shoes</h3> <h3>Women's Running Shoes</h3> <h2>Hiking Boots</h2>
The rule is simple: never skip heading levels, and never use headings just to make text bigger. Use CSS for styling, headings for structure.

8. Missing ARIA Attributes on Custom Components

WCAG Criterion: 4.1.2 (Name, Role, Value)
When you build custom UI components (accordions, tabs, modal dialogs, dropdown menus), browsers and screen readers don't automatically know what these elements are or how they behave. ARIA attributes bridge that gap.
How to fix it:
For a custom accordion:
HTML
<button aria-expanded="false" aria-controls="section1">
 Shipping Information
</button>
<div id="section1" role="region" aria-hidden="true">
 <p>We ship within 3-5 business days...</p>
</div>
For modal dialogs:
HTML
<div role="dialog" aria-modal="true" aria-labelledby="dialog-title">
 <h2 id="dialog-title">Confirm your order</h2>
 <!-- dialog content -->
</div>
Important rule: only use ARIA when native HTML elements don't provide the semantics you need. A <button> is always better than a <div role="button">.


9. Missing Video Captions and Audio Descriptions

WCAG Criterion: 1.2.2 (Captions), 1.2.3 (Audio Description)
If your site includes video content, product demos, promotional videos, tutorials, they need captions for deaf and hard-of-hearing users. Auto-generated captions from YouTube are a start, but they're often inaccurate and don't meet the standard.
How to fix it:
  • Add accurate, synchronized captions to all video content
  • Provide transcripts for audio-only content (podcasts, audio guides)
  • Review auto-generated captions for accuracy, they frequently mangle proper nouns, technical terms, and accented speech
  • For pre-recorded video, provide audio descriptions for important visual information that isn't conveyed through dialogue


10. Insufficient Touch Target Size

WCAG Criterion: 2.5.8 (Target Size Minimum)
This is one of the criteria added in WCAG 2.2, covered in our WCAG 2.2 breakdown. Small buttons and links, especially on mobile, are difficult for users with motor impairments to tap accurately.
The requirement: Interactive targets should be at least 24×24 CSS pixels, with adequate spacing between adjacent targets.
How to fix it:
CSS
/* Ensure buttons and links meet minimum target size */
button, a, input[type="checkbox"], input[type="radio"] {
 min-width: 44px;
 min-height: 44px;
}

/* Add padding to small inline links */
nav a {
 padding: 0.5rem 1rem;
 display: inline-block;
}


How to Check If Your Site Has These Issues

You can manually audit every page against these 10 criteria, but for most businesses that's not practical. Here's a faster approach:
  1. Run a structured accessibility audit to catch the machine-detectable issues (alt text, color contrast, form labels, heading structure). Treat the result as a starting list, not a verdict: automated checks find many problems but cannot confirm conformance.
  2. Test with a keyboard, unplug your mouse and try to navigate your entire site using only Tab, Enter, and Escape. If you get stuck anywhere, your keyboard users will too.
  3. Test with a screen reader, turn on VoiceOver (Mac) or NVDA (Windows, free) and try to complete a key task on your site, like making a purchase or filling out a contact form.
Or scan the page with AccessGuard. It runs automated WCAG 2.2 AA checks in a real browser, groups what it finds by severity and success criterion, writes suggested fixes on paid plans, and puts the report under your agency's name. It cannot tell you a site conforms, because no tool can, but it takes the machine-detectable list off your plate so your time goes on the keyboard and screen reader passes.

Start with a free accessibility scan. New accounts include 3 scan credits, and no card is needed.

The Bottom Line

These ten cover the barriers the DOJ names and the failures WebAIM finds most often, which makes them the cheapest place to start. Most are straightforward, and a few are a one-line change. Fixing them early costs a fraction of fixing them under a complaint, and every one of them removes a real barrier for someone.

There is a second reason to move on them. The European Accessibility Act has applied to products and services placed on the market since 28 June 2025, covering e-commerce, consumer banking, e-books and more (European Commission), so client sites selling into the EU are in scope. Nobody can certify a site compliant. What you can do for a client is show which requirements their site meets, which it does not, and what it takes to close the gap.

AccessGuard runs automated WCAG 2.2 AA checks in a real browser and writes suggested fixes on paid plans. Start your free scan →

Check a client site for this

Audit any page against WCAG 2.2 AA for free and see every finding in about 30 seconds.

Run a free audit