5 PDF Pitfalls That Break Remediation Before It Starts

Most conversations about PDF accessibility start with the remediation step: tagging, alt text, reading order. But a surprising number of documents fail before remediation even begins — not because of missing tags, but because of how the PDF was created in the first place.

After processing thousands of documents for cities, universities, and enterprises, we’ve identified five recurring problems that silently undermine accessibility efforts. None of them are about WCAG criteria. All of them will cost you time, money, or both if you don’t catch them early.

1. Non-standard font encodings from legacy ERP systems

This is the most common — and most invisible — pitfall. Enterprise systems like Tyler Technologies, Oracle EBS, SAP, and Crystal Reports generate PDFs using proprietary or non-standard font encodings. The document looks fine when you open it in Acrobat, but the underlying text data is garbled.

When a remediation engine tries to read this text to generate alt text, validate reading order, or assess content structure, it gets corrupted strings instead of actual words. The result: broken output that looks remediated but isn’t actually accessible.

What you can do about it: Check your ERP’s export settings for PDF/A output mode or an option to embed fonts with /ToUnicode CMaps. PDF/A forces the exporter to embed fonts with proper Unicode mappings, which gives any downstream tool — remediation, search, screen readers — clean text to work with. Most ERP systems have this setting; it’s just rarely enabled by default.

2. Scanned-to-PDF without OCR

Government offices still scan paper documents to PDF every day. The result is a PDF that contains an image of text, not actual text. There’s nothing for a screen reader to read, no content to tag, and no structure to remediate.

OCR (Optical Character Recognition) can extract text from these images, but the quality depends heavily on scan resolution, paper condition, and font choices. A 150 DPI scan of a faded dot-matrix printout will produce garbage OCR, and no amount of remediation will fix content that was never accurately captured.

What you can do about it: Scan at 300 DPI minimum, use your scanner’s built-in OCR mode if available, and verify OCR quality before publishing. If the source document exists digitally anywhere, use that instead of a scan.

3. PDFs generated from presentation software

PowerPoint-to-PDF exports are structurally hostile to accessibility. Each slide becomes a single page with no semantic structure. Text boxes are positioned absolutely with no reading order. Charts become flat images without data tables. Slide transitions become meaningless page breaks.

The exported PDF technically has content, but it has none of the structural scaffolding that accessibility requires. Remediating a 40-slide presentation deck is closer to building a new document than fixing an existing one.

What you can do about it: If a presentation must be published as an accessible document, consider exporting it as a Word document first, adding proper heading structure, then exporting to PDF. Or use the accessibility checker built into PowerPoint before exporting. This won’t fix everything, but it establishes basic reading order and alt text that carries through to the PDF.

4. Form fields without programmatic labels

Government forms are everywhere: permit applications, complaint forms, registration documents. Many are created in Acrobat by manually placing form fields on top of a visual layout. The label “Applicant Name” appears next to an input box, but there’s no programmatic association between the two.

A sighted user sees the label and knows what to type. A screen reader user encounters an unlabeled text field and has no idea what information is expected. This isn’t a tag structure issue — it’s a form authoring issue. The label relationship was never established.

What you can do about it: When creating forms in Acrobat, use the tooltip field as a fallback label, or better yet, use the /TU (text-use) attribute on each form field. If you’re generating forms programmatically, ensure each widget has a corresponding /Lbl (label) element in the tag tree that’s spatially associated with the field.

5. Flattened tables that are really just positioned text

Budget reports, fee schedules, and data tables are among the most common government documents. But many PDF generators don’t create actual table structures — they position text at specific coordinates on the page to create the visual appearance of a table.

When you look at the PDF, you see rows and columns. When a screen reader reads it, it gets a stream of disconnected text fragments with no row or column relationships. The number “$14,500” has no association with the line item it belongs to.

What you can do about it: Remediation tools can often reconstruct table structure from spatial analysis — detecting column alignment, row boundaries, and header patterns. But this only works when the visual layout is consistent. Hand-positioned text with irregular spacing defeats spatial analysis. If you control the source application, export with table structure preserved (Word and Excel do this well; many custom reporting tools do not).

The common thread

All five of these pitfalls share the same root cause: the PDF was created without accessibility in mind. Remediation can fix a lot, but it works best when it has clean input to work with.

The most cost-effective accessibility strategy isn’t better remediation — it’s better authoring. Fix your ERP export settings. Scan at higher resolution. Add form labels at creation time. Use proper table structures. These upstream changes reduce remediation cost and improve output quality for every document that follows.

And for the backlog of documents that already exist with these problems? That’s where automated remediation engines earn their keep — handling the volume, flagging what can’t be fixed automatically, and producing defensible compliance evidence for everything that can.