Here's a failure mode that almost never gets discussed in PDF accessibility circles, and it's more common than you'd think: a document gets scanned, run through OCR, and looks completely normal when you open it. You can see the words. You can even select and copy the text. But the text underneath — the part a screen reader actually reads — is garbage.
Not missing. Not blank. Garbage. And that distinction matters more than it sounds like it should.
How this actually happens
When a document is scanned, it starts life as a picture of text, not real text. OCR (optical character recognition) software analyzes that picture and tries to reconstruct what the words actually say, embedding a matching text layer underneath the image so the document becomes searchable and, in theory, accessible.
Most of the time this works well enough. But OCR isn't infallible, and there are two specific ways it can fail in a way that's genuinely hard to catch just by looking at the page:
- The OCR software misreads characters at the font-encoding level. Every character in a PDF is mapped through something called a ToUnicode CMap — essentially a lookup table telling the computer "this glyph on the page means this actual letter." If that mapping gets corrupted or built incorrectly, individual characters can resolve to the wrong thing entirely — not visually (the page still looks fine), but in the actual underlying text data.
- The scan quality is bad enough that OCR effectively fails outright, producing a text layer that's mostly meaningless replacement characters, but still technically present — which matters, because most basic quality checks only ask "is there text here at all," not "is the text actually correct."
Why this is worse than it sounds
Here's the part that makes this genuinely dangerous rather than just an annoyance: a broken text layer usually still passes a naive "does this have text" check.
We found this directly while testing our own pipeline against a real government application form. The page's own extracted text layer was 217 characters long — comfortably above the threshold most systems use to decide "yes, this page has real text, proceed normally." Except every single one of those 217 characters was a Unicode replacement character — the little "�" symbol that means "I have no idea what this glyph actually is."
The document looked processable. It wasn't. And because it looked processable, an automated system with only a basic text-presence check would confidently proceed — attempting to tag headings, paragraphs, and form fields against text that is, functionally, gibberish. The result: a near-total failure across every category, with no indication to anyone that anything had gone wrong. Just a document that came back looking oddly under-tagged, with no explanation why.
That's the real problem. Not that OCR sometimes fails — everything fails sometimes — but that this particular failure mode is silent by default. It doesn't throw an error. It doesn't look broken. It just quietly produces bad results while reporting success.
What an honest system should actually check
The fix, once you understand the failure mode, isn't complicated — but it does require checking something more specific than "is there text":
- What fraction of the extracted text is actual letters and numbers, versus punctuation, whitespace, or garbage? A healthy document — even one with plenty of numbers, symbols, and formatting — should have a substantial majority of real alphanumeric content. A page returning mostly non-alphanumeric noise is a red flag.
- What fraction of the text is literally an "unknown character" marker? This one's even more direct: real, successfully-OCR'd or natively-digital text should have close to zero unrecognized-character instances. A page returning a large share of them is telling you, unambiguously, that its own font encoding or OCR pass failed.
When we measured this across a real set of working documents versus the one that failed, the gap wasn't subtle — it was a difference of several times over, in both directions, not a borderline case requiring careful tuning. That's actually good news: it means a broken-text-layer document doesn't hide well once you're looking for the right signal. It just requires looking for the right signal, not the obvious one.
The honest thing to do when this happens
The right response to detecting this isn't to try harder to tag an unreadable document — there's genuinely nothing there to tag correctly. The right response is to say so, clearly, before doing anything else: "This document's text layer appears to be unreadable, most likely due to a scanning or OCR issue. We can't reliably remediate it in this state."
That's a less impressive-sounding result than "here's your tagged document!" But it's the honest one. A silent near-empty result that looks like success is a worse outcome for everyone than a clear, upfront "we can't read this" — because at least the second one tells you where to actually look for the problem: back at the original scan, not at whatever remediation tool you tried.
If you're evaluating any automated PDF accessibility tool, this is worth asking about directly: what happens when you feed it a badly-scanned document — does it fail loudly and honestly, or does it quietly hand you something that looks fine and isn't? The answer tells you a lot about how the tool was actually built.