ADA Title II Digital Accessibility

The current event

What changed in April 2026

The original 2024 final rule set an April 24, 2026 compliance date for public entities with a population of 50,000 or more, and an April 26, 2027 date for smaller entities and special district governments. On April 20, 2026, DOJ published an Interim Final Rule that extended both dates by one year.

DOJ said the extension was intended to give public entities more time in light of reported resource constraints, staffing limitations, and slow technological advancement. The amendment changed the dates. It did not rewrite the rest of the 2024 web and mobile accessibility rule.

ADA Title II web and mobile accessibility compliance dates
Public entity	Original date	Current date
Population 50,000 or more	April 24, 2026	April 26, 2027
Population under 50,000	April 26, 2027	April 26, 2028
Special district government	April 26, 2027	April 26, 2028

The rule itself

What did not change

The technical standard

WCAG 2.1 Level A and Level AA remain the technical requirements incorporated into the Title II web and mobile app rule.

The covered technologies

Web content and mobile apps remain covered, including content and apps made available through contractual, licensing, or other arrangements.

The ongoing obligation

After the applicable compliance date, accessibility is not a one-time launch milestone. Public entities must continue to keep covered web content and mobile apps compliant.

The limited exceptions

The rule still contains five defined content exceptions. They are not a general exemption from accessibility or a substitute for understanding the underlying ADA obligations.

Coverage

Who is covered

Title II applies to state and local government services, programs, and activities. In the digital context, that can include state agencies, counties, cities, towns, public schools, public colleges and universities, courts, public transit providers, election offices, libraries, public health agencies, parks and recreation departments, and many other public entities.

Population is not simply "how many people we serve"

DOJ provides specific instructions for determining population for the compliance timeline. For many public entities, the 2020 decennial Census population is used. Independent school districts use a different Census data source identified by DOJ. Special district governments are placed on the April 26, 2028 timeline because they do not have Census populations calculated in the same way.

Examples of special district governments

Transit authorities
Utility districts
Water and sewer boards
Zoning districts
Mosquito abatement districts
Other separate governmental entities that provide a limited set of functions

Digital scope

What is actually in scope

The rule is broader than the public-facing pages of a main website. It applies to web content and mobile apps a public entity provides or makes available, including through certain third-party arrangements.

Common web content

HTML pages and web applications
Online forms and application workflows
PDF, Word, PowerPoint, and other electronic documents
Images, maps, charts, and infographics
Audio and video
Calendars, agendas, minutes, and public notices
Payment, reservation, licensing, and registration systems
Authenticated portals and account areas

Common mobile app functions

Transit schedules and trip planning
Utility account management
Parking and payment services
Emergency alerts
Public meeting and civic participation tools
Service request and issue reporting
Library, recreation, and education services
Digital credentials and account services

Not blanket exemptions

The five specific content exceptions

The rule identifies five categories of content that can be excepted from the WCAG 2.1 AA technical requirement when their conditions are met. Exact applicability matters.

Archived web content

Content that meets the rule's definition of archived web content can be excepted. "Old" does not automatically mean "archived." The content has to satisfy the rule's definition and conditions.
Preexisting conventional electronic documents

Some documents that were available before the entity's compliance date can be excepted. However, the exception does not apply when a preexisting document is currently used to apply for, gain access to, or participate in a public service, program, or activity.
Some third-party content

Content posted by an independent third party can be excepted, but not when that third party is posting because of a contractual, licensing, or other arrangement with the public entity.
Individualized secured documents

Conventional electronic documents about a specific individual, their property, or their account can be excepted when they are password-protected or otherwise secured.
Preexisting social media posts

Social media posts made before the entity's applicable compliance date can be excepted from the technical standard.

The technical target

What WCAG 2.1 Level AA means in practice

For this Title II rule, the legal technical standard is WCAG 2.1 Level A and Level AA. That matters because accessibility teams may also work with newer guidance, but the rule specifically incorporates WCAG 2.1. An organization can choose to go beyond the minimum, but it should not describe a different version as the standard named by this rule.

Perceivable

Useful text alternatives for meaningful images
Captions for prerecorded video with audio
Information and structure available programmatically
Sufficient color contrast
Content that can be resized and reflowed without loss of information or function

Operable

All functionality available from a keyboard
Visible keyboard focus
Enough time to read and use content when time limits exist
Meaningful page titles, headings, link purpose, and focus order
Interfaces that do not create known seizure risks

Understandable

Page language identified in code
Predictable navigation and interaction
Clear labels and instructions
Errors identified in text
Useful correction suggestions when appropriate

Robust

Valid names, roles, states, and values for user interface components
Status messages available to assistive technologies when required
Controls that work with browsers and assistive technologies
Native HTML used wherever it provides the needed behavior

This section is a practical orientation, not a substitute for the complete WCAG 2.1 success criteria and conformance requirements.

Conformance needs evidence

How to test without fooling yourself

Automated scanning is valuable for repeatable checks across many pages, but W3C is explicit that no tool alone can determine whether a site meets accessibility standards. Knowledgeable human evaluation is required. A serious program combines automation, manual review, assistive technology, and testing of real tasks.

Automated checks

Use scanners to catch machine-detectable issues such as certain missing accessible names, markup problems, contrast failures, duplicate IDs, and other patterns. Run them continuously, not only before launch.

Keyboard-only testing

Complete critical tasks without a mouse. Check focus order, visible focus, menus, dialogs, forms, date pickers, data tables, custom controls, and whether focus becomes trapped or lost.

Screen reader testing

Test structure, headings, landmarks, names, descriptions, form errors, dynamic updates, dialogs, tables, and task completion with common browser and screen reader combinations.

Voice and speech input testing

Check whether visible control text matches accessible names, whether controls can be targeted predictably, and whether custom components remain operable without precise pointer input.

Zoom and reflow

Inspect content at high zoom and narrow viewport widths. Look for clipping, horizontal scrolling that blocks reading, overlapping controls, hidden text, and sticky elements that consume too much space.

Mobile app testing

Test screen reader support, focus order, labels, gestures, orientation, text scaling, touch target behavior, dynamic messages, and complete workflows on supported mobile platforms.

Document accessibility

Review document structure, tags, reading order, headings, table markup, links, form fields, alternate text, color use, document titles, and whether the document remains usable with assistive technology.

People with disabilities

Include disabled users in evaluation to expose real usability barriers that standards checks can miss. Pair user evaluation with WCAG conformance testing rather than treating either method as a replacement for the other.

Use the extension deliberately

A practical roadmap from now to April 2027

The schedule below is a practical implementation model, not a DOJ-mandated sequence.

1. Establish ownership and inventory

Identify executive ownership, ADA/accessibility leadership, web teams, content owners, procurement, legal, communications, document producers, mobile app owners, and vendor managers. Inventory domains, subdomains, apps, portals, documents, multimedia, third-party systems, and critical user journeys.
2. Stop creating new barriers

Fix shared templates, components, design systems, CMS patterns, form builders, publishing workflows, and document templates first. Remediating new content repeatedly is slower and more expensive than correcting the source pattern.
3. Prioritize high-impact services

Move critical public services to the front of the queue: voting, emergency information, benefits, taxes, education, health, payments, licensing, permits, transportation, public meetings, and frequently used forms.
4. Remediate documents and media at scale

Create a decision process for fixing, replacing, converting, archiving, or removing obsolete documents. Caption and describe media where required. Train the people who publish new files so inaccessible inventory does not keep growing.
5. Put vendors on the same clock

Require product-level evidence, not only broad accessibility claims. Evaluate demos with assistive technology. Track defects contractually. Define remediation commitments, accessibility documentation, testing expectations, and escalation paths.
6. Perform structured conformance testing

Use representative sampling for large sites, but always include core templates, major components, and critical user flows. Combine automated and manual methods. Document scope, findings, severity, owners, evidence, and retest status.
7. Retest after remediation

A closed ticket is not proof of a fixed barrier. Reproduce the original failure, verify the correction with the relevant test method, and check that the fix did not create a regression elsewhere.
8. Enter continuous compliance mode

Before the deadline, move accessibility into routine publishing, procurement, development, quality assurance, and release processes. The goal is not a last-minute clean site. The goal is an organization that can keep its digital services accessible.

A major risk area

Procurement and vendor management

Many public services are delivered through products a government entity did not build: payment platforms, appointment systems, learning systems, document viewers, meeting platforms, recreation registration, maps, chat tools, transit products, form engines, and mobile apps. That makes procurement one of the most important accessibility controls.

Ask vendors for evidence you can evaluate

A current accessibility conformance report that names the tested product and version
The testing methodology used to produce the report
Known defects and their functional impact
Assistive technologies and browsers used during testing
Accessibility of administrative interfaces, not only end-user screens
Mobile accessibility results when a mobile app is part of the service
A remediation process with accountable contacts and target dates
Contract language covering regressions after product updates
A method for reporting accessibility defects during the contract
An exit or escalation path when accessibility obligations are not met

An accessibility statement, badge, automated score, or sales promise can be useful context. None of them should be treated as conformance evidence by themselves.

Beyond remediation

How an organization keeps content accessible

The hardest accessibility problem is often not fixing a defect. It is preventing the same defect from returning next week through a different page, document, vendor release, or content author.

Policy

Define the standard, scope, ownership, exception handling, procurement expectations, testing practices, reporting routes, and accountability.

Training

Train by role. Developers, designers, document authors, procurement staff, video teams, social media teams, and executives need different accessibility skills.

Accessible defaults

Provide accessible templates, components, document styles, form patterns, and publishing tools so the easiest path is also the accessible path.

Quality gates

Add accessibility checks to design review, pull requests, content publishing, procurement, acceptance testing, and release criteria.

Feedback

Give the public a clear, accessible way to report a barrier. Route reports to people who can act, track them, communicate status, and verify fixes.

Metrics

Measure critical-task coverage, open barriers, aging defects, document inventory, vendor risk, regression rate, training completion, and retest results. Avoid reducing accessibility to one automated score.

What the extension does not mean

Common myths

"The deadline moved, so accessibility can wait until 2027."

No. The specific WCAG compliance dates moved, but DOJ guidance says broader Title II obligations for equal access and effective communication still apply before those dates. Large remediation programs also take time.

"If a vendor built it, the vendor owns the ADA problem."

Not necessarily. The rule expressly reaches web content and mobile apps provided or made available through contractual, licensing, or other arrangements.

"An automated scanner can certify the site."

No. Automated tools can identify many useful issues, but W3C says no tool alone can determine whether a site meets accessibility standards. Human evaluation is required.

"Every old PDF has to be remediated."

No. The rule includes a specific exception for some preexisting conventional electronic documents. But the conditions matter, and documents still used to access or participate in programs can fall outside that exception.

"WCAG 2.2 is the legal standard under this rule because it is newer."

No. The Title II web and mobile app rule specifically incorporates WCAG 2.1 Level A and Level AA. Organizations may choose to meet newer guidance too, but the rule names WCAG 2.1.

"Passing WCAG once means we are done."

No. Sites, apps, documents, content, and vendor products change constantly. DOJ says covered content and apps must continue to meet the requirements after the applicable compliance date.

A quick self-assessment

Title II digital accessibility readiness checklist

If several of these are unanswered, the most important next step is probably not another scan. It is building a program.

We know which compliance date applies to each covered public entity.
We have an inventory of public websites, subdomains, portals, apps, documents, media, and third-party digital services.
We have identified the public's highest-impact digital tasks and services.
We have an accessibility owner with authority to coordinate across departments.
We know which teams create or publish digital content.
Our design system and shared components have been manually accessibility tested.
Our forms can be completed by keyboard and assistive technology.
Our most important workflows have been tested end to end, not only page by page.
We combine automated testing with knowledgeable manual evaluation.
We test with assistive technologies relevant to the service.
We include disabled users in usability evaluation where appropriate.
We have a plan for PDFs and other electronic documents.
We have a repeatable process for captions and other media accessibility needs.
Accessibility requirements are included in procurement and contract language.
We independently evaluate vendor accessibility claims.
We have a method for receiving and resolving accessibility feedback from the public.
Accessibility defects have owners, priorities, target dates, and retest evidence.
New releases cannot bypass accessibility quality checks.
Content authors receive role-specific accessibility training.
We have a plan for ongoing monitoring after the compliance date.

Read the primary material

Primary and technical sources

This page is an educational briefing and implementation guide, not legal advice. For legal requirements, rely on the regulation and official DOJ materials.