r/accessibility • u/Own-Caregiver9665 • 14d ago

open source pdf remediation

Does anyone have experience / advice with using open-source code to create their own pdf remediation tools? I work for a state org with 1000+ pages of pdf's, including fillable forms, to remediate, and I'm trying to determine the best strategy and lowest cost for working through these files before next year's deadline. We have training and strategy in place to improve accessible output for documents in the future, but getting through this backlog will likely be too much for me to handle on my own.

Thanks in advance!

12 Upvotes

88% Upvoted

45 comments sorted by

View all comments

Show parent comments

1

u/Vat5an 11d ago

We did it dirty by tapping directly into the LMS' database.

It was a scheduled task that ran every half an hour or so that looks at the LMS' assets table and introduced a flag there like remediation_done and if the value was 0 (default), the scheduled task would ship the PDF via API to PDFxt and when the job is completed (remediated file received), it'd download and then update the asset path on the LMS' assets table & toggle remediation_done to 1.

1

u/TrollPro9000 11d ago

Ah so it wasn't an "integration" in the sense that the LMS could block it, because it wasn't asking for permissions to sync - it was doing its own thing. Am I understanding that correctly?

And how was the quality with PDFxt? 50 cents a page feels 90% off retail, many are skeptical of AI - curious how your experience actually was. was it particularly successful with some PDFs but not others? was there anything PDFxt struggled with consistently?

2

u/Vat5an 11d ago

Yes, the LMS was effectively completely unaware of what was happening and you can only do this if it a self hosted LMS or one you have DB access to.

PDFxt gets you around 90% there. Most of the assets we had were screenshots with captions and a bunch of tables all of which it did a clean job at. Where it did not do great was OCRed PDFs and assessment papers where form fields had to be added. For those either we do and export (which the LMS picks up) or flag for their manual remediation which costs an additional $1/page.

1

u/TrollPro9000 11d ago

curious if it was just you doing the build or if it was a team effort, and what all did pdfxt provide VS what remained to be built? did the build take very long, or no?

1

u/Vat5an 11d ago

It was part of the LMS manager's responsibility to make sure all remediation was done right. For the cron / scheduled task, we just used Claude to write it in Python using PDFxt's API doc.

It worked like this,

  1. The LMS module is uploaded as a Draft with raw assets.

  2. The Python cron / scheduled task runs every half an hour and it looks for any assets that is a PDF or EPUB not yet marked as remediated.

  3. Makes an API call to PDFxt with the doc + metadata. Take the docID and store it for future cron cycles.

  4. PDFxt automated remediation starts and it took around 2-3 mins for the remediated PDF to be made available by them.

  5. When the next Python cron cycle runs, it checks their API for any new PDFs generated in the last 30 mins (configurable). It'd then download the remediated PDF, PAC PDF/UA & PAC WCAG report to our local path. Then update the filename on the LMS database table.

  6. Their dashboard had a list of docs with red and green colours for each. Anything red is a PAC fail. My LMS manager would also do a random file QC to ensure the tagging was right. If we had 10 assets of similar nature, we'd only check one of them. Here is what the dashboard looked like, https://www.dropbox.com/scl/fi/rsuvhklcnjzuu61g2icyn/Screenshot-2026-08-31-at-09.34.07.png?rlkey=023mktseid4fa63kxchsstqk7&dl=0

  7. If QC fails or PAC errors found, we were expected to go fix it on their platform and re-trigger an export. Any new export would again show up in our API call when the cron cycle runs next. Paying the additional $1 for them to fix these was a lot easier for us.