The 10 Most Common WCAG 2.1 AA Violations on Government Websites
We scanned government websites across 6 cities. Here are the 10 accessibility violations we find most often — and how to fix them before the April 24 deadline.
The April 24, 2026 deadline is 45 days away. Every state and local government serving 50,000+ residents must meet WCAG 2.1 Level AA under the DOJ's ADA Title II rule — or face enforcement action, civil complaints, and legal exposure.
We've been scanning government websites across the country. The results are not encouraging. Of the 6 cities we analyzed recently:
| City | Score | Violations Found |
|---|---|---|
| Waco, TX (waco-texas.gov) | 55/100 | 37 |
| Pomona, CA (ci.pomona.ca.us) | 77/100 | 18 |
| Clovis, CA (cityofclovis.com) | 77/100 | 18 |
| Roseville, CA (roseville.ca.us) | 84/100 | 12 |
| Boise, ID (cityofboise.org) | 84/100 | 12 |
| Lakeland, FL (lakelandgov.net) | 85/100 | 11 |
Even the "best" site in this sample still had 11 violations. Waco had 37. And these aren't obscure edge cases — they're the same violations that appear on nearly every government site we scan.
The WebAIM Million 2025 study — which analyzed 1 million home pages — found that 94.8% of websites had detectable WCAG failures, with an average of 51 errors per page. Government sites generally fare better than average, but "better than average" is still failing.
Here are the 10 violations we find most often, with specifics on what they are, why they fail WCAG, how widespread they are, and how to fix them.
1. Missing Image Alt Text
What it is: Images on the page have no alt attribute, or the attribute is empty when the image conveys meaningful content (a photo of a council member, a map, an infographic).
Why it fails WCAG: Success Criterion 1.1.1 (Non-text Content, Level A). Screen readers skip images with no alt text, leaving blind and low-vision users with no information about what's there.
How common: WebAIM 2025 found that 55.5% of home pages had missing alt text. In our government scans, it's one of the top three violations by frequency — showing up in every site we've scanned.
Quick fix: Add descriptive alt attributes to all meaningful images. For purely decorative images (dividers, background textures), use alt="" to explicitly mark them as decorative. Don't use alt="image" or the filename — that's worse than nothing.
2. Low Color Contrast
What it is: Text doesn't have enough contrast against its background to be readable by users with low vision or color blindness. WCAG requires a minimum ratio of 4.5:1 for normal text and 3:1 for large text (18pt+ or 14pt bold+).
Why it fails WCAG: Success Criterion 1.4.3 (Contrast Minimum, Level AA). This is the single most common accessibility failure on the web.
How common: Per WebAIM 2025, 79.1% of home pages had low contrast text — the highest-frequency error in the entire study. Each affected page averaged nearly 30 distinct instances of low-contrast text.
Quick fix: Use a contrast checker (the browser DevTools accessibility panel works) to test your text/background combinations. Gray text on white backgrounds and light-colored overlays on photos are the typical offenders. Adjust your color palette — you usually don't need a dramatic redesign, just a slightly darker shade.
3. Empty or Missing Form Labels
What it is: Form fields — search boxes, contact forms, service request forms — have no associated <label> element. The placeholder text inside the field is not a substitute.
Why it fails WCAG: Success Criterion 1.3.1 (Info and Relationships, Level A) and 3.3.2 (Labels or Instructions, Level A). Without a label, screen readers announce the field as "edit text" with no context. When the user clicks into the field and the placeholder disappears, the purpose of the field is gone entirely.
How common: WebAIM 2025 found 48.2% of home pages had missing form input labels. Our gov scans routinely flag this on sites with service portals, permit applications, and utility payment forms.
Quick fix: Every <input>, <select>, and <textarea> needs a <label> element linked via for/id. If you can't add a visible label, use aria-label or aria-labelledby — but prefer visible labels.
4. Missing Document Language Attribute
What it is: The <html> element is missing the lang attribute (e.g., lang="en") that tells assistive technology what language the page is in.
Why it fails WCAG: Success Criterion 3.1.1 (Language of Page, Level A). Without it, screen readers may default to the wrong language profile, causing text to be mispronounced or read back with incorrect grammar rules.
How common: Found on 15.8% of home pages in WebAIM 2025. Easy to miss because it has no visible effect on the page — it only affects screen reader users.
Quick fix: One line: <html lang="en">. For multilingual pages, add lang attributes to individual sections where the language changes. This is typically a CMS-level fix you can deploy once and cover every page.
5. Keyboard Navigation Failures
What it is: The site can't be navigated using only a keyboard. Common failures include: no skip-to-main-content link, modal dialogs that trap keyboard focus, dropdown menus that don't open with Enter/Space, and interactive elements that aren't reachable via Tab.
Why it fails WCAG: Multiple criteria — 2.1.1 (Keyboard, Level A), 2.1.2 (No Keyboard Trap, Level A), 2.4.1 (Bypass Blocks, Level A). Keyboard access is foundational. Users with motor disabilities, many power users, and anyone using an alternative input device depends on it.
How common: Keyboard failures are harder for automated tools to catch fully, but they show up in nearly every manual audit of government sites. Complex navigation menus and third-party widgets are the usual culprits.
Quick fix: Add a "Skip to main content" link as the first focusable element on every page. Test your entire navigation flow with just the Tab key — if you get stuck anywhere, that's a WCAG 2.1.2 violation. Use tabindex="0" on custom interactive elements, and ensure all JS-driven interactions have keyboard equivalents.
6. Missing or Duplicate Page Titles
What it is: The <title> element in the HTML <head> is absent, generic ("Home" across every page), or duplicated across the site.
Why it fails WCAG: Success Criterion 2.4.2 (Page Titled, Level A). Screen reader users rely on page titles to orient themselves — especially when switching between open tabs or returning to a bookmarked page. "Home | City Website" tells them nothing.
How common: Frequently found as a secondary violation on CMS-heavy government sites where template pages inherit a default title and it never gets updated. Particularly common on sub-pages and form confirmation screens.
Quick fix: Each page needs a unique, descriptive title that identifies the page content and the organization: "Submit a Building Permit | City of Roseville" is good. Audit your CMS templates to ensure every page type generates a unique title.
7. Inaccessible PDFs
What it is: Government sites are notoriously PDF-heavy — forms, meeting agendas, permit applications, budget documents. Most of these PDFs are either scanned image files with no OCR (completely inaccessible to screen readers) or untagged PDFs that have text but no structural markup.
Why it fails WCAG: When PDFs are referenced from a website, they fall under the same accessibility requirements as web content. WCAG 1.1.1 covers images of text; PDF accessibility requires proper tagging, reading order, alt text for images, and document structure that assistive technology can interpret.
How common: In every government site scan we run, inaccessible PDFs are a recurring issue. This is the violation most likely to affect the highest-priority content — the forms residents actually need to fill out.
Quick fix: For new PDFs: export from a properly structured Word or InDesign file using accessibility export settings, then run Adobe Acrobat's Accessibility Checker. For existing PDFs: prioritize the most-used documents first. Consider HTML alternatives for forms (they're more accessible and easier to maintain). Never post a scanned image as a PDF without running it through OCR first.
8. Videos Without Captions
What it is: Video content — council meeting recordings, public service announcements, instructional videos — is published without synchronized captions.
Why it fails WCAG: Success Criterion 1.2.2 (Captions for Prerecorded Video, Level A). Deaf and hard-of-hearing users can't access audio content without captions. Auto-generated captions (YouTube's automatic captions) don't satisfy this criterion — they must be accurate, which auto-captions frequently aren't for proper nouns, local terminology, and technical language.
How common: A significant gap on government sites that regularly publish meeting recordings. Often the video exists, but captions were never added or were left as uncorrected auto-captions.
Quick fix: Review your auto-captions and correct them before publishing — YouTube's editor makes this straightforward. For new productions, factor caption editing into the workflow. For embedded videos, ensure the player exposes captions to the user.
9. Missing Focus Indicators
What it is: When a keyboard user tabs through the page, the currently focused element has no visible outline or highlight. The browser default focus ring has been removed with outline: none in CSS without providing a replacement.
Why it fails WCAG: Success Criterion 2.4.7 (Focus Visible, Level AA). If you can't see where keyboard focus is, you can't navigate. This often happens because designers remove focus rings for aesthetic reasons — but it makes the site unusable for anyone navigating without a mouse.
How common: Extremely common. The outline: none pattern is one of the most widespread accessibility anti-patterns on the web, and it's present on a large proportion of the government sites we scan.
Quick fix: Remove outline: none from your global CSS. If the default browser focus style doesn't match your design, replace it with a custom visible focus style — a high-contrast outline or box shadow. The 2024 WCAG 2.2 spec added 2.4.11 (Focus Appearance) which tightens these requirements further.
10. Broken ARIA Labels and Misused ARIA Roles
What it is: ARIA (Accessible Rich Internet Applications) attributes are used incorrectly — aria-label pointing to a nonexistent element, role="button" on a <div> with no keyboard support, redundant ARIA that creates duplicate announcements, or ARIA landmarks that conflict with page structure.
Why it fails WCAG: WCAG 4.1.2 (Name, Role, Value, Level A) and related criteria. Bad ARIA is often worse than no ARIA — it creates confusing, unpredictable behavior for screen reader users. The rule in the spec is explicit: "No ARIA is better than bad ARIA."
How common: Increasingly common as sites add interactive components, third-party widgets, and CMS page builders that generate ARIA automatically — often incorrectly. Our scans catch this on sites using accessible-seeming widgets that are actually mis-wired.
Quick fix: Audit your ARIA usage. ARIA roles must come with the full interaction contract — a role="button" element must also handle Enter and Space keystrokes. Use native HTML elements where possible; they have ARIA semantics built in. When in doubt, test with an actual screen reader (NVDA + Chrome on Windows, VoiceOver + Safari on macOS).
What to Do Before April 24
You have six weeks. That's not enough time to rebuild your site — but it's enough time to find your violations and fix the most critical ones.
Prioritize by impact and frequency:
- Color contrast and missing alt text are everywhere and relatively fast to fix
- Form labels and missing page language are often sitewide fixes you can deploy once
- PDFs and keyboard failures take longer but are high legal-risk items
Run an automated scan first. Automated tools can catch 30–40% of WCAG violations reliably and immediately. That covers the bulk of the issues in this list. Use the results to triage — start with whatever your scan flags most frequently.
Don't stop at the home page. Most audits (including ours) start there, but violations are usually worse on interior pages — forms, service portals, document libraries, and application pages are where residents interact with government most, and where accessibility failures do the most damage.
Document your progress. The DOJ rule doesn't require perfection on day one — it requires a good-faith effort toward compliance. An audit report showing what you found and what you're fixing is meaningful documentation if a complaint is filed.
Run your free AccessiGuard scan now →
AccessiGuard scans your site, flags WCAG 2.1 AA violations by severity, and gives you an actionable report — not just a raw list of errors. It's how we generated the city data above.
If you want to work through violations yourself, the free ADA compliance checklist covers every WCAG 2.1 AA criterion with plain-language explanations and quick-fix guidance.
April 24 is a deadline, not a finish line. Start with what you can find and fix now.