Matterhorn 08-002 · PDF/UA-1 UA1:7.1-10
OCR text that was never tagged: searchable, not navigable
OCR added a text layer but no structure tree, so the document is searchable but not navigable.
The condition, as the protocol states it. “OCR-generated text is not tagged.”
Matterhorn Protocol 1.1, checkpoint 08, index 08-002, section UA1:7.1-10. The protocol marks this as requiring human judgement.
What a screen reader actually does
Text is present but has no headings, lists or tables — a single undifferentiated wall.
What the condition is
Recognition and tagging are two different jobs, and it is easy for a scan workflow to do only the first.
A recognised page has an image and an invisible text layer. What recognition does not give it is a structure tree: no /StructTreeRoot in the catalog, no marked content in the page, nothing that says this line is a heading, these five are a list, this block is a table. Poppler’s pdfinfo -struct-text (free) prints the tree of a tagged file and prints nothing at all for one with no tree. On the same page, before and after tagging:
$ pdfinfo -struct-text minutes-searchable.pdf
$ pdfinfo -struct-text minutes-tagged.pdf
Document
H1 (block)
"Minutes of the planning committee, 4 March"
P (block)
"The committee met at 10:00 and approved the extension…"The printed page had a heading and paragraphs, and probably lists and a table. The scanner kept the pixels; the recogniser recovered the words; nothing recovered the rest. The Matterhorn Protocol puts this condition in its OCR checkpoint and marks it as human judgement, since deciding what the structure should be means looking at the page.
What the user hears
With no tags, what a screen reader gets is the viewer’s best guess at an order and a flat run of text. A person who navigates by headings presses the key and is told there are none. A list is a sequence of lines that happen to start with numbers. A table is its cells read row after row, with nothing to say which column a figure belongs to.
The text is all there, and a sighted reviewer who searches for a word will find it. That is why “we ran OCR” is so often taken as “we made it accessible”: the part a sighted person can test works.
Where it comes from
“Searchable PDF” output. Scanner software, multifunction printers and OCR utilities commonly offer a searchable PDF: image plus text layer. Tagging is a separate step, when the tool offers it at all.
Acrobat’s text recognition on its own. Adobe describes the result of Scan & OCR as a searchable text layer. Tagging is a different command, under Prepare for accessibility.
Recognition run on a tagged document. Pages that were scans inside an otherwise tagged file can get a text layer that the existing tree knows nothing about.
Scanned pages inserted into a tagged document. Adobe warns that combining tagged and untagged PDFs gives a partially tagged PDF, and that screen-reader users may not realise the untagged pages are there.
How to check it free
Look for a tree. pdfinfo -struct-text scan.pdf, as above: no output, no tags. In Acrobat Pro, open the Accessibility tags panel (View → Show/Hide → Side panels → Accessibility tags). The Accessibility Checker’s Tagged PDF and Tagged content rules report a missing tree and untagged content.
Then make the judgement. A tree existing is 01-005’s question. This condition asks whether the tree matches the page. With the page beside the tags panel or the pdfinfo output, check that every heading on paper is a heading in the tree and at a sensible level, that lists are lists, tables are tables with their header cells, and that the order runs the way a reader would read the page. Running headers, page numbers and the scanner’s own stamps should be artifacts, not text.
How to fix it free, in Acrobat Pro
From Adobe’s guides to creating accessible PDFs and checking them:
- Recognise the text first, and proofread it (08-001).
- All tools → Prepare for accessibility → Automatically tag PDF. If Acrobat finds problems, the Add Tags Report lists them by page.
- Open the Accessibility tags panel and compare the tree with the page. Use All tools → Prepare for accessibility → Fix reading order to retag regions that came out wrong.
- Run Check for accessibility and look at the Tagged PDF and Tagged content results.
Step 3 is not optional on a scan. Adobe’s own description of automatic tagging says it can misread closely spaced columns, irregular alignment and tables without borders, and a scan of an old document can be all three.
What Taggart does
Taggart has no check for this condition, so it never appears among the findings or in the review queue. It is on the list of conditions Taggart does not check, which hold back the conformance claim: when everything else passes, the app lists them beside a single checkbox, I have checked these conditions by hand, or with another validator, and the PDF/UA identifier is not written until it is ticked. The tick covers the whole list, so make this judgement before giving it.
What Taggart reports is the part a machine can see.
A recognition layer with no structure tree is reported as 01-005, content that is neither tagged nor an artifact:
The document has no /StructTreeRoot, so all 4 painting operation(s) across 1 page(s) are neither tagged nor marked as artifacts.
In a tagged document, a page whose recognised text never made it into the tree gets the same condition, page by page. It is not reported as TG-SCAN-001: that is for a page that is a picture with no text, and this page has text.
The repair for 01-005 is tag-untagged-content, which asks before it runs. It wraps the loose text in marked content and builds elements from the size and position of the text: paragraphs, headings, lists, tables, figures. A page-sized image with recognised text over it becomes a background artifact, because the text is what it shows. The change log says plainly that the result is a proposal and that the reading order needs confirming in the reading-order editor.
When Taggart does the recognition itself, tagging follows in the same run: recognised text is new content Taggart wrote, and it does not leave it untagged, so the mechanical half of this condition is not left behind. Whether the structure it proposed matches the printed page is the other half, and that is still a person’s call.
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.
Whatever Taggart changes, the page still looks identical. Fixes edit the PDF object model, not the content streams, and every remediation is re-rendered and compared against the original at structural similarity ≥ 0.999 before you get the file back. A tool that quietly reflows your document is worse than no tool.
Frequently asked questions
The scan is searchable now. Isn't that accessible?
Searchable means the words exist. Accessible means a reader can find their way through them: headings to jump between, lists it can count, tables it can read cell by cell, an order that follows the page. Recognition supplies the first and none of the rest.
If the text is untagged, will a screen reader read it at all?
Usually, in some order. Adobe notes that when a PDF has no tags, Acrobat tries to tag it on the fly when it is read or reflowed, and that the results may be disappointing. What the listener gets is the text in whatever order that guess produces, with no structure to move by.
Isn't this the same as 01-005?
They overlap. 01-005 is the machine-checkable fact that content is neither tagged nor an artifact, and an untagged recognition layer fails it. 08-002 is the human question behind it: was the recognised text given the structure the printed page shows? A whole page wrapped in a single paragraph passes 01-005 and fails this.
Should the scanned image itself be tagged as a Figure?
Not when the text layer carries its words. Then the image is what the text looks like, and tagging both gives the reader the page twice: once as text, once as a graphic with no description. Taggart's tagging makes such an image a background artifact for that reason.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint 08 (OCR Validation), index 08-002 |
| PDF/UA-1 (ISO 14289-1) | Clause 7.1-10 |
| WCAG 2.1 | 1.3.1 Info and Relationships — Level A |
| EN 301 549 / Section 508 / ADA Title II | All three point at WCAG 2.1 Level AA for non-web documents, so a Level A or AA criterion here is in scope for each of them. |
Related conditions
- 08-001 OCR-generated text contains significant errorsThe invisible text layer produced by OCR does not match the visible glyphs. Confusions like rn→m, l→1, and dropped Hebrew niqqud are typical.
- 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.
- 01-005 Content is neither marked as Artifact nor tagged as real contentEvery text-showing, image-painting and path-painting operator on a page must sit either inside a marked-content sequence that maps to the structure tree, or inside an artifact sequence. Content that is in neither is orphaned.
- 01-006 Structure type is not semantically appropriateThe tag does not match the nature of the content: a heading tagged as a paragraph, a data table tagged as a layout container, a caption tagged as body text. This is the judgment call that no validator can make for you.
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.
Check your own file. Taggart’s validator is free and unlimited — 75 of the 87 Matterhorn conditions software can decide, with the other 12 listed for you to confirm; no watermark, no expiry, and no account needed up to 60 pages.
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 . The Acrobat steps follow Adobe’s documentation and were not walked through by hand. Last updated .