The Municipal Contractor's Guide to Accessible PDFs

The Document Everyone Forgets

When municipal contractors think about ADA compliance, they think about websites. They audit the homepage, fix the navigation, add alt text to images, run a contrast checker. That work matters — the six most common WCAG violations all live in web content.

But there is a massive blind spot in that approach, and plaintiff attorneys know exactly where it is.

PDFs.

Every municipality runs on PDFs. Council meeting agendas. Budget presentations. Permit applications. Zoning maps. Public hearing notices. Annual reports. Tax forms. Water quality reports. Emergency management plans. These documents are generated constantly, uploaded to government websites routinely, and tested for accessibility almost never.

Federal data indicates that 77% of documents downloaded from government websites are PDFs, but only about 20% of those PDFs meet accessibility standards. That gap represents thousands of documents per municipality — each one a potential barrier for residents with disabilities and a potential exhibit in a complaint.

The DOJ's Title II rule does not distinguish between web pages and documents. If a PDF is posted on a government website and used for services, programs, or activities, it must conform to WCAG 2.1 Level AA. The only exception is narrow: pre-existing documents posted before the compliance deadline that are retained exclusively for archival purposes, clearly marked as archived, and never updated. Active documents — the ones residents actually use — have no exemption.

With 46 days until the deadline, this is the deliverable most likely to be non-compliant in your portfolio. Here is how to find the problems and fix them.

Why PDFs Are Uniquely Difficult

Web pages are built on HTML, a language designed to be parsed by machines. A screen reader can traverse the DOM, identify headings, read link text, and navigate form fields because HTML was built for structured content.

PDFs were not. The Portable Document Format was designed to preserve visual layout across devices — to make a document look the same everywhere. That visual fidelity comes at a cost: without deliberate structural work, a PDF is just a picture of text. A screen reader cannot distinguish a heading from body copy, cannot identify table relationships, cannot determine reading order, and cannot interact with form fields.

Making a PDF accessible requires adding a parallel layer of structural information — a tag tree — that tells assistive technology what each element is, how it relates to other elements, and in what order it should be read. This tag tree must be built correctly at creation or added during remediation. There is no CSS trick, no overlay widget, and no automated tool that reliably handles this for complex documents.

This is why PDFs are the compliance gap plaintiff attorneys target. The barriers are real, the failures are provable, and most organizations have not even started addressing them.

The Seven PDF Failures That Show Up in Complaints

Not every PDF accessibility issue carries equal litigation risk. These are the failures that automated checkers flag, that screen reader users encounter as barriers, and that appear in ADA complaints — roughly ordered by how often they occur and how easy they are to detect.

1. No Tag Structure at All

An untagged PDF is the equivalent of a web page with no HTML — just rendered pixels. Screen readers cannot parse the content, identify structure, or provide navigation. The document is completely inaccessible. This is the most common failure and the most damaging in a complaint because it demonstrates zero effort toward accessibility.

How to check: Open the PDF in Adobe Acrobat Pro. Go to File → Properties → Description. If it says "Tagged PDF: No," the document has no tag structure. You can also run Acrobat's built-in accessibility checker: All Tools → Prepare for Accessibility → Check for Accessibility.

How to fix: If the document was created from a properly structured source file (Word, InDesign, Google Docs), re-export with the "Tagged PDF" option enabled. If the source file is unavailable or unstructured, use Acrobat Pro's "Autotag Document" feature as a starting point, then manually review and correct the tag tree.

2. Incorrect or Missing Reading Order

Even when tags exist, the reading order may not match the visual layout. This is especially common in multi-column documents, documents with sidebars, and pages with headers, footers, and pull quotes. A screen reader follows the tag tree order, not the visual position — so if the tags are sequenced incorrectly, a user hears the sidebar content in the middle of a paragraph, or the footer before the main text.

How to check: In Acrobat Pro, open the Tags panel (View → Show/Hide → Side Panels → Accessibility Tags) and read through the tag tree sequentially. Does the order match how a sighted reader would naturally read the page? Also use the Reading Order tool under Prepare for Accessibility to visualize numbered content blocks.

How to fix: Reorder tags in the Tags panel by dragging them into the correct sequence. For multi-column layouts, ensure each column flows completely before the next column begins. Mark headers, footers, page numbers, and decorative elements as artifacts so screen readers skip them.

3. Images Without Alternative Text

Every informational image in a PDF needs alt text — a description that conveys the same information the image provides visually. Decorative images (borders, backgrounds, logos that are already described in text) should be marked as artifacts. Missing alt text on informational images is one of the most commonly cited violations in ADA complaints because it is binary, automated-tool-detectable, and directly affects screen reader users.

How to check: In the Tags panel, locate each Figure tag. Right-click and select Properties. The Alternate Text field should contain a meaningful description. Empty alt text or generic text like "image" is a failure.

How to fix: For each informational image, write alt text that describes the content in context. A photo of a construction site in a project update should describe what the photo shows. A chart showing budget allocation should describe the key data points or provide a text summary. For decorative images, remove the Figure tag and mark the element as an artifact.

4. Improperly Structured Tables

Tables in municipal PDFs — budget summaries, fee schedules, meeting attendance records, zoning data — are extremely common and almost universally inaccessible. Without proper table tags (Table, TR, TH, TD), a screen reader cannot associate data cells with their column and row headers. The user hears a stream of numbers with no context.

How to check: In the Tags panel, find the table element. Verify it contains Table, TR (table row), TH (table header), and TD (table data) tags. Header cells should have a Scope attribute indicating whether they apply to the row or column.

How to fix: If the table is not tagged or is tagged incorrectly, use the Table Editor in Acrobat Pro to define the table structure. Identify header rows and columns, assign TH tags with correct scope, and verify that each data cell is associated with the right headers. For complex tables with merged cells or nested headers, this is manual work that requires careful attention.

5. Inaccessible Form Fields

Permit applications, registration forms, feedback surveys, complaint forms — municipal PDFs frequently contain interactive form fields. When these fields lack labels, a screen reader user encounters a text input that announces nothing about what information it expects. They hear "text field" or "field 1" with no indication of whether to enter their name, address, or permit number.

How to check: Tab through every form field in the PDF. For each field, check whether a screen reader announces a descriptive label. In the Tags panel, verify each form field has an associated label tag or a tooltip that describes its purpose.

How to fix: In Acrobat Pro, open the form field properties for each field and enter a descriptive tooltip. Ensure form fields are tagged within the tag tree and associated with their visible labels. Set a logical tab order that matches the visual layout — Form Properties → Tab Order → Use Document Structure.

6. Missing Document Title and Language

Every PDF should declare its title in the document properties (not the filename) and specify its primary language. Without a title, a screen reader may announce the filename — often something like "FY2026_budget_draft_v3_FINAL.pdf" — which tells the user nothing. Without a language declaration, the screen reader may use incorrect pronunciation rules, producing garbled output.

How to check: File → Properties → Description. The Title field should contain a human-readable document title. The Initial View should be set to display the Document Title (not the filename). Under Advanced, the Language field should be set to the correct language.

How to fix: Enter a descriptive title in the document properties. Set the Initial View to show the document title. Set the language to the appropriate code. These are one-minute fixes that eliminate two automated checker failures instantly.

7. Scanned Documents Without OCR

A scanned PDF is an image of text. No matter how clearly the text appears visually, a screen reader cannot read it. The content is completely inaccessible — invisible to assistive technology, unsearchable, and unusable. This is common with older documents that were scanned from paper originals: archived ordinances, historical meeting minutes, legacy permits.

How to check: Try to select text in the document. If you cannot highlight individual words, the PDF is image-based and needs OCR (Optical Character Recognition).

How to fix: Run OCR in Acrobat Pro (All Tools → Scan & OCR → Recognize Text) to convert the image to selectable, searchable text. After OCR, the document still needs proper tagging — OCR only makes the text readable, it does not add structure. For documents that are genuinely archival and meet the Title II rule's narrow exception criteria, you may not need to remediate — but the exception requires that the document was posted before the compliance date, is kept only for reference, is clearly marked as archived, and is never updated.

The Source File Is the Fix

Here is the most important tactical insight in this entire post: the cheapest and most effective way to create an accessible PDF is to build accessibility into the source document before export.

Remediating a PDF after the fact — adding tags, fixing reading order, writing alt text, structuring tables — can cost $7 to $20 per page when done manually, and complex documents with dense tables or multi-column layouts push that higher. For a municipality with thousands of documents, post-hoc remediation is financially impossible.

But if the source document is properly structured — if the Word file uses real heading styles, if images have alt text in the authoring tool, if tables use header rows, if the document language is set — then exporting to PDF with the "Tagged PDF" option produces a document that is 80% or more of the way to accessible. The remaining work is verification and minor corrections, not structural overhaul.

For municipal contractors, this means building accessibility into your document workflow, not treating it as a separate remediation project:

Use heading styles, not bold text. When you create a document in Word, Google Docs, or InDesign, use the built-in heading styles (Heading 1, Heading 2, Heading 3) to define document structure. Do not just make text bold and larger — visual formatting is not structural formatting.

Add alt text at authoring time. Every image, chart, and graphic should get its alt text in the source application before PDF export. In Word: right-click the image → Edit Alt Text. In Google Docs: right-click → Alt Text. This carries through to the PDF tag tree.

Use real table structures. Format data as tables using the application's table tools, with a defined header row. Do not simulate tables with tabs, spaces, or text boxes — these produce completely inaccessible output in PDF.

Set document properties before export. Title, author, language — set these in the source file. They carry through to the PDF metadata.

Export with tagging enabled. In Word: File → Save As → PDF → Options → check "Document structure tags for accessibility." In Google Docs: File → Download → PDF (tagging is automatic). In InDesign: File → Export → Adobe PDF → check "Create Tagged PDF."

If you build these practices into how your team creates documents today, every PDF you produce from this point forward is defensible. The backlog is the problem — the new workflow is the fix.

The Pre-Publication Checklist

Before uploading any PDF to a municipal website, run this verification:

Open the document properties. Confirm the title is set, the language is specified, and it displays the document title (not filename) in the title bar. Confirm the document is tagged.

Run the built-in accessibility checker. In Acrobat Pro, use All Tools → Prepare for Accessibility → Check for Accessibility. Review every flagged issue. Fix failures; review manual check items.

Walk the tag tree. Open the Tags panel and read through the structure. Does the reading order match the visual layout? Are headings in proper hierarchy? Are tables properly structured with headers? Are images tagged with alt text or marked as artifacts?

Tab through form fields. If the document contains any form fields, verify that each one has a descriptive label, that the tab order is logical, and that required fields are identified.

Test with a screen reader. Even a brief test with NVDA (free, Windows) or VoiceOver (built into macOS) reveals issues that automated checkers miss. Can you navigate by heading? Do tables make sense when read aloud? Can you complete the form?

Log the result. Record the document name, date tested, tool used, issues found, fixes applied, and final status in your audit defense log. This documentation is evidence of your compliance process.

Prioritizing the Backlog

You cannot remediate every PDF on a municipal website in 46 days. You should not try. The Title II rule's enforcement posture rewards documented, prioritized effort — not perfection.

Focus on documents that are actively used for services, programs, and activities. Permit applications. Tax forms. Service request forms. Budget documents that inform public comment periods. Meeting agendas for upcoming sessions. Emergency preparedness guides.

Documents that are genuinely archival — old reports kept for reference, historical meeting minutes, superseded policy documents — may qualify for the pre-existing document exception if they meet all four criteria: posted before the compliance date, retained only for reference, stored in a clearly marked archive section, and never updated.

Everything in between — documents that are current but not high-traffic — goes into the remediation queue, prioritized by public impact and legal exposure. Document your prioritization decisions. The log showing that you made deliberate choices about which documents to address first, based on risk and impact, is itself evidence of good faith.

The Contractor's Opportunity

Every municipality is about to discover that their PDF library is a compliance liability. Most do not have the internal expertise to fix it. That creates a market for contractors who can.

If you are already delivering web accessibility services for municipal clients, PDF remediation is a natural extension of your offering. The same clients who need WCAG-conformant websites need WCAG-conformant documents — and the vendor liability chain that activates after the deadline makes this the municipality's problem whether they acknowledge it yet or not.

Build the PDF workflow into your service offering now. When the deadline passes and the enforcement pressure begins, you will be the contractor who already has the solution.

Forty-six days. Start with the documents your clients use most.

---

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