The 5 WCAG Violations That Trigger 80% of ADA Demand Letters

If you spend an afternoon reading actual ADA Title III demand letters — we have read hundreds, filed publicly in court dockets — a pattern becomes impossible to miss. The same small handful of WCAG 2.2 violations appear in roughly 80% of them.

This is not a coincidence. Plaintiff law firms run automated WCAG scans against thousands of sites per week. The violations that are easiest for the scanner to confirm are also easiest to write into a complaint. A good attorney can draft a complete demand letter in under an hour if the scan output is clean. And these five violations are always at the top of that scan output.

If you eliminate all five from your site, you drop off the easy-target list. Here is what they are, why they matter, and how to fix each one correctly.

1. Images missing alt text (image-alt)

WCAG criterion: 1.1.1 Non-text Content (Level A)

This is the single most common violation in every demand letter we have read. An <img> element with no alt attribute, or with an empty alt="" on a meaningful image, means blind users have no idea what the image shows.

Why this ends up in complaints

It is deterministic. A scanner reports missing alt attribute on <img src="product-hero.jpg"> and an attorney has a named, citable violation. No judgment required. No argument available.

What wrong looks like

<img src="product-hero.jpg" />
<img src="buy-now-button.png" alt="" />
<img src="team-photo.jpg" alt="image" />

What right looks like

<!-- Informative image -->
<img src="product-hero.jpg"
     alt="Midnight blue men's running shoe with reflective laces, side view" />

<!-- Functional image (triggers an action) -->
<img src="buy-now-button.png" alt="Buy now — $89" />

<!-- Decorative image (purely visual, conveys no info) -->
<img src="divider-pattern.svg" alt="" role="presentation" />

The rule of thumb: if removing the image would change the meaning of the page for a sighted user, it needs descriptive alt text. If the page makes just as much sense without it, alt="" is correct.

2. Form fields without labels (label)

WCAG criterion: 3.3.2 Labels or Instructions (Level A), 4.1.2 Name, Role, Value (Level A)

The second most common violation. A form input without a programmatically associated label means a screen reader announces only "edit, blank" with no context. A user cannot fill out a form they cannot identify.

Why this ends up in complaints

Checkout forms, signup forms, and search boxes are the most commonly cited examples. Plaintiffs document specific steps: "the user could not complete step 3 of checkout because the 'Delivery Instructions' field had no accessible name."

What wrong looks like

<input type="text" placeholder="Email" />

<span>Email</span>
<input type="text" />

Placeholders are not labels. They disappear the moment the user starts typing and are not always announced by assistive technology.

What right looks like

<!-- Visible label (preferred) -->
<label for="email">Email address</label>
<input id="email" type="email" required />

<!-- Or using aria-labelledby -->
<span id="email-label">Email address</span>
<input type="email" aria-labelledby="email-label" />

<!-- Or using aria-label (when no visible label is possible, like a search icon button) -->
<input type="search" aria-label="Search products" />

Every single <input>, <select>, <textarea>, and form-associated custom element needs a name that screen readers can announce.

3. Insufficient color contrast (color-contrast)

WCAG criterion: 1.4.3 Contrast (Minimum) (Level AA)

Text against its background must have a contrast ratio of at least 4.5:1 for body text, or 3:1 for large text (18pt+ or 14pt+ bold). This is the violation that most often appears multiple times in a single complaint, because designers often pick a brand color and use it consistently throughout the site — including on backgrounds where it fails.

Why this ends up in complaints

Deterministic again. A scanner can mathematically compute the contrast ratio between two colors. The attorney does not need to see your brand guidelines, argue about aesthetics, or guess at intent. Ratio below 4.5:1 on body text = violation.

Common culprits

• Light gray text on white (#9CA3AF on #FFFFFF = 2.84:1 — fails)
• Brand green on white (#10B981 on #FFFFFF = 2.99:1 — fails)
• Any placeholder text style that inherits a light color
• Hover states that reduce opacity below threshold

The fix

For body text on white backgrounds, your darkest usable shade of most brand colors will be around #065f46 (for greens) or #1E40AF (for blues) — these pass 7:1 (AAA) comfortably. Anything lighter needs validation.

Tools you can use:

• color-contrast-checker npm package in CI
• WebAIM Contrast Checker during design
• Accesseon's free color-contrast checker (no signup)

4. Links without discernible text (link-name)

WCAG criterion: 2.4.4 Link Purpose (Level A)

A link whose visible text is only an icon, or only says "click here," or wraps only a non-text element without an accessible name, cannot be used by screen reader users navigating by links (k in most readers).

Why this ends up in complaints

Social media icons in footers are the number one source. A <a href="https://twitter.com/..."> wrapping only an SVG icon with no accessible name reads to the screen reader as "link" — the user has no idea where it goes. Plaintiffs specifically screenshot the footer of your site because they know the overlay did not fix this.

What wrong looks like

<a href="/products"><img src="arrow.svg" /></a>

<a href="https://twitter.com/example">
  <svg><!-- twitter icon --></svg>
</a>

<a href="/learn-more">click here</a>

What right looks like

<a href="/products" aria-label="View all products">
  <img src="arrow.svg" alt="" />
</a>

<a href="https://twitter.com/example" aria-label="Follow us on Twitter">
  <svg aria-hidden="true"><!-- twitter icon --></svg>
</a>

<!-- Or make the link text itself descriptive -->
<a href="/learn-more">Learn more about our accessibility approach</a>

5. Page structure: missing or skipped heading levels (heading-order + page-has-heading-one)

WCAG criterion: 1.3.1 Info and Relationships (Level A), 2.4.6 Headings and Labels (Level AA)

Screen reader users navigate pages by heading hierarchy. They jump with h to move between headings and use 1-6 to jump to specific heading levels. A page without an <h1>, or with an <h4> that appears before any <h3>, breaks this navigation model.

Why this ends up in complaints

This is subtler than the first four, but it appears in almost every complaint we have reviewed. Attorneys have started bundling it because it signals "this team did not think about semantics" — which supports their larger argument that the site is systematically inaccessible.

What wrong looks like

<div class="text-4xl font-bold">Our Products</div>  <!-- should be h1 -->

<h1>Home</h1>
<h4>Featured products</h4>   <!-- skipped h2 and h3 -->
<h2>Newsletter signup</h2>   <!-- now order is broken -->

What right looks like

<h1>Our Products</h1>

  <h2>Featured collections</h2>
    <h3>Men's running</h3>
    <h3>Women's running</h3>

  <h2>New arrivals</h2>

  <h2>Newsletter signup</h2>

There should be exactly one <h1> per page (the page's primary topic), and subsequent headings must not skip levels downward. You may jump back up (h3 → h2 is fine), but never h2 → h4.

The pattern, and why it matters for you

Every one of these five is:

1. Automatable to detect. A scanner catches it deterministically.
2. Easy to write into a complaint. No judgment or argument needed.
3. Trivial to fix. Usually a single-line HTML change per instance.
4. Rarely fixed by overlays. None of the major overlay widgets reliably address any of these at the semantic HTML level.

Which means: if your site has any of these five, it is on plaintiff attorneys' easy target list. If it has none of them, you have jumped ahead of roughly 80% of potential defendants — because most sites have at least three.

The 30-minute action plan

1. Scan your site. Use Accesseon's free scan or any WCAG 2.2 scanner. Record every instance of the five violations above.
2. Triage by frequency. A single missing alt on an icon is lower priority than 50 form fields without labels in your checkout flow.
3. Fix in source code. Do not reach for an overlay — see our post on why overlays don't hold up in court.
4. Re-scan to verify. Most scanners can generate a before/after diff.
5. Document with a VPAT. A VPAT 2.4 that lists these five criteria as "Supports" — backed by a recent scan — is the legal artifact that turns demand letters into short settlement negotiations.

What you do not need to do yet

Fixing the top five is about 80% of the legal risk reduction you can realistically achieve in a day of engineering time. The remaining 20% — keyboard traps, ARIA live regions for dynamic content, focus management in modals, captions on videos, and so on — are real and important, but they do not typically appear in volume-filed demand letters.

Those are what you work on next sprint, after the top five are eliminated.

The goal, practically, is not WCAG perfection. It is to not be on the easy-target list. The top five is the easy-target list. Get off it first.

---

Accesseon scans your site in 60 seconds, flags every instance of the top five (and the rest of the 80+ WCAG 2.2 criteria), and generates AI-powered code fixes on Pro plans. Free scan, no signup.