If your agency is sitting on tens of thousands of PDFs — or hundreds of thousands, which is not unusual for a state or county government — the pitch is seductive. A tool that automatically turns any inaccessible PDF into an accessible HTML version, on the fly, across your entire library. No remediation queue, no document-by-document slog, no retraining the people who publish. Point it at the pile and the compliance problem disappears.
It doesn't. The converter changes nothing about the documents themselves. It layers a machine-readable version on top of a source file that remains exactly as inaccessible as it was — and it quietly commits you to paying for that layer indefinitely. Worse, under the DOJ's Title II rule, blanketing your site with converted alternates isn't merely inefficient; it runs against the specific conditions the rule sets for using alternate versions at all.
This piece works through what these converters actually do, why the “we'll remediate later” plan rarely survives contact with reality, and where the regulation draws its line. Then it lays out what does shrink the problem: a document-triage decision most agencies skip.
A conversion layer you rent forever is not remediation
A PDF-to-HTML converter functions like an overlay. It doesn't edit or fix the underlying PDF; it generates an alternate rendering when someone requests one and leaves the original document untouched beneath it. The inaccessible file is still there, still inaccessible, still the version most people actually download.
That architecture carries a cost structure worth understanding before you sign. These tools are typically priced per document, per use, or per visit, which means the expense doesn't taper as you make progress — it grows with every new PDF you publish. You are not buying your way out of a backlog; you are renting a permanent translation layer whose price rises in lockstep with your document output. It is an excellent business model for the vendor and a poor one for the customer, because it converts a finite remediation problem into an open-ended subscription.
The stopgap becomes permanent when nobody fixes the process
There is a narrow, legitimate use for these tools. An agency genuinely cornered — a deadline bearing down, a handful of high-traffic documents that have to be usable now — can reasonably deploy a converter as a temporary bridge on its highest-risk documents while it stands up a real remediation program. Be clear about what the bridge does and doesn't do. It can help people use those documents in the meantime, or help answer an individual accessibility request. But once your compliance date arrives, it doesn't make the underlying PDFs compliant. Accessibility practitioners tend to give the same advice: put a remediation plan in place, use the converter to buy time on the priority items, and set the explicit intention of retiring it within a year or two.
The failure mode is what happens when the bridge becomes the destination. An agency adopts the converter, checks the box, and never changes the thing that actually generates the problem: how PDFs get created and published in the first place. The authoring process keeps producing new inaccessible documents, the converter keeps layering over them, and the backlog regenerates faster than any overlay can keep pace with. A converter is a way to defer the work. It is not a remediation plan, and treating it as one all but guarantees you will still be paying for it — and still be noncompliant underneath it — years from now.
Conforming alternate versions are a last resort, not a default
Here the regulation is explicit, and it matters. The DOJ's 2024 Title II web accessibility rule recognizes the concept of a “conforming alternate version” — a separate, accessible version of otherwise-inaccessible content. But 28 CFR § 35.202 permits a public entity to rely on one to meet its obligations only where it is not possible to make the content directly accessible due to technical or legal limitations. It is not a default you may apply across your whole site because it's easier.
The Department's guidance on the rule reads “technical limitation” narrowly: it covers a technology that is not capable of being made accessible. Lack of knowledge or training does not qualify, and neither, by that logic, does the size of your document library. “We have too many PDFs to fix directly” is not a technical limitation, so it cannot justify relying on alternate versions. So a strategy that converts every PDF on your site by default doesn't satisfy § 35.202 — it inverts it, taking a mechanism the rule reserves for genuine last resorts and turning it into standard operating procedure.
There is a deeper reason the Department constrained this. In its rulemaking, the DOJ raised concern that alternate versions invite a segregated, second-class experience for people with disabilities — a separate-but-not-equal arrangement — and noted how difficult it is in practice to keep two versions of the same content in sync. Blanket converter use produces exactly that: one experience for everyone else and a bolted-on version for assistive-technology users, with two things to maintain and drift between them nearly inevitable.
One more precision point, because it's easy to give these tools too much credit. A conforming alternate version has to actually conform: it must be accessible, as up to date as the source, contain the same information and functionality, and be reachable from an accessible page or mechanism. A converter's output can fail those tests, and nothing about the conversion guarantees it passes them. In many cases the converted page isn't even a valid last-resort alternate version; it's an inaccessible workaround wearing the label of one.
Most of your PDFs never needed to be PDFs
So what does shrink the problem? It starts with a decision most agencies never make explicitly: which of these documents should be PDFs at all?
For the large majority, the honest answer is none. A policy page, a program description, a form landing page, a public notice — many were turned into PDFs out of habit, not necessity, and they suffer for it: harder to maintain, harder to find, harder to make accessible. Those are your conversion targets, and the goal is to move them into HTML permanently — not an on-the-fly overlay, but a real HTML page that becomes the canonical source. A great many are low-hanging fruit you can retire from PDF format quickly.
A smaller set genuinely needs to stay in document form. Court records, wet-signature filings, and documents you are required to preserve for public-notice or records-retention purposes have real reasons to remain PDFs. The move there isn't conversion but proper remediation: tag them correctly so the people who need them can use them and so they can be found when someone goes looking.
The rule also gives this triage a third outcome. PDFs that were posted before your compliance date are excepted unless they are currently used to apply for, gain access to, or participate in your services, programs, or activities. Archived content kept only for reference, research, or recordkeeping, left unaltered and stored in a clearly labeled archive area, is excepted too. For a large share of an older library, the right move may be to confirm that it qualifies for one of these exceptions and leave it alone. Confirm how the exceptions apply to your document types with counsel before relying on them.
Sequencing should follow public impact, not conversion convenience. Prioritize the documents that are critical to the services people actually come to you for, and the ones that carry your agency's credibility on a given topic — even a rarely-visited document can be worth keeping and converting if it's the authoritative source on something. This is where portfolio-level visibility earns its place: you cannot triage an inventory you can't see, and most agencies genuinely do not know how many documents they have, where they live, or which ones matter. Surfacing the full document inventory across agencies is the prerequisite for making these calls deliberately rather than reactively.
Fix a template once, or fix every document forever
The cost argument runs the opposite direction from the converter pitch. Permanent HTML is not only more accessible than a converted PDF — it is dramatically cheaper to maintain, because of how the two formats absorb change.
Consider a single correction: a name, a date, a policy detail that has to be updated. In a PDF, that means locating the source file that produced it, editing it, re-exporting, and replacing the published document — for every affected file. On an HTML page, you edit it and republish, and the canonical source is updated in place. There are no parallel formats and no versions to reconcile. Even mediocre HTML tends to be more accessible and more findable than a well-made PDF, which is why the conversion pays for itself on maintenance alone.
Templates multiply the advantage. When your HTML pages are built on a shared template in your CMS, a single fix to that template propagates across every page that uses it. The contrast becomes vivid during a rebrand: a government redesigns, adopts a new logo and color palette, and then discovers that every legacy PDF still carries the old brand. Updating each document by hand is so much work it never gets finished, so the outdated brand lingers in the archive — and stale, mismatched documents quietly erode the very trust the rebrand was meant to build. HTML on templates simply doesn't have that problem.
The real question isn't how to convert — it's what to keep
The converter answers the wrong question. It asks, “How do we make all these PDFs machine-readable?” — and in doing so, it treats the backlog as a permanent fixture to be managed rather than a liability to be retired. The question that actually reduces your exposure is the one it lets you avoid: which of these should be PDFs at all?
Answer that, and the problem gets smaller. Convert the documents that never needed to be documents into permanent HTML. Properly remediate the few that must remain PDFs. Fix the authoring process so you stop manufacturing new inaccessible files. The overlay preserves the backlog and bills you for it; the triage clears it.
That reframe is also easier to sustain when you can see what you're working with. A governance platform like Siteimprove.ai supports each part of that triage. It gives state and local teams portfolio-level visibility into the documents published on the sites they monitor, remediates the PDFs that need to stay PDFs through PDF Remediation Agent, and shows whether the backlog is genuinely shrinking over time rather than quietly growing beneath an overlay you're paying to maintain.
This article is for general informational purposes and is not legal advice. Compliance obligations depend on your entity's specific circumstances; consult qualified counsel.