What the ADA Title II 2026 Deadline Means After the DOJ Extension
The ADA accessibility deadline 2026 has moved. On April 20, 2026 — four days before large public entities were due to comply — the U.S. Department of Justice published an interim final rule pushing the ADA Title II web accessibility compliance dates back by one year. State and local governments serving populations of 50,000 or more now have until April 26, 2027, and smaller entities and special districts have until April 26, 2028. The technical standard has not changed: WCAG 2.1 Level AA is still the rule, and the underlying nondiscrimination obligations under Title II have been in force the entire time.
Key takeaways
- DOJ extended the ADA Title II web rule by one year on April 20, 2026, via interim final rule published in the Federal Register.
- New deadlines: April 26, 2027 for public entities serving 50,000 or more, April 26, 2028 for smaller entities and special districts.
- The substantive rule is unchanged — WCAG 2.1 AA, full scope, including content delivered through vendors and licensors.
- HHS Section 504's parallel deadline of May 11, 2026 was not extended and still applies to recipients of HHS funding.
- Private ADA litigation continues. 3,117 federal website accessibility lawsuits were filed in 2025, a 27% jump from 2024 per Seyfarth Shaw's annual report.
- The European Accessibility Act has been enforceable across all 27 EU member states since June 28, 2025.
What changed on April 20, 2026
The Department of Justice's 2024 final rule under Title II of the Americans with Disabilities Act set the first technical web standard for state and local government entities. The original deadlines — April 24, 2026 for population 50,000+ and April 26, 2027 for everyone else — had been on the calendar since the rule appeared in the Federal Register in June 2024.
Four days before the larger deadline, DOJ published an interim final rule (IFR) that took effect immediately. The agency's stated rationale was that it had "overestimated the capabilities (whether staffing or technology) of covered entities to comply with the rule in the time frames provided." Resource constraints, staffing limitations, slower-than-expected remediation tooling — including the practical limits of generative AI for automated fixes — and litigation exposure under Title II's private right of action were all cited. The public comment window for the IFR closes on June 22, 2026.
The IFR did not touch the substance of the rule. WCAG 2.1 Level AA remains the technical benchmark, the scope still covers web content and mobile applications, and the rule still applies to content "provided or made available" through third-party vendors and licensors. Procurement and vendor management are in scope, not just first-party code.
For QA leaders the headline is simple: the work is the same, the calendar has one more year, the cost of delay went up. DOJ telegraphed that it "fully anticipates" enforcement at the new deadline, and disability-advocacy groups have called the extension unconscionable. Anyone treating it as a pause is reading it wrong.
Who is in scope under ADA Title II
Title II covers every program, service, or activity of a state or local government — a wide net that pulls in city, county, and state government portals, public K-12 districts and their student information systems, public colleges and universities (including LMS, library catalogs, and admissions portals), court filing and public records tools, transit agency sites and fare apps, public library digital lending platforms, utility billing portals, 311 services, emergency alert systems, and voter registration and elections information sites.
The rule applies to new and existing content. Exceptions are narrow — archived content posted before the compliance date and never updated, pre-existing conventional electronic documents (PDF, Word) that are not used for current programs, third-party content the entity does not post or control, and content posted by members of the public, such as social media comments. None of those exceptions excuse the core functionality of a public-facing service.
Vendors and contractors building software for Title II entities are not directly regulated by the DOJ rule, but they sit downstream of every procurement that now references WCAG 2.1 AA as a contract requirement. Voluntary Product Accessibility Templates (VPATs) and accessibility conformance reports have become table stakes in government RFPs, and a vendor that cannot produce one is functionally locked out.
ADA Title II vs HHS Section 504 vs EAA: the rules that still bite
The DOJ extension is not the only accessibility deadline on the 2026 calendar. Two parallel regimes were not extended and continue to apply on their original timelines.
| Regulation | Who it covers | Standard | Key 2025–2028 dates | Status |
|---|---|---|---|---|
| ADA Title II (DOJ) | State and local governments | WCAG 2.1 AA | Apr 26, 2027 (pop 50K+), Apr 26, 2028 (smaller) | Extended by IFR on Apr 20, 2026 |
| HHS Section 504 | Recipients of HHS funding (hospitals, many universities, state health programs) | WCAG 2.1 AA | May 11, 2026 (large), May 11, 2027 (small) | Not extended |
| European Accessibility Act | In-scope products and services sold to EU consumers | EN 301 549 / WCAG 2.1 AA | June 28, 2025 in force; June 28, 2030 for legacy services | Enforceable now |
| ADA Title III | Private "public accommodations" (retail, hospitality, healthcare, etc.) | No specific federal technical rule — courts increasingly look to WCAG 2.1 AA | Ongoing litigation | Active |
| Section 508 | U.S. federal agencies and federal contractors | WCAG 2.0 A and AA (revised standards in force since 2018) | Ongoing | Active |
A few of these are worth pulling out.
HHS Section 504. HHS published its own rule in May 2024 imposing WCAG 2.1 Level AA on entities that receive HHS funding — which sweeps in most U.S. hospitals, many universities, and state-administered health programs. HHS has explicitly not matched the DOJ extension. The first compliance date remains May 11, 2026 for large recipients. Healthcare-adjacent organizations that assumed the DOJ extension applied to them are wrong, and Seyfarth Shaw's 2025 data already shows healthcare filings rising fast in advance of that date.
The European Accessibility Act (EAA). Directive (EU) 2019/882 has been enforceable since June 28, 2025. It applies to e-commerce, banking, telecoms, passenger transport ticketing, e-readers, and several other categories sold to EU consumers — regardless of where the seller is established. EN 301 549 is the European technical standard, grounded in WCAG 2.1 AA. Penalties vary by member state: published frameworks range from typical fines around €100,000 per violation up to €500,000 in Germany, and up to 4% of annual revenue in some jurisdictions. A U.S. company selling SaaS to EU consumers is in scope, and the deadline is already gone. Existing services placed on the market before June 28, 2025 have a transition window until June 28, 2030, but a published accessibility statement is required from day one.
Section 508 and ADA Title III. Section 508 applies to federal agencies and contractors and references WCAG 2.0 A and AA. ADA Title III has no final DOJ technical rule, but federal courts have for years allowed plaintiffs to use WCAG 2.1 AA as the de facto benchmark in litigation against private businesses.
The litigation picture: why "we'll fix it later" is the expensive option
ADA Title III filings — the lawsuits against private businesses — did not pause for the regulatory extension because they never depended on a DOJ rule in the first place. The data from Seyfarth Shaw's ADA Title III Tracker is the cleanest public source.
- 8,667 ADA Title III lawsuits were filed in or removed to federal district courts in 2025, roughly three times the 2013 baseline.
- 3,117 of those (36%) specifically alleged website inaccessibility — a 27% jump from 2,452 in 2024, which more than reversed the prior two-year decline.
- California, Florida, and New York remained the top three jurisdictions, with Florida nearly doubling its 2024 volume.
- Pro se filings rose sharply — Seyfarth Shaw attributes around 40% of 2025 federal filings to pro se plaintiffs, many of whom are using generative AI to draft complaints and identify violations.
- E-commerce and retail businesses are the dominant target, accounting for roughly 70% of digital accessibility cases, with food and beverage at 21% and healthcare rising into third place ahead of the HHS deadline.
These are federal numbers only. Plaintiff firms have been migrating to state court in New York and New Jersey, where standing thresholds are more permissive, so the true volume is meaningfully higher than the federal data shows.
The economics of a single ADA web lawsuit have not improved. Defending a case typically runs $50,000 to several hundred thousand dollars in legal fees even when the defendant prevails, and settlements add another $25,000 to $100,000 on top. Prevailing plaintiffs can recover attorney's fees under the ADA, so losses compound. Building an accessibility program ahead of a deadline is almost always cheaper than three or four lawsuit cycles.
The DOJ extension does not insulate Title II entities against private suits either. Title II permits direct private rights of action without administrative exhaustion, and underlying nondiscrimination obligations have always supported web accessibility claims with or without a codified technical standard.
What WCAG 2.1 Level AA actually requires (and where teams fail)
WCAG 2.1 is organized around four principles — Perceivable, Operable, Understandable, Robust — across 50 Level A and AA success criteria. The DOJ rule cites 2.1, not 2.2, but WCAG 2.2 is fully backward-compatible. A site that meets WCAG 2.2 AA automatically satisfies 2.1 AA. WCAG 2.2 became a W3C Recommendation in October 2023 and was approved as ISO/IEC 40500:2025 on October 21, 2025. For new work, teams targeting 2.2 today avoid a re-baselining exercise when EN 301 549 and likely future U.S. rulemakings catch up.
The failure modes that show up most often in audit reports of government and enterprise sites are consistent:
- Missing text alternatives (1.1.1). Images without
alt, icon buttons with no accessible name, charts with no text equivalent — the single most-cited failure across every sector. - Keyboard inaccessibility (2.1.1). Dropdowns, modals, date pickers, and custom widgets that work only with a mouse, almost always traceable to custom JS built without keyboard patterns.
- Insufficient contrast (1.4.3, 1.4.11). Body text below 4.5:1, large text below 3:1, UI components below 3:1. Brand palettes are rarely audited against 1.4.11's non-text requirement, which arrived with WCAG 2.1 in 2018.
- Form labels and error handling (1.3.1, 3.3.2, 3.3.3). Inputs that rely on placeholders instead of
<label>, errors communicated only by red borders, validation errors not associated with the offending field. - Reflow at 320 CSS pixels (1.4.10). Pages that force horizontal scrolling at small viewport widths — the scenario faced by users zooming in on mobile.
- Broken or misapplied ARIA (4.1.2) and unannounced dynamic content (4.1.3). Custom components with no exposed role, state, or value, status updates or validation errors that change visually but are silent because no
aria-liveregion or focus management is wired up.
The deeper context here is summarized in our piece on why most websites still fail accessibility. The patterns repeat across sectors. The fixes do too.
What an accessibility testing program looks like in practice
Automated scanners catch roughly 30% to 57% of WCAG failures depending on which study you cite — Deque's own data on axe-core puts the figure near 57% under optimal conditions, and independent audits typically land closer to 30%. The remainder — keyboard walkthroughs, screen-reader behavior on dynamic UI, cognitive walkthroughs of multi-step workflows — needs a human. A real program combines both.
Step 1: Run a baseline audit
The audit has to cover the full URL inventory, not the marketing home page. Template pages, transactional flows, authenticated workflows, and document downloads all count. A working baseline blends automated scanning with axe DevTools, WAVE, or Pa11y across every template and key flow, keyboard-only walkthroughs of every interactive component, screen-reader testing with NVDA + Firefox on Windows and VoiceOver + Safari on macOS and iOS, contrast verification against every text and UI combination in the design system, and mobile checks for reflow at 320px and 24×24 touch targets (a WCAG 2.2 addition worth adopting now). Each finding gets logged against a specific WCAG criterion with reproduction steps and the affected URL or component.
Step 2: Triage by severity, frequency, and user impact
A login form with no accessible labels is a blocker. A lang attribute missing on an embedded fragment is real but lower urgency. A failure in a shared header component shows up on every page — fix it once, propagate the fix everywhere. Triage relentlessly.
Step 3: Fix at the design-system layer
Page-by-page remediation is how programs run out of budget halfway through. Fixing accessibility in the shared component library — focus indicators, accessible names, keyboard handlers, color tokens — propagates the fix across every consumer of that component. Most large remediation efforts that succeed on time look the same: a small platform team rebuilds the component library, then content teams catch up on alt text, link text, and headings.
Step 4: Move accessibility into CI
The cleanest way to keep a backlog from regrowing is to fail the build on net-new accessibility violations. axe-core integrates with Jest, Playwright, and Cypress for component and end-to-end coverage; Pa11y CI handles crawler-driven scans on staging; the Storybook a11y addon catches design-system regressions before a component ever ships to an app. A "no new violations" policy keeps existing baseline issues on the backlog while preventing pull requests from adding any. This is what teams mean by accessibility-as-CI — feedback is fast, local, and unambiguous, the same reason linting works. Most modern QA programs are folding it into the broader shift-left pattern documented in 10 SQA methodologies with real-world case studies.
Step 5: Manual accessibility regression on every new component
Anything new gets a keyboard-only run-through and at least one screen-reader pass before merge. This is the part automation will not replace any time soon. Pair it with a published accessibility statement — what standard you target, your testing methodology, how to report a barrier — and your conformance posture is documented if a complaint lands.
Tooling: what to actually install this week
There is no shortage of accessibility tools. A handful of open-source or freemium options cover most of what a working team needs.
axe DevTools (deque.com/axe) — the axe-core engine is the de facto industry standard and powers Lighthouse's accessibility category, Accessibility Insights, and dozens of CI integrations. The CLI and the Playwright/Cypress integrations are how axe ends up in CI.
WAVE (wave.webaim.org) — WebAIM's tool overlays accessibility indicators directly on the rendered page. Useful for evaluating heading structure, label associations, and contrast in context, and the browser extension runs locally so it works on staging and authenticated pages without leaking content to a third party.
Pa11y (pa11y.org) — the CLI tester that maps neatly onto CI pipelines. pa11y-ci runs axe-core or HTML_CodeSniffer across a URL inventory on every build, with thresholds that fail the pipeline on regressions.
Lighthouse (built into Chrome DevTools) is useful for a sampling pass, not a conformance audit. The accessibility score is powered by a subset of axe-core rules — do not present it to a regulator as evidence of conformance. For broader Lighthouse usage see our Chrome DevTools performance auditing guide.
Beyond that, NVDA + Firefox on Windows and VoiceOver + Safari on macOS and iOS are the two screen-reader combinations that match how the majority of real users actually browse. The Colour Contrast Analyser from TPGi handles the cases automated tools miss — text over images, custom focus indicators, gradient backgrounds. All free.
For a longer breakdown including paid platforms and AI-driven options, see the best accessibility testing tools for WCAG.
What the private sector should still be doing
The DOJ extension applies to Title II entities only. Private "public accommodation" businesses under Title III — retail, hospitality, healthcare, financial services, education — got nothing from the IFR, the litigation environment continues to escalate, the European Accessibility Act is in force across all 27 EU member states, and ADA Title III plaintiffs in U.S. federal court increasingly cite WCAG 2.1 AA as the de facto standard regardless of whether DOJ has codified it for the private sector.
The strategic position is straightforward: align to WCAG 2.1 AA now, target WCAG 2.2 AA for new work, and treat accessibility as a release gate rather than a quarterly audit. The cost of building it in is lower than the cost of bolting it on, and that gap widens every year regulators and plaintiffs keep applying pressure.
For QA teams, accessibility is not a separate workstream — it is a normal acceptance criterion. A dropdown is not done when it looks right. It is done when it opens with Enter or Space, closes with Escape, navigates with arrow keys, exposes the correct role and state to assistive tech, and meets contrast. One set of test conditions, written once, run every time the component ships.
FAQ
What is the ADA Title II 2026 deadline now?
The original April 24, 2026 deadline for public entities with a population of 50,000 or more was extended on April 20, 2026 to April 26, 2027. Smaller public entities and special districts now have until April 26, 2028. The technical standard (WCAG 2.1 Level AA) and substantive scope were not changed.
Did the HHS Section 504 deadline change too?
No. The Department of Health and Human Services has not matched the DOJ's extension. The first HHS Section 504 web accessibility compliance date remains May 11, 2026 for large recipients of HHS funding.
Is WCAG 2.1 or WCAG 2.2 the right target?
Legally, the DOJ rule cites WCAG 2.1 Level AA. Practically, WCAG 2.2 AA is fully backward-compatible — meeting 2.2 means you also meet 2.1 — and WCAG 2.2 is now ISO/IEC 40500:2025. For new development work in 2026, target 2.2 AA.
Does the European Accessibility Act apply to U.S. companies?
Yes, if you place an in-scope product or service (e-commerce site, banking platform, ticketing service, e-reader, and similar categories) on the EU market or offer it to EU consumers. The EAA has been enforceable since June 28, 2025 regardless of where the seller is established. Microenterprises (under 10 employees and under €2M turnover) are partially exempt.
How much of WCAG can automated tools actually catch?
Estimates range from roughly 30% to 57% of WCAG failures, depending on the study. Axe-core's own publications put the figure near 57% under optimal conditions; independent audits often land lower. The remainder requires manual keyboard testing, screen-reader testing, and cognitive walkthroughs.
What does an ADA web accessibility lawsuit typically cost?
Defending an ADA web case typically costs $50,000 to several hundred thousand dollars in legal fees, with settlements adding another $25,000 to $100,000 on top. Plaintiffs who prevail can recover attorney's fees, which substantially increases the downside of losing on the merits.
File accessibility bugs with full context, not just a screenshot
Accessibility bugs are among the hardest QA artifacts to document well. A failure usually depends on the interaction between an assistive technology, a browser, a particular DOM state, and a sequence of keyboard or focus events. A static screenshot rarely conveys any of that. Developers picking up the ticket need the sequence, the console state, the DOM at the moment of failure, and the environment details — not a flat image with a red arrow.
Crosscheck is a free Chrome extension for visual bug reporting that captures all of that in one click. Screenshot or full screen recording, complete browser console log, every network request, and the environment metadata — browser, OS, viewport, screen size — packaged into a single report that lands in Jira, Linear, ClickUp, Slack, or GitHub. For accessibility testing programs racing toward 2027 deadlines and HHS's 2026 date, the bottleneck is rarely finding bugs. It is moving them from discovery to verified fix without three rounds of "can you send more detail?" The perfect bug report template outlines what a complete report looks like and why screen recordings beat screenshots almost every time.
Try Crosscheck free and shorten the loop between every accessibility finding and the fix in production.
