Accessible PDFs and ADA Title II: what the rule covers

Ask most public agencies where their accessible PDF problem under ADA Title II lives, and they will point to the archive: thousands of old reports, minutes and forms on the website. That is part of it. The larger and less visible part is the documents being produced today, many of them by software you bought.

This post covers how the DOJ's Title II web rule treats documents, what the exceptions do and do not cover, and why a vendor's VPAT often says nothing about the documents its product generates.

Accessible PDFs: documents are web content

The rule (28 CFR part 35, subpart H) requires web content and mobile apps to conform to WCAG 2.1 Level AA from 26 April 2027 for entities of 50,000 or more, and 26 April 2028 for smaller entities and special district governments.

"Web content" is defined to include "conventional electronic documents", and those are defined by file format:

• portable document format (PDF) files;
• word processor files;
• presentation files; and
• spreadsheet files.

The proposed rule had also listed database file formats; the final rule dropped them. The list is exhaustive. The DOJ chose a fixed list of formats over a flexible definition because, in its words, a more flexible definition "would result in less predictability".

The standard for these documents is the same as for web pages: WCAG 2.1 Level AA. The rule does not adopt a separate document standard such as PDF/UA. The DOJ acknowledged that some WCAG criteria do not apply to documents exactly as written, declined to carve out exceptions, and pointed entities to the W3C's guidance on applying WCAG to non-web documents and software (WCAG2ICT).

The preexisting-document exception, and its limit

Under 28 CFR 35.201(b), conventional electronic documents that were available on an entity's web content or mobile apps before its compliance date do not have to conform, "unless such documents are currently used to apply for, gain access to, or participate in the public entity's services, programs, or activities."

That final clause does a lot of work. The DOJ's own example in the rule's preamble: a preexisting PDF application for a business license generally must conform if it is still in use. So must other preexisting documents needed to obtain the license or understand the process, such as instructions, manuals, sample tests and question-and-answer guides.

Two practical consequences:

• The exception does not reach new documents. Anything posted after your compliance date must conform. That includes next month's agenda packet and every PDF a vendor system publishes on your behalf.
• "Old" is not a safe harbor if the document is live. Forms, fee schedules, application guides and permit instructions that people still use are covered, whatever their creation date.

Archived web content has its own, separate exception (35.201(a)), with conditions: among them, the content must be retained exclusively for reference, research or recordkeeping, and not altered or updated after archiving. The ADA Title II exceptions post walks through all five exceptions.

Individualized documents behind a login

A second exception, 35.201(d), covers conventional electronic documents that are both about a specific individual, their property or their account, and password-protected or otherwise secured. Think utility bills, tax statements or test results delivered as PDFs in a portal.

The limits are easy to miss:

• It covers documents, not the portal. The preamble states that the exception "would not apply to the platform on which the public entity makes those documents available." The login pages, account screens and download links must conform.
• It covers the listed formats only. If the same individualized information is shown as an HTML page rather than a PDF, the exception does not apply.
• Existing obligations remain. The DOJ notes that entities still have Title II obligations to provide accessible versions of these documents, in a timely manner, to individuals with disabilities who need them. The exception removes the duty to make every such document conform in advance. It does not remove the duty to respond.

That last point matters for vendor selection. If your billing or records system cannot produce an accessible version of a statement on request, the exception will not help you when the request arrives.

Documents your vendors' software produces

Much of what an agency publishes is generated by systems, not written by staff:

• agenda and minutes software that assembles meeting packets;
• permitting and licensing systems that issue permits, notices and receipts;
• payment and billing platforms that generate invoices and statements;
• reporting tools that export PDFs and spreadsheets to the public website;
• form builders that output fillable PDFs.

The rule covers web content an entity provides "directly or through contractual, licensing, or other arrangements". A PDF that a vendor's system generates and publishes for you is your web content. The third-party content exception in 35.201(c) does not help either: it excludes content posted by a third party "unless the third party is posting due to contractual, licensing, or other arrangements with the public entity."

Federal guidance treats this the same way from the Section 508 side. Section508.gov's advice on business partners says electronic documents "such as training, user guides, ongoing status reports, and invoicing, must be accessible," and recommends building the requirement into the agreement.

What a VPAT does and does not tell you about documents

A conformance report usually describes the product's interface: the screens your staff and the public click through. Whether it addresses documents depends on the edition and on how carefully the vendor scoped it.

• WCAG edition. The conformance table covers the product. Generated documents are only covered if the vendor says so, typically in the notes or the remarks. Most reports do not.
• Section 508 edition. Each WCAG row has separate remarks fields for Web, Electronic Docs, Software and Authoring Tool, and Chapter 6 covers support documentation (602.3 requires electronic support documentation to conform to WCAG 2.0 AA). Read the Electronic Docs remarks: are they filled in, and do they describe output documents or only the help manual?
• Authoring features. If staff build documents inside the product (agenda items, notices, templates), the question is also whether the tool lets them produce accessible output: headings, alternative text, table structure, reading order, document language.

When a report is silent on generated documents, silence is not conformance. Ask directly.

Questions to ask the vendor

1. Which documents does the system generate for the public or for publication, and in what formats?
2. Are generated PDFs tagged, with a logical reading order, document title and language set? Have they been tested with a screen reader?
3. Do generated tables have proper header markup? Do charts have text alternatives?
4. Can the system produce an accessible version of an individualized document (a bill, a statement) on request, and how quickly?
5. Can staff-authored content carry headings, alt text and table structure into the output?
6. Where is this covered in your ACR? If it is not, will you add it?

Put the answers in writing, and consider making the important ones contract terms. The contract language post has suggestions to take to counsel.

Where to start

Inventory before you remediate. Separate documents that are preexisting and not in active use from those people still rely on, and separate documents you author from documents your systems generate. The first group may wait. The second group is your current exposure, and the third is best fixed once at the source, in the vendor's product, rather than one PDF at a time.

---

Sources: 28 CFR 35.104 (definitions) and 35.200–35.201 (the DOJ's 2024 Title II web rule, as amended in April 2026), and the rule's preamble at 89 FR 31320; ITI VPAT 2.5Rev 508 edition template; Revised Section 508 Standards, 602.3; Section508.gov, "Requiring Business Partners to Provide Accessible Documents". This is general guidance, not legal advice.

GOVvpat reviews vendor reports for what they say, and do not say, about the documents a product generates. Request a quote.