The WCAG Violations Plaintiff Attorneys Target First

Not All Violations Are Equal

There are 50 testable success criteria in WCAG 2.1 Level AA. If your municipal deliverable fails any of them, it is technically non-conformant. But plaintiff attorneys filing ADA accessibility complaints do not test against all 50. They focus on a narrow set of violations that share three characteristics: they are detectable by automated tools, they are easy to demonstrate to a judge, and they clearly affect real users.

This is not a guess. The 2025 EcomBack midyear lawsuit report cataloged the most commonly cited barriers in over 2,000 federal ADA filings. WebAIM's 2025 Million report — which scanned the top one million websites — found that 96% of all detected errors fall into just six categories. These six have been the same for five consecutive years.

The overlap between what automated scanning finds and what plaintiff attorneys cite is nearly perfect. That overlap is your priority list.

If you are a municipal contractor with 67 days until the April 2026 Title II deadline, these are the violations to fix first — not because the others do not matter, but because these are the ones that generate demand letters.

1. Low Contrast Text (WCAG 1.4.3)

How often it appears: 79.1% of the top million homepages fail this criterion. It is the single most common detectable WCAG failure on the web.

What the standard requires: Text must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold and above) requires at least 3:1. This applies to all text content, including text on buttons, in navigation menus, on form labels, and inside banners.

Why attorneys target it: Contrast failures are binary and provable. A scanning tool outputs a ratio. If that ratio is below 4.5:1, it fails. There is no ambiguity, no interpretation, and no need for expert testimony. A plaintiff's complaint can include the exact ratio, the exact element, and a screenshot showing the inaccessible text — all generated automatically.

Where it shows up in municipal projects: Branded elements are the most common source. A municipality's official color palette often includes combinations that do not meet contrast requirements — light blue text on white backgrounds, gray text on light gray panels, white text on medium-tone hero images. Navigation menus, footer links, and placeholder text in form fields are frequent offenders.

How to fix it: Run any contrast checker (WebAIM's Contrast Checker, the Chrome DevTools accessibility panel, or the axe-core engine) against your deliverable. Every text element that fails gets one of two fixes: darken the text color or lighten the background (or the reverse). For branded elements, work with your client to establish an accessible color palette that preserves brand identity while meeting the 4.5:1 threshold. Document the before-and-after contrast ratios in your audit defense log.

2. Missing Alternative Text (WCAG 1.1.1)

How often it appears: 55.5% of the top million homepages have images with missing alt text. Across those pages, 18.5% of all images lack alt text entirely.

What the standard requires: Every non-decorative image must have a text alternative that conveys the same information as the image. Decorative images — those that add no information and are purely visual — must have an empty alt attribute (alt="") so screen readers skip them. Functional images like linked logos or icon buttons need alt text that describes the function, not the image.

Why attorneys target it: Missing alt text is the most frequently cited specific violation in ADA lawsuit complaints. It is immediately provable — either the alt attribute exists and is meaningful, or it does not. Screen reader users encounter missing alt text as an image that announces either nothing or a meaningless filename, making entire sections of a page incomprehensible.

Where it shows up in municipal projects: Header images and logos that link to the homepage without alt text describing the destination. Informational graphics like maps, charts, or organizational diagrams with no text alternative. Photo galleries of public facilities or events where none of the images are described. Icons used as buttons (search, menu, close) where the icon has no text equivalent.

How to fix it: Audit every image on the site. Each one falls into one of three categories. If the image conveys information, write alt text that describes the content in context — not just "photo" but a description of what the photo shows and why it matters. If the image is functional (a linked logo, an icon button), the alt text should describe the action ("Go to homepage," "Open search"). If the image is purely decorative, add alt="" to ensure screen readers skip it. This is manual work, but it is straightforward and high-impact.

3. Missing Form Labels (WCAG 1.3.1, 4.1.2)

How often it appears: 34.2% of all form inputs across the top million homepages lack proper labels, according to WebAIM's 2025 data.

What the standard requires: Every form input — text fields, dropdowns, checkboxes, radio buttons, textareas — must have a programmatically associated label that a screen reader can announce. The label must describe what information the field expects.

Why attorneys target it: Inaccessible forms directly prevent users with disabilities from completing transactions — paying taxes, submitting permit applications, filing service requests, registering accounts. This is not a cosmetic issue. When a screen reader user encounters an unlabeled text field, they hear nothing about what to type. In a municipal context, this means a resident with a disability cannot independently access a government service they are entitled to. That is a clear, demonstrable harm with a specific individual who was denied access — exactly what a plaintiff needs to establish standing.

Where it shows up in municipal projects: Search fields with placeholder text but no actual label element. Contact forms where fields are visually labeled but the label is not programmatically linked to the input via a for attribute. Multi-step application forms (permits, registrations, payments) where error messages are not associated with the field that caused the error. Login forms on password-protected portals.

How to fix it: Every <input>, <select>, and <textarea> needs a corresponding <label> element with a for attribute that matches the input's id. Alternatively, the input can be wrapped inside the label element. Placeholder text is not a substitute for a label — it disappears when the user starts typing and is not reliably announced by all screen readers. If you use ARIA labels (aria-label or aria-labelledby), verify they are correctly implemented — WebAIM found that pages using ARIA actually averaged 34% more errors than pages without it, often due to incorrect implementation.

4. Empty Links and Buttons (WCAG 2.4.4, 4.1.2)

How often it appears: This is consistently one of the top six most common errors detected by WebAIM across the million-page sample.

What the standard requires: Every link and button must have a discernible, accessible name that describes its purpose. Links must make sense out of context — a screen reader user who pulls up a list of all links on the page should be able to understand where each link goes without reading the surrounding text.

Why attorneys target it: Empty links and buttons are another binary, tool-detectable failure. An anchor tag wrapping an image with no alt text produces a link with no accessible name. A button element with only an icon and no text label is silent to screen readers. Plaintiff complaints cite these as evidence that basic navigation and interaction are broken for assistive technology users.

Where it shows up in municipal projects: Social media icon links in the header or footer (a Facebook icon wrapped in a link with no text). Icon-only action buttons (hamburger menus, close buttons, expand/collapse toggles). "Read more" links that all share identical text, making them indistinguishable in a link list. Linked images — including logos — where the image has no alt text, producing a link that announces nothing or reads aloud the image file path.

How to fix it: Ensure every link has descriptive text, either as visible text content, as the alt text of a linked image, or as an aria-label. Replace generic "Click here" and "Read more" links with descriptive text that identifies the destination ("Read the full permit application guide"). For icon buttons, add visually hidden text or an aria-label that describes the action ("Open menu," "Close dialog," "Share on Facebook").

5. Missing Document Language (WCAG 3.1.1)

How often it appears: This remains one of the persistent top-six failures in the WebAIM data year after year.

What the standard requires: The HTML document must declare its primary language using the lang attribute on the <html> element (e.g., <html lang="en">).

Why attorneys target it: It is a single-line fix, which makes its absence especially damaging in a complaint. A plaintiff's attorney can point to the missing attribute and argue that the developer did not even take the most basic step toward accessibility. From a user impact perspective, screen readers use the language declaration to select the correct pronunciation engine. Without it, a screen reader may mispronounce words, switch to the wrong language voice, or produce garbled output that makes the entire page unintelligible.

Where it shows up in municipal projects: This is overwhelmingly a template-level issue. If the base HTML template for a site does not include lang="en", every page on the site fails this criterion. CMS themes and starter templates vary in whether they include it by default.

How to fix it: Add lang="en" (or the appropriate language code) to the <html> element in your base template. This is a one-line change that fixes the issue site-wide. If sections of the site include content in other languages, those sections should be wrapped in elements with the appropriate lang attribute. Verify the fix with any automated scanner — it will immediately confirm the issue is resolved.

6. Broken Heading Structure (WCAG 1.3.1, 2.4.6)

How often it appears: Heading-related issues are consistently flagged across large-scale scans, though they require more nuance to evaluate than the previous five.

What the standard requires: Pages must use a logical heading hierarchy. There should be one H1 per page, followed by H2s for major sections and H3s for subsections, with no skipped levels (no jumping from H2 to H4). Headings should describe the content of the section they introduce.

Why attorneys target it: Screen reader users navigate pages by heading. They can pull up a list of all headings on a page to understand its structure and jump directly to the section they need. If headings are missing, skipped, or used for visual styling rather than structural meaning, the page becomes unnavigable for screen reader users — a demonstrable barrier that compounds with page complexity.

Where it shows up in municipal projects: Developers using heading tags for visual styling (making something an H3 because they want smaller bold text, not because it is a subsection). CMS-generated pages where content editors choose heading levels based on appearance rather than structure. Pages with no H1 at all, or multiple H1s. Sidebar widgets and footer content that break the heading hierarchy of the main content area.

How to fix it: Review the heading structure of each page using a browser extension (the HeadingsMap extension or WAVE) that visualizes the heading outline. Verify there is one H1, that headings descend logically without skipping levels, and that each heading describes its section. If headings were used for styling, replace them with appropriate elements (a <p> with a CSS class, for example) and reserve heading tags for structural hierarchy. This is a manual review that takes minutes per page but can require template-level changes to fix systematically.

The Pattern Behind the Pattern

Look at this list as a plaintiff attorney would. Every one of these violations is detectable by a free automated tool in seconds. Every one produces a clear, documentable output — a contrast ratio, a missing attribute, an empty element. Every one maps directly to a specific WCAG success criterion with a specific conformance level. And every one can be described to a judge without requiring technical expertise: "The website has images that blind users cannot perceive. The website has forms that screen reader users cannot complete. The website has text that low-vision users cannot read."

This is the anatomy of an accessibility complaint. It is formulaic by design. The plaintiff firms that filed over 4,900 lawsuits in 2025 are not conducting comprehensive WCAG audits. They are running automated scans, identifying the same six categories of violations, and generating templated complaints at scale. The AI-assisted pro se filers driving the 40% increase in self-represented cases are using the same tools and targeting the same violations.

For municipal contractors, this means that fixing these six categories of issues does not guarantee full WCAG conformance — the remaining 60 to 70 percent of accessibility issues require manual testing and human judgment. But it does eliminate the violations that are most likely to appear in a demand letter. It closes the automated scan gaps that plaintiff firms use to identify targets. And it produces documented, timestamped evidence that you addressed the highest-risk barriers — exactly the kind of good faith documentation that supports your defense if a complaint does arrive.

Sixty-seven days. Six categories. Start with the ones the attorneys start with.

---

This post is for informational purposes only and does not constitute legal advice. Consult with qualified legal counsel for guidance specific to your situation.