If a tool has just told you your PDF has a tagging problem — in a checker, a command-line utility, or an accessibility report — the message was probably terse and the fix unstated. Here are the tagged-PDF errors people actually encounter, what each one really means, and what to do about it.
"This PDF is marked as a tagged PDF, but no structure was found"
Reported by Poppler-based tools (pdfinfo, pdftotext) and some
validators. The file's catalog claims it is tagged (its MarkInfo dictionary says
Marked true) but there is no usable structure tree behind the claim. It's the
document equivalent of a book whose contents page lists chapters that don't exist.
Cause: usually a converter or "PDF optimiser" that stripped the structure tree but left the flag; sometimes a generator that sets the flag without ever building tags.
Fix: don't try to patch the flag — rebuild the structure by re-exporting from the source document with tagging enabled (steps in our Word export guide). If a compression or conversion step in your pipeline caused it, test each step's output to find the one that drops the tags.
"The document is not tagged" / "No tags available"
Adobe Acrobat's accessibility checker, screen readers, and our own checker report this when the document has no tag structure at all. Everything a screen reader needs — reading order, headings, what's a table and what's decoration — lives in that structure. Without it the document is, to assistive technology, a bag of positioned glyphs.
Cause: nine times out of ten, the export setting. Word's "Document structure tags for accessibility" box wasn't ticked, the file came from "Print to PDF" (printing never produces tags), or a scanner produced it (a scan is a photograph — no text, no tags).
Fix: re-export from the source with tags enabled. For scans, you need OCR first, then tagging — no export checkbox can recover text that was never there.
veraPDF failures citing StructTreeRoot or ISO 14289
veraPDF is the industry-standard PDF/UA validator (it's the engine behind our full audit). Its findings cite the specific ISO 14289-1 clause a file violates, and the tagging-related ones cluster into three groups:
- StructTreeRoot missing — the same "no tags at all" situation as above, stated in specification language.
- Content not mapped to structure ("artifact" / "tagged content" failures) — the document has tags, but some visible content isn't connected to them, so a screen reader will skip it. Common after merging tagged and untagged PDFs into one file, or adding stamps, headers or watermarks with a tool that doesn't tag what it adds.
- Role or nesting problems (non-standard structure types, wrong heading order) — tags exist but don't form a sensible hierarchy: headings that jump levels, tables tagged as paragraphs, list items outside a list. Screen readers announce this structure incorrectly even though "the file is tagged".
Fix: the first group means re-export, as above. The second and third usually need either a fix in the source document (correct heading styles, real tables — the same rules as our Word guide) or, for merged/stamped documents, doing the merge with a tag-aware tool and running the check again.
"Tagged but still failing" — why a tagged PDF isn't automatically accessible
A tag structure is the foundation, not the finish line. A file can be tagged and still fail because images lack alternative text, the document language or title is unset, or table headers aren't marked. These are separately checkable — and mostly separately fixable in the source document. Our checker's report lists each one in plain English with its fix; the PDF/UA vs WCAG guide explains how these rules relate to the legal requirements.
General information, not legal advice.