Do Your PDFs Have to Be Accessible? Title II's Quietest Trap for Contractors

The Deliverable Nobody Scanned Is a PDF

Run the seven-step toolkit this series built — axe DevTools, WAVE, Lighthouse, a keyboard pass, a screen-reader spot check — and you have covered the HTML you delivered. Then ask a separate question: what did you actually hand the city? For an enormous share of municipal contractors, the answer is not a web page. It is a PDF. The board agenda. The annual report. The capital-improvement plan. The permit application. The benefits form. The ADA transition plan itself, ironically, posted as an untagged scan.

Those PDFs are the deliverable, and they are sitting in a blind spot that is wider than most contractors realize. A browser scanner does not open a PDF. Lighthouse does not score one. The entire automated layer of the standard accessibility workflow stops at the document boundary — and the document is frequently the whole point of the engagement.

The reflex is to assume PDFs are a softer obligation than web pages: older, more numerous, surely grandfathered, surely "we'll fix them on request." Each of those assumptions has a specific answer in the regulatory text, and none of them lands where the reflex expects. This post walks that text — what the rule names, the two exceptions that look like escape hatches and aren't, the standard your documents are measured against, why your scanner is structurally blind to them, and what a defensible record looks like for a deliverable no tool can score.

PDFs Are Named First in the Rule

This is not an inference from "web content." The Title II rule has a defined term for documents, and PDFs lead the list.

28 CFR 35.104 defines "conventional electronic documents" as web content or content in mobile apps that is in the following electronic file formats: portable document formats ("PDF"), word processor file formats, presentation file formats, and spreadsheet file formats. You can read the operative regulatory text at ecfr.gov and the rule's full preamble in the Federal Register. Four formats, and the PDF is named first — the format DOJ evidently had most in mind, because it is the format public entities post most.

Two structural facts follow from that definition.

First, conventional electronic documents are inside the web-and-mobile rule, not adjacent to it. They are a defined subset of covered content, held to the same technical standard, on the same compliance dates, as the web pages around them. There is no separate, gentler document track.

Second, the obligation reaches documents a public entity "provides or makes available, directly or through contractual, licensing, or other arrangements." That is the same vendor hook this series has traced through mobile apps and embedded third-party content. A city does not have to have authored a document to be on the hook for it. And a contractor does not stop being relevant just because the city is the named entity — the contract that produced the document is the mechanism that flows the obligation back toward whoever produced it.

So the threshold question is not "are PDFs covered." They are, by name. The real questions are the two exceptions, because that is where contractors talk themselves into a false sense of safety.

The Two Exceptions That Read Like Escape Hatches

28 CFR 35.201 lists the exceptions to the web-and-mobile requirements. Two of them get pointed at documents constantly, and both are narrower than they sound.

"Preexisting" does not mean the form you still use

The rule excepts preexisting conventional electronic documents — documents that were available as part of the entity's web content or mobile apps before the compliance date. That sounds like a blanket amnesty for every old PDF on the server. Read the rest of the sentence.

The exception applies "unless such documents are currently used to apply for, gain access to, or participate in the public entity's services, programs, or activities." That clause is the whole game. A genuinely dormant 2014 meeting minute that nobody transacts against is excepted. The permit application, the benefits form, the registration packet, the tax document — anything a resident currently uses to do something with the government — is not excepted, no matter how old the file is. DOJ's own framing in the preamble is that entities should focus on new accessible documents and on remediating the existing documents that are currently used to access services, programs, or activities. The active form is the priority, not the afterthought.

For a contractor, the implication is sharp. If your engagement touches the forms a city actually transacts through — and most do — the "it's preexisting" defense evaporates the moment that form is still in service. The age of the file is irrelevant; its current use is everything.

"Third party" does not mean the PDF you authored

The second exception covers content posted by a third party where the third party is not the public entity. Contractors reach for this one instinctively: I'm a vendor, I'm a third party, my documents are third-party content. That is exactly backwards.

The exception is excepted unless the third party posts the content "due to contractual, licensing, or other arrangements with the public entity." A document you produce under a contract with the city and the city posts is the textbook case of content under a contractual arrangement — which means it is not third-party-excepted. It is covered content, and you are the party who built it. The third-party exception is for genuinely independent content a member of the public drops onto a comment forum, not for the deliverable a city paid you to create.

This is the same boundary the embedded-content post drew for widgets and iframes: "third party" plus "under contract" cancels out to "covered, and yours." The PDF you delivered is the cleanest example of it. Do not plan around an exception that is written to exclude you.

The Standard Is WCAG 2.1 AA — and PDF/UA Is How You Reach It

28 CFR 35.200 sets the technical standard for all covered web and mobile content — documents included — at WCAG 2.1 Level AA, incorporating the specific June 2018 W3C Recommendation. There is no document-specific standard buried in the rule; the same success criteria that govern a web page govern a PDF. You can confirm the standard in the regulatory text.

WCAG was written with web pages in mind, so applying it to a PDF takes a translation layer — the same conceptual problem WCAG2ICT solves for mobile apps. For documents, the practical companion is PDF/UA (ISO 14289-1), the technical specification for "universally accessible" PDFs. PDF/UA is not the legal standard — WCAG 2.1 AA is — but it is the engineering target that maps a tagged, structured, navigable PDF onto the success criteria the rule actually mandates. A PDF that satisfies PDF/UA is a PDF that gives a screen reader a real document structure to read instead of a flat image of one. Section 508 takes the same posture for federal electronic documents, referencing WCAG through the Revised 508 Standards, which is why a document built to clear Title II generally clears a 508 document requirement too.

In concrete terms, an accessible PDF is one with a real tag tree (headings, lists, tables marked up as tables), a defined reading order, alt text on meaningful images, a document title and language set, form fields that are labeled and operable by keyboard, and tables with header associations. A "PDF" that is a flat scan of a printed page is, to a screen reader, a picture of a document — zero structure, zero operability. That is the most common and most damaging failure in the municipal document pile, and no amount of OCR-free posting makes it conform.

Why a Structural Scan Cannot See This

Here is the honesty that protects you, and it is the same honesty this product is built on: an automated structural scanner reads HTML. It does not open PDFs.

BidShield's Readiness Scanner parses the rendered HTML of a page against the WCAG 2.1 AA ruleset. It is genuinely useful for the web surface — and it is structurally blind to a document. When you click a link to a PDF, you have left the DOM the scanner can see and entered a binary the scanner never parses. This is not a gap we paper over. It is the nature of the file format, and any tool that claims to "scan your site for compliance" while silently ignoring every linked PDF is overstating what it does.

That limitation is worth stating plainly to a client, because the alternative — implying the document layer is covered when it isn't — is precisely the kind of overclaim the FTC's accessiBe action ($1M, 2025) put a price on. Automated tooling of any kind catches only a portion of WCAG issues — Deque's research puts axe-core's coverage around 57% of issues by volume on the web content it can read — and it cannot replace manual review. On a PDF, the automated share that a generic web scanner contributes is effectively zero, because it never sees the file. PDF accessibility is checked with document-specific tooling (the accessibility checker inside Acrobat Pro, PAC/PDF Accessibility Checker for PDF/UA) plus a manual screen-reader pass — the same automated-floor-plus-human-judgment workflow the toolkit post describes, ported to a different file type.

So what does the product do for documents, honestly? It does not scan them. What it does is let you record each PDF deliverable as its own tracked line in the audit defense log — file name, the WCAG checks you ran and how, who ran the manual screen-reader pass, the remediation status, the date. The scan covers the HTML; the log covers the documents the scan can't. Together they are the dated, exportable record that answers the procurement gate or the demand letter — not a conformance certificate, which no tool can honestly issue, but the paper trail that shows you did the work and when.

What Enforcement Has Actually Looked Like

The document obligation is not theoretical, and it did not wait for the 2027 deadline. DOJ has been holding Title II entities to WCAG across their web content for years.

In December 2021, the Justice Department settled with the Champaign-Urbana Mass Transit District over the accessibility of its digital services. The agreement requires the district to bring its website, web content, and mobile applications into conformance with WCAG 2.1 Level AA — and "web content" is the same defined universe that, under the 2024 rule, expressly includes conventional electronic documents. The settlement predates the rule's compliance dates by years, which is the point: the underlying Title II duty was already enforceable, and a posted document is part of the content DOJ expects to conform. The contractor lesson is not that one transit district got named; it is that "web content" in an enforcement agreement is broad enough to swallow the document pile, and that the agency held to it will look to whoever built that content.

Pair that with the private-litigation channel. Inaccessible PDFs — unlabeled forms, untagged scans, image-only documents — are among the most reproducible barriers a plaintiff's tester can document, because the failure is binary and obvious the instant a screen reader hits it. When a city client receives a demand letter, the documents you delivered are squarely in scope, and the contractor who can produce a dated record of what was tested and remediated is in a categorically different position than the one reconstructing it after the fact.

The Clock: What Moved, What Didn't

The compliance dates were extended once and are frequently misremembered, so state them precisely. The April 2026 Interim Final Rule (91 FR 20902) moved the WCAG 2.1 AA compliance dates to April 26, 2027 for public entities with a total population of 50,000 or more, and April 26, 2028 for entities under 50,000 and for special-district governments. The IFR's public comment period closed on June 22, 2026 — a week before this post — and DOJ has signaled it may reconsider parts of the 2024 rule, which is a live drift risk worth watching but not yet a change in the law.

Editor's note: an IFR is a rule that is in effect while comments are taken, not merely proposed. The extended dates are operative today. What is uncertain is whether DOJ revises the rule further, and whether the pending litigation over the extension disturbs it — neither of which has happened as of this post's date.

What did not move on any of these clocks:

• The document obligation itself. The extension touched only the two compliance dates in 35.200. It said nothing about documents because it did not need to — PDFs were always inside the rule and stayed there.
• The scope of "currently used" documents. Active forms and transactional documents were never within the preexisting-document exception, and the extension did not widen that exception.
• The standard. WCAG 2.1 AA, June 2018 Recommendation. Not 2.2, not 3.0, for the federal Title II floor.
• State clocks and private litigation. Several states wrote their own procurement-accessibility dates that the federal extension does not touch, and the Unruh/private-litigation channel runs on its own schedule. The federal deadline is a floor, not a shield.

What to Do This Week

If you deliver documents to a public-entity client — and you almost certainly do — four moves.

Inventory the documents the way you inventory pages. Every PDF, Word file, presentation, and spreadsheet you produce or maintain for a client, with one column that decides priority: is this document currently used to apply for, access, or participate in a service? The active forms go to the top; the genuinely dormant archives go to the bottom and may be excepted. That single distinction is the rule's own triage logic.

Open one active form in a screen reader. Pick the permit application or the benefits form, turn on VoiceOver or NVDA, and try to complete it. You will know in minutes whether it is a tagged document or a flat scan, whether the fields are labeled, whether the reading order makes sense. That five-minute test tells you more about your exposure than any assumption about "we'll handle it on request" — and the on-request model is exactly what DOJ's guidance treats as insufficient for documents that are the service.

Decide who owns remediation, in writing. If you author the document, the contractual-arrangement language puts it on you; if you inherit a vendor's PDF, draw that boundary explicitly in your scope before you carry the liability silently. The PDF you produced under contract is not third-party-excepted — plan accordingly.

And log it. For each document, record what you tested, how, who ran the manual pass, and the remediation status in the audit defense log, with dates. The scanner handles the HTML; the log is the only place the document layer becomes a defensible record. The log that protects you when a demand letter names a web page is the same log that protects you when it names a form.

The web pages in your portfolio have been getting scanned for months. The PDFs — named first in the rule, exempted by neither exception you were counting on, invisible to every browser tool you own — have not been getting scanned at all. Open one. Turn on the screen reader. Find out what you have been delivering.

---

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