Taggart rule TG-EMPTY-001

Empty paragraphs in a PDF tag tree: whitespace-only tags

Authoring tools emit an empty paragraph wherever the author pressed return twice, and each one becomes a <P> in the structure tree holding a single space. They are not a failure of any Matterhorn condition — nothing is wrong with the file — but a reader that steps through the document element by element stops at every one of them for nothing. On an ordinary Word export there are commonly a dozen; on a long report, hundreds. Whitespace is not content, so the honest place for it is the artifact stream, which is where the page furniture already lives.

What a screen reader actually does

Navigating by element, the reader announces "blank" or simply says nothing and waits, once per empty element. It is not misleading, it is tedious — and tedium is what makes people stop using a screen reader on a document and ask a colleague to read it to them instead.

What is in the file

Somebody pressed return twice to leave a gap. The word processor exported it faithfully:

/Document
├── /P   "Minutes of the March meeting of the finance committee."
├── /P   " "                                  ← MCID 1: a single space
└── /P   "Present: the chair, the treasurer and two members."

and on the page:

/P <</MCID 1>> BDC
  BT /F1 12 Tf 1 0 0 1 72 736 Tm ( ) Tj ET
EMC

The element is real, it is in the reading order, and the only thing it holds is a space. Taggart reports an element when it has no child elements, no /Alt or /ActualText, and every piece of marked content it owns decodes to whitespace.

What it costs

A user moving through the document element by element — the way many screen reader users read a document they need to work through rather than skim — stops at each one. Depending on the screen reader and its settings, the stop is announced as blank, or as nothing at all: a pause, waiting for a keypress, with no information in it.

One is nothing. A one-page export with a dozen is a page where every third stop says nothing. A long report can hold hundreds, and the effect is not confusion but fatigue, which is how people end up asking a colleague to read a document to them instead.

Where it comes from

Blank paragraphs in the source. A word processor exports the paragraphs a document contains, and a line left empty to make space is a paragraph. The tagged export keeps it. On a real one-page export Taggart was tested against, there were fourteen of them against thirty-three lines of content.

Automatic tagging of a page that has blank text runs on it — a space painted between two blocks, a line of spaces used to push something down. A tagger that wraps every run it finds wraps those too.

How to check it free

Not with veraPDF. Its PDF/UA-1 profile has no test for empty elements, so a file full of them can pass it cleanly.

Acrobat Pro’s Tags panel. Open it from the hamburger menu (Windows) or the View menu (macOS) → Show/Hide → Side Panels → Tags, turn on Highlight Content from the panel’s Options menu, and walk the <P> elements. An element whose highlight surrounds nothing you can see, between two paragraphs, is the condition. It is quick on a page and slow on a report.

A screen reader. Read the document element by element and count the stops that say nothing. This is the test that tells you what it costs, rather than whether it is there.

How to fix it free

In the source, which is best. Replace blank lines with paragraph spacing. In Word, that is the Spacing Before and After settings for the paragraph style, rather than an extra press of return. The export then has nothing to tag.

In Acrobat Pro. Adobe documents two Tags panel options that look like they do this, and only one of them does all of it (Adobe: Edit document structure with the Content and Tags panels):

• Change Tag To Artifact — documented as changing the selected tags to artifacts and removing the tagged content from the structure tree. That is the repair: the element leaves the reading order and the space becomes an artifact.
• Delete Tag — documented as removing the selected tag. The element goes, and the space it held is left as content that is neither tagged nor an artifact, which is 01-005.

So:

1. In the Tags panel, select the empty element.
2. Options menu (or right-click) → Change Tag To Artifact.
3. Repeat for each one, then save.

What Taggart does

The check reports each element on its own, with its structure path:

<P> holds only whitespace, so it is a stop in the reading order that announces nothing.

It deliberately leaves two cases alone. An element whose content decodes to no text at all is not reported here, because that is usually a font with no Unicode mapping — 10-001 — rather than a blank. And an element with alternate or actual text is not empty, whatever it paints.

The repair, empty-elements, is in Fix All Safe. It detaches each element from the tree and turns its marked content into an artifact, in that order, so that nothing is left untagged behind it; no painting operator is touched and the page renders identically. Which elements are empty is measured again when the repair runs rather than taken from the original report, because a repair that ran first — a link placed inside a paragraph, a list built out of paragraphs — can move every path after it.

It also runs after Taggart’s own automatic tagging, unasked. Tagging wraps every untagged run on a page, blank ones included; without the follow-up, a document that arrived with no structure tree would come back with empty elements Taggart had made itself.

How Taggart handles it

Taggart checks for this condition automatically and reports it as a warning, with where in the file it found it.

The fix is Move empty elements out of the reading order. It is mechanical, so “Fix All Safe” applies it along with the others in one pass and lists what it changed. Your original file is never modified.

Where this sits in the standards

Related conditions

• 01-001 Artifact tagged as real contentDecoration — 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-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.
• 09-001 Tags are not in logical reading orderThe order of elements in the structure tree does not match the order a human would read the page. This is the single most common substantive defect in tagged PDFs and the one Acrobat's own tooling handles worst.
• 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.

Other conditions in checkpoint TG-STRUCT

Checkpoint TG-STRUCT covers structure-tree hygiene (taggart extension). These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.

Checked with Taggart on a generated file that fails this condition on 2026-10-02. The Acrobat steps follow Adobe’s documentation and were not walked through by hand. Last updated 2026-10-02.