Update (April 21, 2026): On April 20, 2026, the DOJ published an Interim Final Rule extending the ADA Title II web accessibility compliance deadlines by one year. State and local government entities with populations of 50,000+ now have until April 26, 2027. Smaller public entities have until April 26, 2028. The points in this post still apply (private-sector ADA exposure, EAA compliance, and rising Title III lawsuit volume are unchanged), but the hard April 2026 deadline for public-sector entities no longer applies. For why overlay widgets still aren’t a compliance shortcut, see this follow-up.
On April 24, 2026, ADA Title II’s digital accessibility requirements take effect. State and local government websites must meet WCAG 2.1 AA. That’s not a recommendation. It’s a federal requirement with enforcement behind it.
If you’re in the private sector, you’re not off the hook. The DOJ has treated websites as “places of public accommodation” under the ADA for years, and ADA-related web accessibility lawsuits have risen sharply year over year. The European Accessibility Act, in effect since June 2025, applies to any business selling to EU customers regardless of where the business is based.
95.9% of home pages have detectable WCAG violations. If you haven’t checked your site, there’s a strong chance it fails.
What WCAG 2.1 AA means in plain language
WCAG stands for Web Content Accessibility Guidelines. It’s the standard that defines what an accessible website looks like. The “2.1” is the version. “AA” is the conformance level.
There are three levels: A (minimum), AA (the accepted standard), and AAA (strictest). AA is what compliance frameworks reference. It’s what the courts apply. It’s the right target.
The standard organizes requirements around four principles. Your site must be:
- Perceivable: content can be seen, heard, or read by everyone, including users with visual or hearing impairments. This covers color contrast, alt text on images, captions on video, and text alternatives for non-text content.
- Operable: every function works with a keyboard, not just a mouse. Links, buttons, forms, and menus must be navigable without a pointing device. Touch targets need adequate size. Nothing should flash in a way that could trigger seizures.
- Understandable: content is readable and the interface behaves predictably. Forms explain what’s expected. Error messages say what went wrong and how to fix it. Navigation is consistent across pages.
- Robust: content works with assistive technologies like screen readers. This means semantic HTML, correct use of ARIA attributes, and valid markup that assistive technology can reliably parse.
That’s it. No mystery. The violations that trip up most sites are straightforward to identify and, in most cases, straightforward to fix.
The five issues to fix first
These cover the majority of real-world violations. If your site passes on these five, you’ve addressed the most common failures.
1. Color contrast
83.9% of home pages have insufficient contrast between text and background. WCAG AA requires a 4.5:1 ratio for normal text and 3:1 for large text. Light gray text on a white background, thin fonts on busy images, placeholder text in form fields: these are the most common failures.
What to check: Run your brand colors through a contrast checker. Check body text, headings, link text, button text, and form placeholders against their backgrounds. Don’t forget hover states and focus states.
2. Missing or generic alt text
53.1% of home pages have images with missing alt text. A screen reader reads the alt attribute aloud. If it says “image1.jpg” or nothing at all, the user gets no information. If every image says “photo,” that’s not much better.
What to check: Every informational image needs alt text that describes what the image communicates, not what it looks like. Decorative images (visual flourishes, background patterns) should have empty alt attributes so screen readers skip them entirely.
3. Keyboard navigation
If your site only works with a mouse, it doesn’t work for users on keyboards, switch devices, voice control, or screen readers. Every link, button, form field, dropdown, and modal needs to be reachable and operable with the Tab key and Enter/Space.
What to check: Put your mouse away. Tab through your entire site. Can you reach every interactive element? Can you see where focus is (a visible outline or highlight)? Can you open and close menus, submit forms, and navigate without getting stuck? If you get trapped in a widget with no way to tab out, that’s a keyboard trap: one of the most severe violations.
4. Form labels and errors
Form inputs without associated labels are one of the most common accessibility failures. A screen reader user tabbing into an unlabeled input field has no idea what to type. Placeholder text doesn’t count as a label because it disappears when the user starts typing.
What to check: Every input field should have a visible label linked to it. Required fields should be clearly marked. Error messages should explain what went wrong and which field needs attention, not just “There was an error.”
5. Heading structure
Headings aren’t just visual styling. Screen reader users navigate by headings the way sighted users scan a page visually. If your heading hierarchy jumps from h1 to h4, or uses headings purely for font size, the page structure is broken for assistive technology.
What to check: Every page should have one h1. Headings should follow a logical order (h1, h2, h3) without skipping levels. If something looks like a heading but isn’t marked up as one, it’s invisible to screen readers.
How to run a basic audit yourself
You don’t need to hire someone to find out where you stand. A few free tools will surface the most obvious issues:
- Browser DevTools Accessibility Panel: built into Chrome and Firefox. Inspect any element and check its accessibility properties, roles, and labels.
- axe DevTools: a free browser extension that scans the current page and lists WCAG violations with explanations and fix suggestions.
- WAVE: a web-based tool that overlays accessibility errors and warnings directly on your page. Good for visual learners.
- Lighthouse: built into Chrome DevTools. Run an accessibility audit and get a scored report with specific issues.
These tools catch roughly 30% of WCAG violations: the ones that can be detected programmatically. Contrast failures, missing alt text, broken ARIA attributes, missing form labels. They won’t catch the other 70%: keyboard navigation problems, screen reader behavior, logical reading order, or whether alt text actually describes the content accurately. But they’ll tell you whether you have obvious problems.
Run one of these tools on your homepage. If it flags more than a handful of issues, the rest of your site likely has similar problems.
Why accessibility overlays don’t work
If you’ve seen a widget that promises one-click WCAG compliance (a small icon in the corner of a site that opens an accessibility menu), know that these don’t meet compliance requirements. The DOJ, accessibility advocacy organizations, and multiple court rulings have made this clear.
Overlays attempt to fix issues client-side with JavaScript. They can’t fix missing alt text because they don’t know what the image represents. They can’t fix heading structure because they don’t understand the content hierarchy. They can’t fix keyboard traps because they don’t control the site’s interaction patterns. What they can do is add another layer of JavaScript that sometimes conflicts with the assistive technology users already have.
Over 1,000 accessibility professionals have signed a public statement against overlay products. Multiple lawsuits have specifically named overlay-equipped sites as non-compliant. An overlay is not a fix. It’s a liability. For a full breakdown of why overlays fail audits, users, and courts, see Why Accessibility Overlays Don’t Count as WCAG Compliance.
When to bring in a professional
If your audit surfaces a handful of contrast issues and missing alt text, you can probably fix those internally. These are HTML and CSS changes that don’t require deep accessibility expertise.
Bring in a professional when:
- Your site is large or complex (dozens of pages, dynamic content, authenticated sections)
- Automated tools show widespread issues across multiple categories
- You need to test with actual assistive technology (screen readers, switch devices)
- The codebase has structural problems (non-semantic markup, missing landmarks, JavaScript-heavy interactions)
- You’re facing a compliance deadline and need a clear scope, timeline, and verification process
The difference between automated scanning and a professional audit is the 70% of issues that tools can’t catch. A professional tests with real assistive technology, evaluates the user experience (not just the markup), and prioritizes fixes by severity so the highest-impact issues get resolved first. Here’s what that process looks like in practice.
Accessibility isn’t a one-time fix
Compliance is the floor, not the ceiling. 1.3 billion people globally live with some form of disability. In the US, that’s 1 in 4 adults. An inaccessible site excludes that audience entirely. The things that make a site accessible (semantic HTML, clear heading structure, descriptive link text, sufficient contrast) are the same things search engines reward, and the same things AI assistants need to cite your site. Sites that invest in accessibility consistently see better organic traffic, lower bounce rates, and improved usability for every user, not just those on assistive technology.
Compliance isn’t static. Every content change, feature addition, and CMS edit is a chance to reintroduce violations. The sites that stay compliant build accessibility into their process, not just their launch checklist.
The April 24 deadline is the start, not the finish. The sites that treat accessibility as infrastructure rather than a project are the ones that stay compliant as they evolve.