Matterhorn 01-005 · PDF/UA-1 UA1:7.1-2
Untagged content: text a screen reader never reaches
Every 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.
The condition, as the protocol states it. “Content is neither marked as Artifact nor tagged as real content.”
Matterhorn Protocol 1.1, checkpoint 01, index 01-005, section UA1:7.1-2. Software can decide this one on its own.
What a screen reader actually does
Orphaned content is not in the reading order. Depending on the reader it is either skipped or read at an unpredictable point.
What the requirement actually says
PDF/UA-1 clause 7.1 sets a rule with no exceptions: content is either real content, in which case it belongs in the structure tree, or it is an artifact, in which case it is explicitly declared as one. There is no third category, and no default.
The content stream expresses this with marked-content operators. Real content:
/P <</MCID 3>> BDC
BT /F1 11 Tf 1 0 0 1 72 700 Tm (The first paragraph.) Tj ET
EMCAn artifact:
/Artifact <</Type /Pagination /Subtype /Footer>> BDC
BT /F1 8 Tf 1 0 0 1 72 40 Tm (Page 3 of 40) Tj ET
EMCAnd the failure — an operator inside neither:
BT /F1 11 Tf 1 0 0 1 72 660 Tm (Nobody will ever hear this.) Tj ETThat last line paints text on the page. A conforming reader, walking the structure tree, never arrives at it.
Why “invisible” and not “mislabelled”
This is the distinction that makes the condition serious. A paragraph tagged as a heading is wrong — the reader announces the wrong role, but the user gets the text and can work out the rest. Untagged content produces no announcement at all. There is no cue that anything was skipped.
Behaviour varies by reader, which makes it worse. Some fall back to raw content-stream order and read it at an unpredictable point; some skip it entirely; some read it only in a “no structure” mode the user has to know to switch on. From the author’s side it looks fine in all three cases, because the page is unchanged.
How to find it free
Acrobat Pro. Accessibility → Accessibility Check reports Tagged content — Failed and lists the offending elements. Clicking a result highlights the region on the page. This is the fastest free route and it is reliable.
PAC (free, Windows). Reports it under clause 7.1 with a screen-reader preview that shows you exactly what is announced and what is not — often more convincing than a list of failures.
veraPDF (free, cross-platform). verapdf --flavour ua1 file.pdf reports rule 7.1-3 for each occurrence.
The manual check that always works. In Acrobat, Accessibility → Reading Order → Show Order Panel. Anything on the page without a numbered box over it is untagged.
How to fix it free, in Acrobat Pro
For a handful of orphans:
Accessibility → Reading Order.- Drag a marquee around the untagged region.
- Click the button for what it is: Text/Paragraph, Figure, Heading 1…
- If it is decoration, click Background/Artifact instead — that is the correct treatment, not a cop-out.
For a document with no structure at all, Accessibility → Autotag Document gives you a tree in one step. Be clear about what you have then: everything is in the tree, the condition is cleared, and the reading order and the tag types are a machine’s guess. On a two-column page that guess is reliably wrong — see 09-001.
The better free fix, wherever it is available, is upstream. Export from Word with Document structure tags for accessibility ticked, or from InDesign with Create Tagged PDF. Content that was structured in the source arrives structured, with an order that reflects the author’s intent rather than a geometric sweep.
Where Taggart differs
Taggart walks every content stream, including inside form XObjects, tracking the marked-content stack. It reports per page with a breakdown by kind rather than a single verdict:
Page 3 paints 14 objects that are neither inside a marked-content sequence nor marked as an artifact (11 text, 2 path, 1 image).
For an entirely untagged document it says so once, with the totals, rather than emitting one finding per operator.
The repair is available but deliberately gated. tag-untagged-content wraps every orphaned operator in a marked-content sequence and creates <P> and <Figure> elements in painting order, and it refuses to run without explicit confirmation, because painting order is not reading order. The change log says exactly that: painting order is not reading order — open the reading-order editor and confirm the sequence before shipping this file.
Only BMC, BDC and EMC operators are inserted. Those paint nothing, so the rendered page is unchanged — the appearance gate measures 1.000000 on this fix, and the corpus test applies it to a completely untagged document on every commit to prove it.
How Taggart handles it
Taggart detects this condition automatically. It is reported as a blocker, with the page, the structure path and the object id of every occurrence.
The fix is Tag untagged content. It changes what the document means, so Taggart proposes it and waits for your approval rather than applying it unattended.
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
What exactly counts as content that must be tagged?
Every operator that paints something: text-showing operators (Tj, TJ, ' and "), image and form XObject invocations (Do), inline images, path painting operators (S, s, f, F, f*, B, B*, b, b*) and shadings (sh). Each must sit inside a marked-content sequence that maps into the structure tree, or inside an /Artifact sequence.
Is artifacting a legitimate fix, or is it hiding the problem?
It is legitimate when the content genuinely carries no meaning — a rule line, a page number, a background wash. It is the correct treatment for those and there is no other one. It becomes hiding the problem when it is applied to real content, which is condition 01-002 and is the most damaging single mistake in PDF remediation, because the content does not become mislabelled, it disappears.
My document has no structure tree at all. Is that this condition?
Yes, in its most complete form. With no /StructTreeRoot every painting operation in the file is untagged, so Taggart reports it once per document with the total rather than emitting thousands of identical findings.
Does auto-tagging fix this?
It puts everything in the tree, which clears the condition. Whether it produces a document anyone can read is a different question: auto-tagging assigns types and an order by guessing from geometry, and on anything but a simple single-column page the guess is wrong. Treat it as a starting point, not a fix.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint 01 (Real content tagged), index 01-005 |
| PDF/UA-1 (ISO 14289-1) | Clause 7.1-2 |
| 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
- 01-003 Content marked as Artifact is present inside tagged content A BMC/BDC artifact sequence has been opened while a marked-content sequence for real content is still open. Artifacts and real content may not be nested inside one another.
- 01-004 Tagged content is present inside content marked as Artifact A marked-content sequence for real content has been opened inside an open artifact sequence. The artifact swallows the real content.
- 01-002 Real content marked as artifact Content that carries meaning has been marked as an artifact, which removes it from the structure tree entirely. This is the most damaging single mistake in PDF remediation because the content becomes invisible rather than merely mis-labelled.
- 18-001 Headers and footers are not marked as pagination artifacts Running heads, footers and page numbers are tagged as real content, so they repeat in the reading order on every page.
Other conditions in checkpoint 01
Checkpoint 01 covers real content tagged. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.
- 01-001 Artifact tagged as real content Decoration — a rule line, a page-border image, a watermark, a background flourish — has been given a real content tag, so assistive technology announces it as if it were part of the document.
- 01-002 Real content marked as artifact Content that carries meaning has been marked as an artifact, which removes it from the structure tree entirely. This is the most damaging single mistake in PDF remediation because the content becomes invisible rather than merely mis-labelled.
- 01-003 Content marked as Artifact is present inside tagged content A BMC/BDC artifact sequence has been opened while a marked-content sequence for real content is still open. Artifacts and real content may not be nested inside one another.
- 01-004 Tagged content is present inside content marked as Artifact A marked-content sequence for real content has been opened inside an open artifact sequence. The artifact swallows the real content.
- 01-006 Structure type is not semantically appropriate The 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.
- 01-007 Suspects entry has a value of true The MarkInfo dictionary carries /Suspects true, which is the producing application's own declaration that its tagging may be unreliable. PDF/UA-1 requires the value to be false.
Check your own file. Taggart’s validator is free and unlimited — every machine-checkable Matterhorn condition, no page cap, no watermark, no account needed.
Verified against a real document on . Last updated .