ADA Title II Web & Document Compliance: The Complete Checklist

The Department of Justice’s ADA Title II rule on web and mobile accessibility is the first time state and local governments have had a specific technical standard, a specific scope, and a specific date on the calendar. The standard is WCAG 2.1 Level AA. The scope is the web content and mobile apps you provide or make available — including the documents posted on them. And the dates, as extended by the DOJ’s April 2026 interim final rule (Federal Register 2026-07663), are:

• April 26, 2027— public entities with a population of 50,000 or more
• April 26, 2028— public entities with a population under 50,000, and special district governments

If you run digital services for a city, county, state agency, public school district, or public college or university, this checklist walks through what needs to happen between now and your deadline — in the order that experienced teams do it.

1. Confirm your deadline and name an owner

Your deadline depends on population as determined by Census data, so confirm which tier your entity falls into rather than assuming. Special district governments — transit districts, water authorities, library districts — get the 2028 date regardless of the population they serve. Then assign a single accountable owner. Title II programs stall when accessibility is everyone’s shared responsibility and no one’s job; the entities making real progress have one person with authority to set priorities across departments.

2. Inventory everything the rule touches

You cannot remediate what you have not counted. Build a written inventory of:

• Every website and subdomain you provide — the main site, department microsites, the parks-reservation portal you forgot existed
• Vendor-hosted services that citizens use on your behalf: payment portals, permit systems, agenda-management platforms, learning management systems
• Mobile apps you offer to the public
• Documents posted on all of the above — PDFs, Word files, PowerPoints, spreadsheets. For most entities this is the largest and least visible category.

The vendor category surprises teams most. Content a third party provides for you— under contract or other arrangement — is generally your responsibility under the rule. “Our permit vendor built it” is not a defense; it is a procurement item (see step 7).

3. Run an automated scan to establish a baseline

Automated testing is the fastest way to size the problem. A crawler-based scan against the WCAG 2.1 A and AA rules will find missing alt text, contrast failures, unlabeled form fields, broken heading structure, and ARIA misuse across thousands of pages in hours. A tool like TheAccessibleAudit gives you a per-page, per-criterion baseline you can re-run monthly to measure progress.

Be honest with leadership about what automation covers: automated checks can verify only a portion of WCAG success criteria. A clean scan is necessary, not sufficient. Treat the scan as your triage map, not your compliance certificate.

4. Manually test your critical user journeys

Pick the five to ten tasks residents actually come to you for — pay a bill, apply for a permit, register for a class, find a polling place, request a record — and test each one end to end:

• Keyboard only. Unplug the mouse. Can you complete the entire task with Tab, Enter, and arrow keys, with a visible focus indicator the whole way?
• Screen reader. Run the journey with VoiceOver (macOS/iOS) or NVDA (Windows). Are form fields announced with their labels? Are errors read out?
• Zoom and reflow. At 200% browser zoom, does content reflow without horizontal scrolling or overlapping controls?
• Color and contrast. Is anything conveyed by color alone? Does body text meet 4.5:1 contrast?

Manual testing of a handful of journeys routinely finds blocking issues that automated scans rate as clean pages — a custom date picker that traps keyboard focus, a CAPTCHA with no accessible alternative, a multi-step form that loses screen-reader users at step two.

5. Deal with your documents

Documents are where most Title II programs are furthest behind. Every PDF posted on your site that people currently use to apply for or access your services must meet WCAG 2.1 AA — which for a PDF means real text (not a scan), a logical tag structure and reading order, alt text on images, labeled form fields, marked table headers, and a document language and title.

Triage rather than boiling the ocean: forms and currently-used documents first, high-traffic informational documents second. For many documents, converting to accessible HTML is faster and more durable than hand-remediating the PDF — TheAccessiblePDF automates exactly that conversion. And fix the pipeline, not just the backlog: train the people who publish documents to produce accessible source files, or the backlog regrows.

6. Apply the rule’s exceptions carefully

The rule contains limited exceptions — including archived web content, pre-existing conventional electronic documents that are not currently used to apply for or access services, certain third-party content you do not control, and certain individualized password-protected documents. Two cautions before you lean on them:

• The exceptions are narrow and conditional. A PDF form residents still use is not “pre-existing” in any way that helps you, and content only qualifies as archived if it meets the rule’s specific definition.
• An exception to the web rule is not an exception to the ADA. If a person with a disability needs excepted content, you still have Title II obligations to provide access.

Document every exception decision in writing, with the reasoning. Review each with counsel — this guide is not legal advice.

7. Fix procurement so new problems stop arriving

Every new website, platform, or app you buy either shrinks your problem or grows it. Update contract language now: require WCAG 2.1 AA conformance for anything public-facing, require an Accessibility Conformance Report (ACR) with bids, and reserve acceptance-testing rights. (Not sure what to ask vendors for? See our guide to VPATs vs. ACRs.)

8. Build a prioritized remediation plan

Combine the scan results, manual findings, and document triage into one plan with dates and owners. Prioritize by user impact, not by ease: blocking failures on critical journeys first, then high-traffic pages, then the long tail. A written, dated, actively-worked plan also matters if a complaint arrives before your deadline — it is the difference between “we are executing” and “we hadn’t started.”

9. Publish an accessibility statement and feedback channel

Post a public accessibility statement: the standard you target, known limitations, and a monitored way to report barriers (an email address a real person reads, with a response target). Many accessibility complaints start as an unanswered barrier report. A working feedback channel is your cheapest early-warning system — and the litigation climate rewards it: in 2025 alone, 8,667 ADA Title III lawsuits were filed in federal court (Seyfarth Shaw). Those target businesses rather than governments, but they show how actively digital accessibility is enforced through the courts.

10. Make it permanent

Compliance on deadline day is a snapshot; the obligation is ongoing. Before you declare victory:

• Schedule recurring automated scans and review the trend, not just the snapshot
• Add accessibility checks to your content-publishing workflow
• Train content authors annually — most regressions come from new content
• Re-run manual journey tests after major redesigns or platform changes

The short version

Confirm your date. Inventory everything, including documents and vendor platforms. Scan, then manually test what matters most. Triage documents and fix the publishing pipeline. Use exceptions narrowly and in writing. Put WCAG 2.1 AA in every contract. Work a prioritized plan, publish a statement, and keep monitoring after the deadline passes.