PDF accessibility is often approached as a validation problem.
Upload a PDF, run a checker, and get a list of accessibility issues.
But finding issues is only one part of the problem.
The harder part is fixing them.
I've been building AccessLumens as an accessibility platform, and one of the capabilities I've recently added is PDF accessibility remediation.
The goal wasn't just to build another PDF accessibility checker.
I wanted to build a workflow that answers a few important questions:
How accessible is this PDF right now?
What issues can potentially be fixed?
How much improvement can I expect?
What does the document look like after remediation?
The workflow
The process looks like this:
Upload PDF
↓
Accessibility Scan
↓
Current Accessibility Score
↓
Projected Score After Remediation
↓
Repair
↓
Final Accessibility Scan
↓
Final Score
↓
Pay & Download
The part I found particularly important was the projected score.
Why show a projected score?
Remediation shouldn't feel like a black box.
If someone uploads a document for remediation, they shouldn't have to pay first and only then discover what improvement was possible.
So before starting the repair process, AccessLumens shows:
The current accessibility score
The projected score after addressing supported issues
The user can then decide whether they want to proceed.
After remediation, the PDF is scanned again and the final score is displayed.
This creates a simple feedback loop:
Scan → Understand → Repair → Verify
Automation isn't the answer to everything
One thing I've learned while working on PDF remediation is that not every accessibility issue should be blindly automated.
Some problems require context.
For example, a system can identify that an image needs a description, but understanding what that image actually communicates may require human input.
The goal isn't to pretend that accessibility can be solved with a single button.
The goal is to automate what can be automated and surface what requires human attention.
From web accessibility to PDFs
AccessLumens initially started with web accessibility scanning.
Adding PDF remediation is part of a broader direction: bringing different accessibility workflows into one platform.
Web pages aren't the only digital assets organizations publish. PDFs are everywhere — reports, forms, financial documents, educational material, government documents, and more.
And accessibility workflows shouldn't stop at the browser.
There's still a lot I'm working on, particularly around complex document structures, tables, scanned PDFs, and improving remediation accuracy.
But this is an exciting milestone.
Know your score.
See what's possible.
Repair it.
Verify the result.
You can check the feature here - https://accesslumens.com/pdf-remediation
I'm open to share some test credits if you are interested to test it out.
I'm continuing to test and improve this, and I'd love feedback from developers and accessibility professionals working with PDF accessibility, PDF/UA, or document processing.
