Matterhorn 09-001 · PDF/UA-1 UA1:7.2-1
Fix PDF reading order: why tags read out of sequence
The 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.
The condition, as the protocol states it. “Tags are not in logical reading order.”
Matterhorn Protocol 1.1, checkpoint 09, index 09-001, section UA1:7.2-1. The protocol marks this as requiring human judgement.
What a screen reader actually does
The reader announces content out of sequence: a sidebar in the middle of a sentence, a table read column-by-column, a two-column paper read straight across both columns.
What is actually in the file
A tagged PDF holds two parallel descriptions of the same page. The content stream paints glyphs at coordinates, in whatever order the producer felt like emitting them. The structure tree is a separate tree of objects hanging off /StructTreeRoot, and it is the only one that describes meaning and sequence.
They are joined by marked-content identifiers. The content stream wraps each run in a marked-content sequence:
/P <</MCID 4>> BDC
BT /F1 11 Tf 1 0 0 1 320 640 Tm (Right column, first line.) Tj ET
EMCand a structure element points back at it:
12 0 obj
<< /Type /StructElem
/S /P
/P 9 0 R
/Pg 3 0 R
/K [ 4 ] % this element owns MCID 4 on page 3
>>
endobjA screen reader walks the structure tree depth-first. Where the text sits on the page is irrelevant to it. If /StructTreeRoot’s children list the right column before the left one, the right column is read first — no matter that a sighted reader would obviously start on the left.
That is why a document can look perfect and read as nonsense.
How the failure usually gets there
Three producers account for almost all of it.
Auto-tagging. Acrobat’s Autotag Document and most SDK taggers order elements by a simple top-to-bottom, left-to-right sweep of the page. On a single-column page that is right. On two columns it interleaves them: left line 1, right line 1, left line 2, right line 2. The page looks fine; the reading order is shredded.
Late edits. A block moved on the page after tagging keeps its old position in the tree. This is the one that catches careful people out, because the document was correct when it was tagged.
Floated elements. Pull quotes, sidebars, callouts and figure captions are painted wherever the layout engine put them, and land in the tree at that point rather than where they belong in the argument.
How to see the real order
You cannot judge reading order from the page. You need the tree.
In Acrobat Pro: View → Show/Hide → Navigation Panes → Tags. Expand the tree and walk it top to bottom. That sequence is the reading order. Turn on Options → Highlight Content so selecting a tag outlines the region it covers on the page — this is the only reliable way to map tree position to page position in Acrobat.
Ignore the Order panel for this. It shows a different, per-page ordering that Acrobat keeps for its own tooling, and editing it does not reliably rewrite the structure tree.
How to fix it free, in Acrobat Pro
This genuinely works. It is slow, which is the point of buying a tool, but it costs nothing.
- Open the Tags panel and turn on Highlight Content.
- Click the first tag. Confirm the highlight lands on the content a reader should meet first.
- Walk down with the arrow keys, watching where each highlight appears. The first tag whose highlight jumps somewhere unexpected is your first defect.
- Drag that tag to its correct position in the tree. Acrobat accepts drops between siblings; the insertion line tells you where it will land.
- Repeat. On a two-column page you will move roughly half the elements.
- Re-check with
Accessibility → Accessibility Checkand, better, by reading the document with a screen reader.
Two things to know before you start. Acrobat’s tag drag-and-drop has no multi-select, so every element moves individually. And there is no reliable undo across a batch of moves — save a copy first.
If the document is short and the source file still exists, fix the source and re-export instead. A correctly structured Word or InDesign file exports with a correct reading order, and that costs you nothing at all.
Where Taggart differs
Taggart compares the structure order against the geometric order of the content each element actually points at, and reports the specific transpositions rather than a verdict:
On page 4 the structure tree order disagrees with the visual reading order for 61 of 210 element pairs (29%), in a 2-column layout.
Each finding lists the pairs: “Right column line 1 here.” reads first on the page but comes later in the structure. The editor then shows numbered badges on the rendered page so the order is visible at a glance, keeps the tree and the page selection linked in both directions, and lets you move an element with Alt and the arrow keys — with undo that actually spans a batch.
How Taggart handles it
The protocol marks this condition as needing human judgement, so no validator can decide it outright. Taggart applies a heuristic to find the likely cases and reports them as warnings for you to confirm — it never passes them silently, and it never fails them silently either.
The fix is Repair reading order. 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
Does changing the reading order move anything on the page?
No. Reading order lives in the structure tree, which is a separate object graph from the content streams that paint the page. Reordering elements changes what assistive technology announces and in what sequence; it does not move a single glyph. Taggart proves this on every export by re-rendering both files and comparing them at structural similarity ≥ 0.999.
Why do the Order panel and the Tags panel in Acrobat disagree?
Because they show different things. The Tags panel shows the structure tree, which is what a screen reader follows. The Order panel shows a per-page ordering that Acrobat maintains for its own Reading Order tool. Editing one does not reliably update the other, which is the single biggest source of confusion in Acrobat-based remediation. Trust the Tags panel.
Is reading order a WCAG failure or only a PDF/UA one?
Both. PDF/UA-1 requires the structure tree to reflect logical reading order (checkpoint 09, condition 09-001). WCAG 2.1 covers it under 1.3.2 Meaningful Sequence at Level A, with 1.3.1 Info and Relationships also in scope where the order carries structural meaning.
My document is Hebrew. Does right-to-left change any of this?
It changes the answer, not the rule. In a right-to-left document the correct order for a two-column page runs right column first, then left. Auto-tagging tools order columns left-to-right regardless of script, so a Hebrew paper is very often tagged as two interleaved halves. Taggart detects the document's primary script and evaluates the order accordingly.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint 09 (Appropriate Tags), index 09-001 |
| PDF/UA-1 (ISO 14289-1) | Clause 7.2-1 |
| WCAG 2.1 | 1.3.2 Meaningful Sequence — Level A |
| 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
- 09-002 Structure elements are nested in a semantically inappropriate manner Nesting that is syntactically legal but semantically nonsense — a Table inside an H2, a paragraph containing a section.
- 28-001 An annotation is not in correct reading order The annotation's position in the structure tree does not match where it appears on the page.
- TG-RTL-004 Reading order is not right-to-left aware Auto-tagging tools order blocks left-to-right, top-to-bottom. In a Hebrew two-column layout the correct order is right column first.
- 01-005 Content is neither marked as Artifact nor tagged as real content 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.
Other conditions in checkpoint 09
Checkpoint 09 covers appropriate tags. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.
- 09-002 Structure elements are nested in a semantically inappropriate manner Nesting that is syntactically legal but semantically nonsense — a Table inside an H2, a paragraph containing a section.
- 09-003 Structure type is not semantically appropriate after role mapping Once role mapping has been resolved, the effective type still does not describe the content.
- 09-004 A table-related structure element does not conform to ISO 32000-1, Table 337 The table grammar is broken: a TD outside a TR, a TR outside Table/THead/TBody/TFoot, a Table with no rows.
- 09-005 A list-related structure element does not conform to ISO 32000-1, Table 336 The list grammar is broken: an LI outside an L, an Lbl or LBody outside an LI, a list item with no LBody.
- 09-006 A TOC-related structure element does not conform to ISO 32000-1, Table 333 TOCI appears outside a TOC, or a TOC contains children other than TOC and TOCI.
- 09-007 A Ruby-related structure element does not conform to ISO 32000-1, Table 338 RB, RT or RP appears outside a Ruby element, or Ruby has an illegal child sequence.
- 09-008 A Warichu-related structure element does not conform to ISO 32000-1, Table 338 WT or WP appears outside a Warichu element, or Warichu has an illegal child sequence.
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 .