Matterhorn 08-001 · PDF/UA-1 UA1:7.1-10

OCR errors: the text layer says what the page doesn't

The invisible text layer produced by OCR does not match the visible glyphs. Confusions like rn→m, l→1, and dropped Hebrew niqqud are typical.

What a screen reader actually does

The reader announces gibberish that looks correct on screen — the worst possible failure mode, because it is invisible to a sighted reviewer.

What the condition is

A scanned page is a picture. Optical character recognition adds the words as a second layer, painted in text render mode 3, which draws nothing, over or under the picture:

q 595 0 0 842 0 0 cm /Im0 Do Q              % the scan, as an image
BT 3 Tr /F1 11 Tf                           % mode 3: invisible text
1 0 0 1 72 760 Tm (Minutes of the planning cornmittee, 4 March) Tj
ET

Everything that reads the document uses that layer: screen readers, search, copy and paste, text-to-speech, indexing. Everyone who looks at the document sees the picture. When the layer and the picture disagree, the readers and the lookers are working from different documents, and neither can tell from where they sit.

The condition is that the recognised text contains significant errors. The protocol leaves it to a person, and for a plain reason: deciding requires comparing what was recognised with what is printed, and a machine that could do that reliably would have recognised it correctly in the first place.

What the user hears

The layer, read fluently and exactly as written, mistakes and all:

Minutes of the planning cornmittee, 4 March. The cornmittee met at 1O:OO…

A listener cannot look at the page to check. A figure that came out wrong is simply a different figure, said with the same confidence as the right one. Meanwhile the person reviewing the file for accessibility sees a clean scan and hears nothing, because they are reading the picture. It is the rare failure that is invisible to exactly the person checking for it.

The errors to expect

Lookalike characters. rn read as m, cl as d, l, 1 and I interchanged, O and 0, 5 and S, 8 and B. In Hebrew, letters that differ by a stroke, such as ד and ר or ה and ח, and niqqud dropped or misplaced.

The wrong recognition language. A Hebrew page recognised as English does not produce Hebrew with errors; it produces Latin letters in Hebrew-shaped places. Acrobat asks for the language when you run recognition, and the choice matters.

Scan quality. Skew, low resolution, faint photocopies, stamps and handwriting across printed lines. Each of them costs accuracy, and the cost lands in the layer.

Layout read as text. Two columns read straight across, a running header merged into the first line, hyphenated words left split. These are reading order and artifact problems as much as recognition ones, and 08-002 and 09-001 cover the structure side.

How to check it free

Extract the layer and read it against the page. Poppler’s pdftotext (free) prints exactly what the layer says:

pdftotext -layout scan.pdf -

Read it beside the page image. Check every number, date, name and amount by eye; skim the prose for words that are not words.

Search for what you can see. Pick a distinctive word from the image and search for it. A miss means the layer says something else there.

Listen. Run a screen reader over a page. Errors that the eye skates over in extracted text are obvious when spoken.

Acrobat Pro’s suspect review. Following Adobe’s instructions: All tools → Scan & OCR → Correct recognized text, and tick Review recognized text. Acrobat draws boxes around the words it was unsure of. It shows nothing else, so treat a clean result as “no doubts”, not as “no errors”.

Validators cannot help. veraPDF’s PDF/UA-1 profile has no test for this condition, and no validator could have one.

How to fix it free, in Acrobat Pro

Correct the suspects. In the same Correct recognized text view, select a boxed word, fix it in the Recognized as field, and choose Accept. Acrobat moves to the next one.

Recognise again with better settings. Adobe’s text recognition guide says to review the result and, where needed, correct errors manually or rerun recognition with adjusted settings. The language is the setting most worth getting right: All tools → Scan & OCR → In this file, then choose the pages and the language before Recognize Text.

Rescan. If the errors come from the image, no setting fixes them. A straight, clean scan at a sensible resolution is cheaper than correcting its output word by word.

Better still, don’t recognise at all. If the document exists in a born-digital form, such as the Word file it was printed from or the publisher’s own PDF, use that instead. Real text has no recognition errors.

What Taggart does

Taggart has no check for this condition. A recognised layer reading cornmittee produces exactly the same findings as one reading committee, and the condition never appears among the findings or in the review queue.

Where it does appear is at the end. It is one of the conditions Taggart does not check, and those hold back the conformance claim until a person confirms them. When everything else passes, the app shows them as a list, each linked to its page here, beside one checkbox: I have checked these conditions by hand, or with another validator. Until it is ticked, the button that writes the PDF/UA identifier stays disabled, and the report says conformance cannot be claimed. The report records which conditions were confirmed.

That tick covers the whole list at once, this condition included. Do the proofreading before you tick it, not after.

What Taggart does have is on either side of it.

Before: it reports a page that is a picture with no text as TG-SCAN-001, and offers to recognise it. That repair runs Tesseract with English, Hebrew and Arabic at 300 dpi, writes the words as an invisible layer, and leaves the image exactly as it was, so the page still renders identically. It is not a safe fix and runs only when you ask. Its change log says which pages were read, how many text runs were written and in which recognition languages, and notes any page where nothing legible came out. It does not record how sure it was of any word.

After: for a file that arrives with a recognised layer, Taggart’s screen-reader preview shows the words a reader will be given, in order, which makes it a convenient place to proofread. Read it against the page. That comparison is this condition, and it is the step no tool takes for you.

How Taggart handles it

No software can decide this one, and Taggart has no check for it, so it never appears among the findings or in the review queue. It is on the list of conditions Taggart asks you to confirm by hand before it writes the PDF/UA claim into the file — the claim waits until you have.

Where this sits in the standards

Related conditions

• 08-002 OCR-generated text is not taggedOCR added a text layer but no structure tree, so the document is searchable but not navigable.
• TG-SCAN-001 The page is a picture of text and carries no text layerA scanned page is a photograph of a page. There is no text object in the file at all, so there is nothing to tag, nothing to put in reading order and nothing to read aloud — every structural repair in this engine is a no-op on it, and a report listing thirty tagging failures describes the symptom and misses the disease. It is also the commonest thing in a real remediation backlog and the repair with the largest single gain, because the document goes from unreadable to readable rather than from badly tagged to well tagged. Recognition writes the words underneath the picture as an invisible layer; the image itself is not touched, so the page still renders exactly as it did.
• 11-007 Natural language is not appropriateA language is declared but it is the wrong one — a Hebrew document declared en-US, or an English abstract inside a Hebrew paper inheriting he-IL.
• 10-001 Character code cannot be mapped to UnicodeA glyph is painted whose character code has no Unicode equivalent reachable through the font's ToUnicode CMap, encoding, or glyph names. The text renders correctly but cannot be extracted.

Other conditions in checkpoint 08

Checkpoint 08 covers ocr validation. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.

• 08-002 OCR-generated text is not taggedOCR added a text layer but no structure tree, so the document is searchable but not navigable.

This condition needs a person’s judgement, so there was nothing for a tool to check. Written from ISO 14289-1 and the Matterhorn Protocol on 2026-10-02. The Acrobat steps follow Adobe’s documentation and were not walked through by hand. Last updated 2026-10-10.