What is PDF remediation?

PDF remediation is repairing an existing PDF so assistive technology can read it: adding the tag structure that marks headings, lists, tables and reading order, plus alt text, a document language and a real title. It is distinct from authoring an accessible document, because the source file is often long gone.

Are PDFs covered by accessibility law?

Where a rule covers an organisation's web content, the documents published on that site are part of that web content. The ADA Title II rule and the HHS Section 504 rule both adopt WCAG 2.1 Level AA, and Section 508 and the European Accessibility Act carry their own obligations. This is general information, not legal advice.

Can PDF remediation be automated?

The structural layer can: tagging, document language, title and metadata, artifacts and much of the reading order. What cannot be automated is judgement - alt text that says what a chart means, which row is a header, and whether the reading order matches what the author intended. A tool that guesses at those produces a file that passes tests and still makes no sense read aloud.

How much does PDF remediation cost?

Hand remediation is commonly priced per page and runs into the tens of dollars per page for complex documents. Automated repair is far cheaper but covers less of the work. AccessLumens charges $5 per document and only for documents whose measured score actually improved.

Guides

How to Remediate a PDF: The Obligation, the Workflow, and the Tools

August 30, 20269 min read

Remediation is what you do about the documents you have already published. It is a different job from authoring an accessible document, and it usually arrives with a deadline attached: an audit, a complaint, a procurement question, or a rule that just came into force. This guide covers why the obligation is real, how the work is actually sequenced, and which tools do which part of it.

If what you need is the underlying checklist - tags, reading order, alt text, and how PDF/UA relates to WCAG - start with how to make a PDF accessible and come back here for the backlog.

Why the documents count, not just the site

The most common and most expensive misreading of accessibility law is that it stops at the HTML. It does not. Where a rule covers an organisation’s web content, the documents published on that site are part of the web content. A perfectly accessible page that links to an untagged PDF has moved the barrier one click further away, not removed it.

The specific obligations differ by where you operate and what you do:

ADA Title II (US state and local government). The Department of Justice’s 2024 rule adopts WCAG 2.1 Level AA as the standard, with deadlines phased by population. Entities serving 50,000 or more had to conform by April 24, 2026; smaller entities follow in April 2027. The rule speaks to web content, and agency PDFs are the bulk of what many agencies actually publish.
Section 504 (US healthcare and federally funded programs). The HHS web content rule at 45 CFR 84.84 also points at WCAG 2.1 Level AA. In May 2026 HHS extended the deadline to 11 May 2027.
Section 508 (US federal agencies and their vendors). The long-standing procurement standard. If you sell to a federal agency, your documents are in scope of what you are asked to attest to.
European Accessibility Act. Applied from 28 June 2025 across the EU, covering a defined set of products and services. See the EAA guide for who is covered and the micro-enterprise carve-out.
ADA Title III (US private business). No regulation names a technical standard here, but courts and settlements have converged on WCAG AA in practice. See ADA website compliance.

None of this is legal advice, and the application of any of it to your organisation is a question for your counsel. See our accessibility disclaimer for what an automated check can and cannot tell you.

It is worth knowing that a deadline passing does not mean the work got done. When we scanned 221 US city government sites after the April 2026 Title II deadline, 42% still had a critical barrier. The gap between a rule and its practice is where most organisations currently sit.

The part that is not about the law

The legal framing is useful because it is what gets budget approved. It is not the reason to do the work, and treating it as the reason produces a predictable failure: documents engineered to pass a validator that are still miserable to read aloud.

A document is how an organisation says something that matters. The benefits application. The exam timetable. The lease, the lab result, the ballot measure, the price list. When that document is untagged, a blind or low-vision reader does not get a worse version of the information. They get nothing, or they get a jumble, and their remaining option is to ask another person to read their private business aloud to them. That is the actual harm, and it does not show up anywhere in a compliance score.

This has a practical consequence for how you prioritise. Compliance logic says remediate whatever an auditor is most likely to open. Harm logic says remediate whatever a person most needs to act on: the forms, the notices with deadlines, the documents someone must read to receive something. Those two lists are not the same, and the second one is the right one to start with.

How remediation actually goes

The instinct is to open the oldest document and start tagging. That is how remediation projects stall. The work sequences better as triage.

Inventory, then cut it down. Most document libraries are substantially dead weight: superseded forms, old newsletters, duplicates of a page that already exists in HTML. Deleting a document is a complete and permanent fix, and it is usually the cheapest one available. Do this before you cost anything.
Ask whether it should be a PDF at all. If the content is a page - a policy, a notice, an FAQ - an HTML version is easier to make accessible, easier to keep accessible, and better for search. Reserve PDF for things that genuinely need to be fixed-layout or printed.
Separate the scanned documents. A scan has no text in it to tag, so it needs OCR before any of this applies, and OCR output needs checking. That makes it a slower and separate workstream (why scans are a different problem). Finding them early stops them blocking everything else.
Fix the source where it still exists. Correcting styles in the Word or InDesign file and re-exporting beats repairing the PDF, and it fixes the next version too. The authoring guide covers the export settings that matter.
Machine-repair the structural layer. Language, title, metadata, tagging, artifacts, reading order: this is the bulk of the failures on a typical document and the part software genuinely does well.
Hand off what needs judgement. Some things cannot be inferred from the file. Alt text that says what a chart means rather than that it is a chart. Which row is a header. Whether the reading order that looks right is the one the author intended. A tool that guesses at these produces a document that passes every test and still makes no sense read aloud, which is worse than an obvious failure because nobody looks again.
Re-check the repaired file, and look at it. Validate it, then open it. A repair that broke the layout or dropped a font is not a repair, and validators do not check whether the document still renders the way it did.

The tools

No single tool covers the whole job. What follows is what each one is actually for. We build the first one, so read that row with the appropriate suspicion, and see the full comparison for pricing, platforms, and the rows where we come off worse.

AccessLumens. Upload a document, get a repaired one back: structure tree, document language, title and metadata, artifacts, and AI-drafted image descriptions that you review before they are applied. The result is re-checked against the same engine the original was scored with, so the before and after are the same measurement, and you are only charged for a document whose score actually moved. Try it on a document. What it does not do is make the judgement calls above: our reports list what a person still has to decide rather than pretending the file is finished.
Adobe Acrobat Pro - where hand remediation happens, and the tag tree editor most auditors know. The capable option when the source is lost, and it expects an operator who knows what a correct tag tree looks like.
CommonLook - built for a compliance obligation with a volume problem, around PDF/UA and Section 508 sign-off.
axesPDF - strong on PDF/UA correctness, particularly tables and complex structure being right rather than merely present.
Equidox - detection tooling for the difficult source documents, tables and multi-column layouts that are painful by hand.
PAC and veraPDF - free, and checkers rather than repair tools: they tell you what is wrong and fix nothing. Worth running whatever else you use, precisely because they are not the tool that did the repair.

One warning applies to every tool in the list, ours included: a perfect score on a document the tool could not parse means nothing at all. That failure mode, and why checkers disagree with each other, is covered in the authoring guide.

Where to start

Pick the five documents your readers most need to act on. Check them, repair what a machine can repair, and read what is left with your own eyes - or better, have someone who uses a screen reader read one. That tells you more about your backlog than any inventory spreadsheet, and it tends to settle the argument about whether the work is worth doing.

You can check a PDF free to see where a document stands, or repair one and see what changes.