The ADA Title II Deadline Is 7 Weeks Away — Here's the Compliance Checklist Every Business Should Steal

April 24, 2026 is now seven weeks out. For state and local government websites, that date is a hard legal deadline. For everyone else, it's a signal you'd be unwise to ignore.

Here's the actual checklist — plus context on why the Title II deadline matters even if your site has nothing to do with government.

What the April 24 Deadline Actually Is

Under a 2024 DOJ rule, Title II of the ADA now requires state and local government entities serving populations over 50,000 people to meet WCAG 2.1 Level AA by April 24, 2026. Smaller public entities (under 50,000) get until April 26, 2027.

This is the first time web accessibility has been codified into federal law with specific, date-bound requirements. Before this rule, the obligation existed but the standard and timeline were always contested. Now they're not.

What's mandated: WCAG 2.1 Level AA. The same standard that's been the de facto benchmark in private-sector ADA litigation for years.

Why Private Businesses Can't Treat This as Someone Else's Problem

Title II covers government. Title III covers places of public accommodation — which courts have consistently interpreted to include commercial websites.

The litigation data makes the stakes clear:

• 5,000+ ADA web lawsuits were filed in 2025 alone
• 1,427 companies were re-sued after a prior settlement — roughly 45–46% of federal cases hit repeat defendants
• New York and California alone accounted for approximately 2,000 combined state cases last year
• The DOJ is actively pursuing Title III enforcement against private entities

The repeat-defendant number is the one that should get your attention. It means companies got sued, paid a settlement, patched the most visible issues, and got sued again. Surface-level fixes don't hold.

The Title II deadline creates a new reference point for courts and plaintiffs' attorneys. WCAG 2.1 AA is now explicitly codified as the federal standard. That makes it even harder for private businesses to argue ambiguity in Title III cases.

The WCAG 2.1 AA Checklist

WCAG is organized around four principles: Perceivable, Operable, Understandable, and Robust. Here's what each means in practice, with the specific criteria that show up in lawsuits.

Perceivable

Users must be able to perceive all information on your site, regardless of how they access it.

• Alt text on all images. Every image that conveys information needs a text alternative. Decorative images should have alt="" so screen readers skip them. Missing alt text is the single most common lawsuit trigger.
• Captions on video content. Prerecorded video needs synchronized captions. Live video needs real-time captions if it's carrying meaningful content.
• Color contrast ratio ≥ 4.5:1 for normal text; 3:1 for large text (18pt or 14pt bold). Low-contrast text isn't just a legal problem — it's unreadable for a significant portion of your users.
• No seizure-triggering content. Nothing that flashes more than 3 times per second.
• Text can be resized to 200% without losing content or functionality.

Operable

Users must be able to navigate and use your interface without requiring a mouse.

• Full keyboard navigation. Every interactive element — links, buttons, form fields, dropdowns, modals — must be reachable and usable via keyboard alone.
• Visible focus indicator. When a user navigates by keyboard, the focused element must be visually distinct. Browsers provide a default; make sure your CSS hasn't removed it.
• Skip navigation link. A "skip to main content" link at the top of the page lets keyboard users bypass repetitive navigation. It's one of the cheapest fixes with the highest impact.
• No keyboard traps. If a user tabs into a modal or widget, they must be able to tab out.
• No time limits without override. If sessions expire, users need adequate warning and a way to extend.

Understandable

Content and UI behavior must be predictable and clear.

• Descriptive link text. "Click here" and "read more" fail because they have no meaning out of context. Screen reader users often navigate by pulling a list of all links on a page.
• Form labels. Every input field needs a programmatically associated <label>. Placeholder text alone doesn't count — it disappears when the user starts typing.
• Error identification. When a form submission fails, the error must be described in text — not just indicated by color.
• Language declared. The lang attribute on <html> tells screen readers which language to use. Get it wrong and pronunciation is gibberish.
• Consistent navigation. If your nav appears on multiple pages, it should appear in the same order and location each time.

Robust

Content must work across assistive technologies, not just modern browsers with no extensions.

• Valid, semantic HTML. Heading hierarchy matters. Use <h1> through <h6> correctly. Don't use a <div> where a <button> belongs.
• ARIA only when necessary. ARIA attributes can patch semantic gaps, but misapplied ARIA breaks things for screen reader users. If native HTML works, use it.
• Custom widgets have ARIA roles and states. Accordions, tabs, carousels — if you built it custom, it needs keyboard support and appropriate ARIA.
• PDFs are tagged. Inaccessible PDFs show up in lawsuit filings regularly. If you're hosting PDFs, they need proper tag structure, alt text on images, and reading order.

The Failures That Keep Showing Up in Lawsuits

These aren't hypothetical. They're pulled from the pattern of actual federal filings:

1. Missing alt text on product images and banners — the most litigated failure by a wide margin
2. Unlabeled form fields — contact forms, checkout flows, search bars
3. Inaccessible PDFs — menus, brochures, product specs, policies
4. Low color contrast — particularly on buttons and small-print legal text
5. JavaScript widgets that block screen readers — date pickers, carousels, autocomplete dropdowns
6. No skip-nav link — forces keyboard users to tab through the entire navigation on every page load

How to Actually Audit vs. Checkbox Theater

Automated scanners are useful for a first pass. They're not a compliance strategy.

The commonly cited figure is that automated tools catch around 30% of WCAG issues. The other 70% require a human who knows what they're looking for — and ideally a real screen reader (NVDA, JAWS, VoiceOver) to test interactions.

Accessibility overlays fall in the same bucket. The DOJ has signaled skepticism about overlay-based compliance claims, and the lawsuit data supports that skepticism: overlay users still get sued.

What actual auditing looks like:

• Run an automated scanner to find the quick wins
• Manual keyboard testing through every interactive element
• Screen reader testing on the most important user flows (navigation, checkout, contact forms)
• PDF accessibility checks if you're hosting documents
• Color contrast analysis across all text and UI components

If you want to know where your site actually stands before April 24, the AccessiGuard audit covers all of this — automated scan plus manual review, specific WCAG criteria, and a prioritized fix list. No overlay sales pitch.

If you want to start with the checklist itself, download the full WCAG 2.1 AA checklist here — it's structured for the people actually doing the fixes, not just checking a box.

The Bottom Line

April 24 is a government deadline, but it's also the clearest signal yet that WCAG 2.1 AA is the law of the land for web accessibility in the U.S. The standard isn't ambiguous anymore. The enforcement trend isn't ambiguous. And the pattern of companies getting sued twice for the same site — because they did enough to settle but not enough to fix — should be the cautionary tale.

The checklist above covers what's required. The question is whether you'd rather find your gaps now or have a plaintiff's attorney find them for you.