The Municipal PDF Problem: Your Site Passes but Your Documents Don't

The Blind Spot

If you have been following this series, you have done the work. You know the regulatory deadline. You understand why overlay widgets will not save you. You have read RFP accessibility requirements and know what procurement officers are looking for. You have studied the 2025 lawsuit data, built your audit defense log, run through the 75-day checklist, fixed the six violations plaintiff attorneys target first, and prepared for what happens the day after April 24.

But there is a very good chance that everything you have scanned, fixed, and documented covers only part of what the Title II rule actually requires. Because most accessibility scanning tools — and most contractors — focus almost entirely on HTML pages. And municipalities do not run on HTML pages alone. They run on PDFs.

Permit applications. Meeting minutes. Budget documents. Zoning maps. Engineering drawings. Council agendas. Public notices. Fee schedules. Annual reports. Emergency plans. Bid tabulations. Ordinances.

Every one of these documents is in scope under the DOJ's Title II rule. Every one of them must conform to WCAG 2.1 Level AA. And the vast majority of them — on virtually every municipal website in the country — are completely inaccessible to screen readers.

This is the compliance gap that will generate demand letters after April 24. Not because the HTML pages fail, but because the document libraries behind them were never tested at all.

What the Rule Actually Says About Documents

The DOJ's final rule defines "web content" broadly. Under 28 CFR § 35.104, web content includes text, images, sounds, videos, controls, animations, and conventional electronic documents. The rule defines conventional electronic documents as content in portable document formats (PDFs), word processor file formats, presentation file formats, and spreadsheet file formats.

This is not ambiguous. PDFs hosted on a municipal website are web content under the rule. They must conform to WCAG 2.1 Level AA just like the HTML pages that link to them.

The rule does include a limited exception for preexisting conventional electronic documents under § 35.201(b). A PDF posted before the compliance date is exempt — unless it is currently used to apply for, gain access to, or participate in the public entity's services, programs, or activities. That exception is far narrower than most people assume.

A permit application form? Used to apply for a service. Not exempt.

Council meeting minutes from 2024 that are still linked from an active meeting archive? Used to participate in the entity's activities. Almost certainly not exempt.

A fee schedule that residents reference to determine what they owe for a building permit? Used to gain access to a service. Not exempt.

A flyer for a 2022 holiday parade that no one has looked at in three years and that sits in a clearly labeled archive section? That might qualify for the exception. But the DOJ has made clear that the intent is to minimize the number of inaccessible documents, not to provide a loophole for avoiding remediation.

And here is the part that matters most for contractors: even when the preexisting document exception applies, if an individual requests that document in an accessible format, the municipality must still provide it under its existing Title II obligations. The exception only exempts the document from the technical standard requirement — it does not eliminate the municipality's duty to provide equal access.

For any document you created, converted, or uploaded on behalf of a municipal client, the accessibility of that document is part of your deliverable. If your contract includes accessibility warranties — and as we covered in the RFP post, more contracts do every month — the warranty covers documents, not just pages.

Why Standard Scanners Miss the Problem

When you run an automated WCAG scan on a municipal website, the tool crawls the HTML pages. It checks contrast ratios, alt text, heading structure, form labels, link text, and ARIA attributes across the site's page structure. If the scan comes back with a manageable list of issues and you fix the six high-priority violation categories, you might conclude that the site is in reasonable shape.

But that scan did not open a single PDF. It did not check whether the 347 documents in the city's document library have tags, reading order, alt text, or defined languages. It did not verify that the permit application form is navigable by keyboard. It did not test whether the council agenda's table of contents actually works with a screen reader. The scanner saw a link to a PDF and kept crawling HTML.

This creates a false sense of compliance. The scan report shows a passing score on the pages. The pages link to hundreds of documents that have never been tested. And when a plaintiff attorney or a DOJ investigator follows those links, they find exactly what the scan missed.

The common PDF accessibility failures are well documented and nearly universal on municipal sites. They fall into a predictable set of categories.

Untagged PDFs. A PDF without tags is, from an assistive technology perspective, a blank page. Screen readers cannot identify headings, paragraphs, lists, or reading order. The most common source of untagged PDFs on municipal sites is documents that were printed to PDF or exported from legacy systems without any accessibility consideration. A University of Melbourne survey found that only about 13% of respondents considered PDFs accessible — and on municipal sites, where documents are often generated by staff without accessibility training, the number is likely far lower.

Scanned image PDFs. When a paper document is scanned and uploaded as a PDF, the resulting file is a series of images. There is no text for a screen reader to interpret. Without optical character recognition (OCR) processing, the document is completely invisible to assistive technology. Municipal sites are full of these — legacy ordinances, signed resolutions, historical records, and any document that originated on paper before the digital era.

Missing or incorrect reading order. Even when a PDF has tags, the reading order may not match the visual layout. Multi-column documents, sidebars, headers, and footers can cause a screen reader to jump between columns or read content out of sequence. For a budget document with columns of figures or an engineering report with callout boxes, incorrect reading order makes the content unintelligible.

Missing alt text on images. Charts, graphs, maps, diagrams, logos, and photographs embedded in PDFs require alternative text descriptions. Without them, a screen reader user encounters unnamed images throughout the document. On municipal sites, this affects everything from organizational charts to zoning maps to site plan illustrations.

Inaccessible form fields. PDF forms — the kind residents use to apply for permits, file complaints, or submit requests — need labeled, navigable form fields that work with keyboard input and screen readers. Most PDF forms on municipal sites were created without these labels, making them unusable for anyone who cannot see the visual layout.

Missing document language. If a PDF does not declare its language in the document properties, screen readers may mispronounce text or apply incorrect reading rules. This is a metadata setting that takes seconds to fix but is almost never set in documents generated by municipal staff or exported from government systems.

How to Triage the Document Backlog

With 53 days until the deadline, you are not going to remediate every PDF on every municipal site you have built. You should not try. The goal is the same as it has been throughout this series: prioritize the highest-risk items, fix what matters most, document everything, and establish a process for ongoing compliance.

Here is how to approach the document problem systematically.

Step 1: Inventory the documents you are responsible for. Go back to the deliverable inventory you built in the 75-day checklist. For each municipal project, identify not just the pages and applications, but the documents. How many PDFs did you create, upload, or build a system to generate? How many are still actively linked? How many are used to apply for, gain access to, or participate in the municipality's services?

Step 2: Categorize by function and risk. Not all documents carry the same litigation risk. Prioritize in this order:

Documents used to apply for services — permit applications, registration forms, license applications, complaint forms. These are the documents a plaintiff attorney will test first, because denying access to a government service application is the clearest possible ADA violation.

Documents used to participate in government — council agendas, meeting minutes, public hearing notices, budget documents. These are the records that define how residents engage with their government, and they are explicitly within the rule's scope.

Documents used to access information about services — fee schedules, program descriptions, eligibility criteria, policy documents. These enable access to government services and are unlikely to qualify for the preexisting document exception.

Legacy and archival documents — historical records, past event materials, superseded policies. These may qualify for the preexisting document exception if they meet all the criteria and are stored in a clearly designated archive area. These are lowest priority for remediation.

Step 3: Run accessibility checks on the high-priority documents. Adobe Acrobat Pro includes a built-in accessibility checker that will identify untagged content, missing alt text, reading order issues, missing language declarations, and inaccessible form fields. It is not a substitute for manual testing with a screen reader, but it gives you a structured report of the most critical failures. For each document you check, record the findings in your audit defense log.

Step 4: Fix what you can, flag what you cannot. Some PDF accessibility fixes are quick. Setting the document language is a single property change. Adding alt text to a handful of images is straightforward. Tagging a simple text document is manageable with the reading order tool in Acrobat Pro.

Other fixes are not quick. Remediating a 40-page scanned document requires OCR processing and full tagging from scratch. A complex engineering drawing with layered annotations may need to be recreated or supplemented with an accessible alternative. For documents that cannot be remediated in time, document the issue, note the plan for remediation, and ensure the municipality has a process for providing accessible alternatives upon request. That documented plan — with dates, responsible parties, and specific actions — is what the DOJ looks for when evaluating good faith.

Step 5: Address the pipeline, not just the backlog. The most important long-term action is ensuring that new documents are accessible when they are created, not remediated after the fact. If you manage a CMS for a municipal client, the document upload workflow should include an accessibility check. If your deliverable includes templates that municipal staff use to create documents, those templates need to be structured for accessibility from the start — with styles mapped to proper heading tags, alt text fields for images, and language properties set by default.

This is where the contractor's role shifts from remediation to infrastructure. A municipality that has accessible templates, a document accessibility checklist for staff, and a review process before publication will generate far fewer inaccessible documents going forward than one that produces documents the same way it always has and tries to fix them later.

The Contractor Advantage

Most contractors in the municipal space are not thinking about document accessibility at all. They are focused on pages, applications, and interactive components. The 2025 litigation data and the predictions for 2026 make clear that plaintiff firms are expanding into government targets — and document-heavy operations are explicitly identified as high-risk.

If you can demonstrate document accessibility capability in your next RFP response — not just web page compliance, but a documented process for ensuring PDFs, forms, and published documents meet WCAG 2.1 Level AA — you are ahead of virtually every competitor in the space. Include your document accessibility methodology alongside your web scanning process. Show sample audit defense log entries that cover document remediation. Reference the specific WCAG criteria that apply to PDF accessibility and describe how you test against them.

When a procurement officer reads ten proposals and nine of them describe web page accessibility only, the one that addresses the full scope of the Title II rule — pages, applications, and documents — will stand out. Because that procurement officer knows exactly how many PDFs are on their site. They know the deadline is coming. And they know that most of those documents have never been tested.

Fifty-Three Days

The April 24 deadline is 53 days away. Your HTML pages may be ready. Your scan reports may be clean. Your audit defense log may be growing. But if the document libraries on the sites you have built are full of untagged, scanned, inaccessible PDFs, then your compliance story has a hole in it — and it is exactly the kind of hole that generates complaints.

Start with the inventory. Prioritize the documents that enable access to services. Check them, fix the critical failures, document the work, and build the process that prevents the problem from recurring. The contractors who address the PDF problem before someone files a complaint are the ones who will still be winning municipal bids after the deadline passes.

---

This post is for informational purposes only and does not constitute legal advice. Consult with qualified legal counsel for guidance specific to your situation.