ADA Title II readiness checklist for digital documents

Who this is for

This checklist is written for the people who actually own digital documents at a state or local public entity: ADA and 504 coordinators, web and communications teams, IT directors, and the administrators who sign off on compliance. It focuses on the document layer (PDFs, Word, Excel, PowerPoint), which is where most public entities have the largest backlog and the least tooling.

It is general guidance, not legal advice. For the underlying rule and who is covered, see who must comply and rule status.

What counts as a document

The ADA Title II web rule covers web content and the documents published through it. In practice the files that matter most are the ones the public actually uses:

• Board and committee agendas, packets, and minutes
• Course catalogs, class schedules, and program guides
• Public-facing forms and applications
• Financial reports, budgets, and audits
• Policies, notices, and public records posted as PDFs

The technical target is WCAG 2.1 Level AA, applied to the content of the document itself (Source: 28 CFR § 35.200 ) .

The deadlines

Compliance dates are keyed to the population the entity serves. The larger group by entity count is on the April 2027 date. For the full breakdown and edge cases, see deadlines.

The 10-point checklist

Use this to gauge readiness for a single document, a template, or a whole library. If you can't answer yes to a point, that's a gap worth logging.

1. Inventory. Do you have a list of the public documents on your site, with owners and roughly how many there are?
2. Tagged structure. Do PDFs have a real tag tree (headings, paragraphs, lists) rather than just looking right visually?
3. Reading order. Does the content read in a logical order with assistive technology, not just left to right by position?
4. Alt text. Do meaningful images, charts, and logos have alternative text, and are decorative images marked as decorative?
5. Tables. Are data tables marked up with header rows and cells, so a screen reader can announce them?
6. Links. Do links have descriptive text rather than bare URLs or "click here"?
7. Language and title. Is the document language set and a real title present in the file properties?
8. Color and contrast. Does text meet contrast minimums, and is color never the only way information is conveyed?
9. Forms. Do interactive forms have labeled fields and a logical tab order?
10. Validation. Has the file been checked against WCAG 2.1 AA and PDF/UA, ideally with a human using assistive technology, not an automated checker alone?

How to prioritize

Most teams can't remediate everything at once, and they don't need to. A defensible approach is to work by use and risk rather than trying to boil the ocean:

• Highest use first. The handful of documents the public opens most (catalogs, current forms, recent board materials) carry the most exposure.
• New before old. Fix the authoring templates and the publication workflow so new documents go out accessible, then work backward through the archive.
• Document the plan. A written, dated remediation plan and progress record generally helps with both enforcement posture and internal reporting.

Common mistakes

• Posting a separate "accessible version." Under the rule, the original document itself generally needs to be accessible; a separate alternate file is usually not enough.
• Relying on an accessibility overlay or widget. Overlays generally don't make posted documents conformant, and they aren't treated as meeting WCAG on their own. See do accessibility overlays comply with ADA Title II?
• Automated-only remediation. Auto-tagging tools speed things up but typically leave reading-order, alt-text, and table issues that need a human pass.
• Waiting for the deadline. A large document backlog takes time; starting the inventory now is usually the cheapest move.