Every time I start a PDF remediation project, I ask the same question before I do anything, does this document actually need to be a PDF?
It sounds almost too simple, but this one question has saved clients more time and money than any tagging technique or remediation tool I've ever recommended. Because the most efficient way to deal with an inaccessible PDF isn't always to fix it; sometimes it's to rethink whether the format is the right choice.
The problem nobody talks about
Organizations come to me with backlogs. Sometimes it's 50 documents. Sometimes it's 500. Government agencies facing the ADA Title II deadline, universities trying to get course materials in order, businesses that just received a demand letter. The instinct is always the same: we need to remediate all of these PDFs.
When I actually sit down and look at what's in the pile, a huge portion of those documents shouldn't be PDFs at all. There's a PDF contact form that could be a simple web form. A FAQ that was exported from Word and hasn't been updated in three years. A policies page that's functionally identical to content already on the website. A newsletter from 2019 that nobody is reading anymore.
Remediating each of those PDFs — tagging the structure, fixing the reading order, adding alt text, setting the language, testing with a screen reader — takes real time. For a moderately complex document, that's easily two to four hours of skilled work. Multiply that across a backlog of hundreds and you're looking at weeks or months of effort, much of it spent on documents that don't need to exist in that format.
The decision framework I use
When I audit a PDF library, I sort every document into one of four buckets before anyone touches Acrobat:
Delete it
Is this document still current? Is anyone actually accessing it? A surprising number of PDFs sitting on websites are outdated. If the content is no longer relevant, take it down. You've just eliminated the remediation work entirely, and cleaned up your site in the process.
Convert it to HTML
Does this document get updated regularly? Is it primarily text-based content that people read on screen rather than print? Things like FAQs, program descriptions, staff directories, informational guides, and news updates almost always work better as web pages. HTML is inherently more accessible than PDF; semantic markup works natively with screen readers, the content reflows on mobile, and you don't need specialized tools to maintain it.
Replace it with a web form
Is this a fillable PDF? Application forms, registration forms, feedback surveys, request forms; are some of the most difficult PDFs to make accessible. Fillable PDF forms require proper labels, correct tab order, tooltip-based accessible names, and careful focus management. And even when remediated well, they still don't work reliably in most mobile PDF viewers. A simple HTML form does all of this natively and is dramatically easier to make accessible.
Remediate it
Does this document genuinely need to maintain a fixed visual layout? Legal contracts, architectural plans, designed publications, formal reports with complex tables, signed documents; these are the PDFs that actually belong in PDF format. These are the ones worth spending your remediation time on.
In my experience, when I run a client's document library through this framework, 30–50% of their PDFs fall into the first three buckets. That means the remediation workload is cut by a third to a half before anyone opens a tag tree.
Why "just remediate everything" is the wrong default
There's a common assumption that every PDF on your site needs to be remediated in place. But this approach has real costs beyond just the hours spent making your PDF compliant.
Maintenance burden
A remediated PDF is a point-in-time artifact. Every time the source content changes — a phone number updates, a policy gets revised, a date expires — someone has to either re-export from the source file and re-remediate, or edit the PDF directly and hope the tag structure survives. With HTML, you update the web page once and everyone sees the current version. There's no second document to maintain.
Mobile experience
PDFs on mobile devices are a poor experience for everyone, not just people using assistive technology. They don't reflow to fit screen sizes, pinch-to-zoom is clumsy, and many accessibility features that work in desktop Adobe Reader don't function at all in mobile viewers or in-browser rendering. If the majority of your audience is on phones — and statistically, they probably are — a web page serves them better.
Discoverability
Search engines can index PDF content, but not as effectively as HTML. Web pages are easier to find, easier to link to specific sections within, and easier for visitors to share. A remediated PDF buried three clicks deep in your site is less useful than the same content surfaced as a well-structured page.
Ongoing compliance
Accessibility isn't a one-time project. Standards evolve, content changes, and sites get redesigned. HTML content living in your CMS moves with your site. PDFs are static files that can easily get left behind; un-updated, un-remediated, and quietly creating liability you don't realize you have.
The conversation to have with your team
If you're facing a PDF remediation project, the most valuable thing you can do before diving in is have a frank conversation with your content stakeholders. These are the questions I always start with:
Why was this made a PDF in the first place? Often the answer is "because that's how we've always done it" or "someone exported it from Word." Neither is a reason it needs to stay a PDF.
Who is this document for, and how are they accessing it? If your audience is reading on screens and phones, HTML is almost always the better format.
How often does this content change? Anything that gets updated more than once a year is probably better served as a web page that can be edited directly in the CMS.
Do you still have the source file? If the original Word or InDesign file exists, fixing accessibility issues there and re-exporting is dramatically faster than remediating in Acrobat. If nobody can find the source file, that's a signal to consider whether the content should just be rebuilt as a web page.
Does this document need a fixed visual layout? If the answer is no — and for most informational documents, it is — then PDF is adding complexity without adding value.
What should stay as a PDF
I'm not anti-PDF, but there are legitimate use cases where the format is the right choice.
Documents that need to preserve an exact visual layout for print or legal purposes. Formal reports, annual statements, and publications where design integrity matters. Forms that require signatures or notarization. Archival documents that need to exist as stable, self-contained files. Technical drawings, blueprints, and diagrams where spatial relationships are critical.
For these documents, remediation is absolutely worth doing; and doing well. These should be the documents you're spending your remediation time on, not the staff directory or the lunch menu that someone exported from Word in 2021.
The bottom line
PDF remediation is skilled and time-consuming work. Every hour you spend remediating a document that didn't need to be a PDF is an hour you could have spent on a document that does.
The single highest-impact step in any accessibility remediation project isn't learning a new Acrobat technique or buying better tooling; it's looking at your document library honestly and asking which of these actually need to exist in this format.
Shrink the pile first then remediate what's left with the care and attention it deserves.
Send me 5 pages and I'll tell you what's wrong and the cost to fix.