ADA title II web and mobile accessibility

Title II makes digital accessibility legally enforceable for public sector organizations. If your websites, mobile apps, and posted digital documents don’t conform to WCAG 2.1 Level AA, you may be out of compliance with the DOJ’s Title II web/mobile accessibility requirements.

This guide shows you how to build compliance that sticks when your accessibility lead quits, your vendor delivers noncompliant work, or you’re suddenly managing five new sites.

Here’s what we’ll cover:

• Mapping Title II requirements across websites, mobile applications, and electronic documents
• Converting WCAG 2.1 AA standards into testable compliance checkpoints
• Aligning accessibility deadlines with budget cycles and program planning
• Building governance frameworks that scale across content teams and vendors

First, let’s break down what Title II requires and why WCAG 2.1 AA matters for the content you’re publishing right now.

What’s the new ADA Title II web accessibility rule?

The Department of Justice’s (DOJ’s) ADA Title II update states that public entities need to make their web content meet WCAG 2.1 AA (Web Content Accessibility Guidelines) standards.

Published in April 2024, this update closes a gap that has existed since 1990. When the Americans with Disabilities Act (ADA) became law, no one was worried about websites. Now your entire operation lives online, and the DOJ finally caught up.

Title II of the ADA covers state and local government services, e.g., city websites, public library systems, state university portals, and transportation departments. If your organization is funded by taxpayers, this is for you.

Before the update, accessibility guidelines were vague. “Make it work for everyone” didn't mean much when you were staring at a fillable PDF form that needed fixing. Now you've got WCAG 2.1 AA, with 50 specific success criteria you can test against. Does your color contrast hit 4.5:1? Can someone navigate your site with just a keyboard? Do your forms tell screen reader users what went wrong when they make a mistake?

The rule covers public-facing websites, mobile app experiences, and digital content, including conventional electronic documents. PDFs, online forms, embedded maps, videos, third-party widgets — if someone needs it to access your services, it's in scope.

There are exceptions to be aware of: Subpart H includes explicit carve-outs. Depending on how the content is used, exceptions can include certain archived content, some preexisting conventional electronic documents, some individualized password-protected documents, and preexisting social media posts, among others. For example:

• Certain archived web content
• Some conventional electronic documents posted before your compliance date, unless they’re currently used to apply for access or participate in services, programs, or activities
• Third-party content unless it’s posted under a contractual, licensing, or other arrangement with the public entity
• Individualized, password-protected (or otherwise secured) conventional electronic documents in certain circumstances
• Preexisting social media posts (depending on timing and context)

Compliance deadlines are split by population served:

• April 24, 2026: Entities serving populations of 50,000 or more
• April 26, 2027: Entities serving populations under 50,000 and special district governments

Don't wait until month 23 to start. Complaints filed before your deadline still need responses.

What is the DOJ's mandate?

In practice, compliance isn’t just about fixes—it’s also about showing that accessibility is managed over time. If a complaint leads to an investigation, you may be asked to provide documentation of how issues were identified, prioritized, and remediated.

Enforcement mechanisms

Complaints trigger investigations, which can lead to corrective action plans or consent decrees that lock you into specific timelines with federal oversight. Don’t bank on informal notice or a long grace period; some complaints move fast from intake to deadlines, and you may be expected to produce a remediation plan early in the process.

Documentation requirements

Accessibility statements aren’t explicitly required by the new Title II web/mobile rule, but publishing one is a practical best practice: share your conformance status, how people can request help or file complaints, and known issues you’re working on. During an investigation, the DOJ (or another designated agency) may request documentation. If you can’t produce documentation showing how you’ve handled accessibility, that becomes part of the problem.

Mandates for planning and resourcing

One-time audits won't cut it. The DOJ expects ongoing processes: budgets for accessibility work, clear ownership of who's responsible, content governance that catches issues before they go live, vendor contracts with accessibility requirements, and staff training.

Your accessibility plan needs to cover all of it. Claims of “We're working on it” without a system to back that up won't hold up during an investigation.

Why digital accessibility is a civil right

Internet accessibility lets people with disabilities participate in civic life the same way everyone else does. When your website doesn't work for someone, you've locked them out of services they're entitled to.

Civil rights law and equal access

Wheelchair ramps exist because buildings without them exclude people. Digital accessibility works the same way. A screen reader user who can't complete your benefits form faces the same barrier as someone in a wheelchair facing stairs with no ramp. The law recognizes both as civil rights violations.

Real impacts on critical services

Here's what broken accessibility looks like in practice:

Examples of accessibility barriers and their impact on critical public services

Service	Barrier	Result
Benefits enrollment	Forms that don't work with screen readers	People miss application deadlines or give up entirely
Emergency alerts	Videos without captions	Deaf residents don't get evacuation notices
Online permits	Color-only error indicators	Colorblind users can't figure out what they did wrong
Public meetings	PDFs that break assistive tech	People can't review agendas or comment on proposals

70 million American adults live with a disability. When your site doesn't support keyboard navigation, screen readers, or captions, you're excluding a significant portion of the people you're supposed to serve.

Accessible UX patterns aren't extras. They're how you provide the equal access civil rights law requires.

Who must comply with Title II?

If you're a public entity, you're covered. The list of covered entities extends to state agencies, county and city governments, public school districts, universities, libraries, transportation authorities, parks departments, public hospitals, housing authorities, and courts. Even that tiny department managing your town's website from a laptop in the storage closet counts.

The programs you run, contractors you hire, and organizations you fund all fall under your compliance umbrella. Hire someone to build your website or manage your digital services, and they need to deliver WCAG 2.1 AA-compliant work. If what they build doesn't meet standards, you're still the one answering to the DOJ. 

The same principle often applies when a nonprofit (or any third party) is delivering services, programs, or activities on the public entity’s behalf—or when the public entity provides or makes that content available through a contractual, licensing, or similar arrangement. In those cases, vendor- or partner-delivered digital experiences can still create Title II risk if they aren’t accessible.

Internally, compliance splits across multiple teams:

Internal teams and typical responsibilities for Title II digital accessibility compliance

Team	Responsibility
IT/Web teams	Technical infrastructure, CMS configuration, testing tools
Communications	Content creation, document remediation, social media
Service delivery	Forms, applications, program-specific tools
Procurement	Vendor requirements, contract language, compliance verification
Legal/Compliance	Policy, training, complaint handling, documentation

Nobody gets to claim ignorance or defer to someone else. Title II compliance requires all these teams to work together.

What are public entities?

Public entities are any state or local government units providing programs or services to the public, including city councils, state departments, and school boards. This definition also extends to water districts, housing authorities, transit agencies, planning commissions, and even quasi-governmental bodies, such as regional development corporations, if they deliver public services. 

Shared digital platforms count, too. Multi-agency portals where residents pay bills, apply for permits, or access services across departments need to be accessible.

The same goes for interagency systems, such as an unemployment portal run by three state departments or a regional library catalog spanning five counties. One noncompliant platform can create violations across multiple entities, so shared infrastructure needs extra attention in your compliance planning.

What are the implications for public education (universities, K-12)?

Universities and K-12 systems have complicated digital ecosystems that all need to meet WCAG 2.1 AA. Every platform students and parents interact with (e.g., learning management systems, student information systems, admissions portals, and library databases) falls under Title II.

Here's where it gets messy: course materials. That PDF your biology professor uploaded to Canvas in 2019? The lecture recording with auto-generated captions that say “mitochondria” as “mighty chondria?” The worksheet parents download for homework help? All of it needs captions, transcripts, proper tagging, or accessible alternatives. You can't let faculty treat the learning management system like a digital filing cabinet where anything goes.

Procurement is where you either save yourself or create years of cleanup work. That new edtech tool looks great in the demo, but ask for their Voluntary Product Accessibility Template (VPAT) before you sign anything. A vendor can't prove WCAG 2.1 AA conformance? Walk away. Fixing someone else's inaccessible product after you've already paid for it and rolled it out to 50,000 students costs far more than choosing the right tool from the start.

What's the impact on libraries and other government services?

Libraries face a particular challenge because so much of what they offer lives in third-party systems. Most catalog software, discovery layers, e-book platforms, and archived web content from digital newspaper archives come from vendors who may or may not have prioritized accessibility. You need to audit all of it against WCAG 2.1 AA and push vendors to fix what's broken.

Physical public kiosks matter, too. Touchscreen catalog stations and self-checkout terminals need accessible interfaces: screen reader compatibility, keyboard navigation, and adjustable text size. Someone who can't use a touchscreen still needs to check out books.

Note: kiosks aren’t covered by the new Subpart H web/mobile technical standard, but they can still trigger Title II obligations under program access and effective communication.

The same principles apply to other civic services, such as online permitting systems, payment portals for utilities, park shelter reservation tools, and parking ticket payment sites. If the public uses it to interact with your services, it needs to be accessible. It doesn't matter if you built it in-house or bought it from a vendor; it's your responsibility.

A step-by-step plan for achieving Title II compliance

Compliance needs a system: audit what's broken, fix it in priority order, control what vendors deliver, and train your team to keep things accessible. Here's how to build that system so it sticks.

Step 1: Conduct a comprehensive digital accessibility audit

A full-scope audit shows you where you stand, what's putting you at legal risk, and what needs fixing first.

Start with automated scans. There are many digital tools, including Siteimprove.ai, that catch the obvious stuff (e.g., color contrast failures, missing alt text, and broken ARIA labels) fast. However, automated tools can’t catch all accessibility issues, so manual testing is essential, too. Tab through your forms with just a keyboard. Fire up a screen reader and try to complete a task. Watch someone who uses assistive technology interact with your site if you can.

Quantify everything by severity, traffic, and impact. A broken contact form on your most-visited page? Critical. An outdated PDF buried three clicks deep that gets 12 views a year? Still needs fixing, but later. Tag issues by component type (e.g., navigation, forms, media, and documents) so you can fix patterns across your site instead of one-off problems.

The output should be a backlog with clear owners, time estimates, and service level agreements. Your content team owns document remediation. Design owns color and layout fixes. Development owns form validation and keyboard navigation.

Step 2: Prioritize remediation and create a road map

Prioritized remediation waves let you show progress fast while knocking out your biggest legal risks first.

Group issues into themed sprints instead of scattering fixes randomly across your site. One sprint tackles every form validation problem you've got. Another fixes video captions. Another remediates your most-downloaded PDFs and other electronic documents. Why? Because fixing patterns at scale beats playing whack-a-mole with individual pages for the next three years.

Another approach is to consider actual user journeys when you're planning sprints. Someone applying for unemployment benefits touches five different pages and two forms. Make that entire path accessible in one go instead of fixing the application page in Q1, the confirmation page in Q3, and wondering why you're still getting complaints in Q4.

Critical tasks, such as paying water bills, submitting permit applications, and accessing food assistance, jump the line ahead of your events calendar.

Set quarterly goals you can actually measure and show leadership. “Reduce critical errors by 60 percent” gives you a number to hit. “Make all top-20 landing pages WCAG 2.1 AA compliant” gives you a checklist you can prove.

Step 3: Vet and manage third-party vendor accessibility

Vendor controls keep you from inheriting someone else's accessibility disaster and then scrambling to fix it when you're already up against your deadline.

Ask for current VPATs or Accessibility Conformance Reports before you sign anything. These documents spell out exactly what works and what doesn't. The vendor can't produce one? Red flag. Their VPAT shows major conformance gaps? Either negotiate fixes with timelines or find a different vendor. Marketing copy that says “we're committed to accessibility” means absolutely nothing.

Include WCAG 2.1 AA conformance in your contracts: deadlines for fixing issues, indemnification clauses if their inaccessible product gets you sued, and termination rights if they don't deliver.

Test vendor tools in staging before they reach production. Just because a vendor swears an embedded chat widget, form builder, payment processor, map tools, or calendar system is accessible doesn't mean it will work the way you've implemented it. Discovering your new permit application form breaks screen readers after 500 people have already tried to use it is not the learning experience you want.

Step 4: Implement staff training and ongoing monitoring

Training and continuous monitoring turn accessibility into something your team does automatically, not something they remember when Legal forwards a complaint.

Train people on their specific responsibilities, not generic disability awareness. Content creators need to know how to write useful alt text and structure headings that make sense to screen readers. Designers must understand color contrast ratios, focus indicators, and why 9-pixel touch targets make everyone miserable. Developers need to know ARIA, keyboard navigation, and how to build form errors that assistive technology can actually announce.

Build accessibility compliance checks into the work itself, such as automated tests in your deployment pipeline that block code with new violations from going live, content approval workflows that require someone to verify basics before publishing, and browser extensions that flag issues while people are drafting content. Make the accessible option the default option, and compliance gets easier.

Set up monitoring that shows you problems in real time, not during your annual panic audit:

• Dashboards that track error counts by severity and page type
• Alerts for when critical issues appear
• Clear paths for routing user complaints to whoever can actually fix them

Finally, quarterly check-ins can catch small problems before they become big ones. You'll sleep better knowing you're not building up an invisible backlog of violations.

What are the consequences of noncompliance?

Noncompliance triggers DOJ investigations, legal costs, mandatory corrective action plans, and the kind of public attention nobody wants.

Complaints lead to investigations that can result in consent decrees: legally binding agreements that lock you into specific remediation timelines with federal oversight. You'll report progress on a schedule the DOJ sets, not yours. They can require third-party monitoring, mandate regular audits, and keep you under supervision for years. Some settlements and consent decrees include multi-year monitoring and structured deadlines, depending on the scope of the issues and the resolution terms.

The financial hit compounds the longer you wait. Fix accessibility proactively, and you're paying for audits, training, and systematic remediation. Wait until you're under a consent decree, and you're paying for all of that, plus legal fees, settlement costs, potential damages, and rush fees to fix everything under compressed timelines. Organizations often find that remediation becomes significantly more expensive when issues are discovered late—especially if deadlines compress work into a short window or require outside support.

Then there's the damage to your reputation. Public consent decrees make the news. Every complaint filed becomes public record. Being the government entity that locked out people with disabilities from public services isn’t exactly the headline you want when you're trying to build community trust.

A more inclusive digital future

Title II compliance keeps you out of DOJ investigations, sure. But the bigger point is that 70 million Americans with disabilities shouldn't have to fight through broken websites just to pay a parking ticket or apply for benefits.

The work list is long. Audits, remediation backlogs, vendor contracts that need accessibility clauses, and training so your team stops creating new problems while you're fixing old ones. Starting with a plan now beats the alternative: your deadline arrives, you're nowhere near compliant, and every choice you make costs more because you're doing it under pressure.

siteimprove.ai catches accessibility issues before they go live, tracks your progress across every site you manage, and gives you the proof you need when someone (e.g., your legal team, your CIO, or the DOJ) asks where you stand on compliance.

Want to see how website accessibility monitoring works? Request a demo, and we'll show you how public sector teams maintain WCAG 2.1 AA compliance without turning accessibility into everyone's second full-time job.