Matterhorn 22-001 · PDF/UA-1 UA1:7.12-1

PDF article threads that read in the wrong order

If article threads are present at all, the bead order must match the logical reading order.

What a screen reader actually does

Readers that follow article threads announce content in the wrong sequence.

What an article thread is

Before PDF had tags, it had its own way to say “this story continues over there”. An article thread is a chain of rectangles, called beads, drawn around the parts of a story in the order they should be read. Acrobat’s help describes it as the navigational path through text that flows from column to column and page to page, so a reader can follow one story and skip the rest (Adobe: PDF articles).

In the file it is a linked list off the catalog:

1 0 obj
<< /Type /Catalog /Threads [ 60 0 R ] … >>

60 0 obj
<< /Type /Thread /F 61 0 R                   % first bead
   /I << /Title (Annual report) >> >>

61 0 obj
<< /Type /Bead /T 60 0 R /P 3 0 R            % on page 3…
   /R [ 72 72 295 720 ]                      % …the left column
   /N 62 0 R /V 63 0 R >>                    % next, previous

62 0 obj
<< /Type /Bead /P 3 0 R /R [ 300 72 523 720 ]  % then the right column
   /N 63 0 R /V 61 0 R >>

The list is circular — the last bead’s /N points back to the first — and each page lists its beads in /B. None of it refers to the structure tree. A document can have perfect tags and a thread that runs the columns backwards, and nothing in either will notice the other.

What breaks

Two reading orders that disagree. The tags say left column then right; the thread says right then left, or jumps from page 3 to page 7 because a box was drawn in the wrong order, or skips the sidebar that the tags read in the middle.

In Acrobat, Read Article follows the thread box by box. The people who depend on that are on-screen readers of multi-column layouts and readers using magnification: following columns at high zoom is exactly what the feature is for, and exactly where a wrong order is hardest to notice — you are only ever seeing one box at a time. Any tool that extracts text by following threads inherits the wrong order too.

Where it comes from

• Threads drawn by hand and never redrawn. A layout changes after the threads were made; the boxes still point at the old positions.
• Threads generated in frame order. Adobe notes that most desktop publishing programs can generate threads automatically when converting to PDF. A generator that follows the order frames were created, rather than the order the story runs, produces a thread that is consistently wrong.
• Right-to-left layouts. In a Hebrew or Arabic two-column page the story starts in the right column. A thread drawn or generated left to right reads it backwards — the same mistake TG-RTL-004 describes for the tags.
• Merged documents, where two documents’ threads, or a thread and a later edit, no longer line up.

How to check it free

This is a judgement because the logical order is a judgement; checking the thread against it is mechanical once you have both.

See whether there are any. In Acrobat, View → Show/Hide → Side panels → Articles opens the Articles panel with the document’s articles listed. An empty list means 22-001 cannot fail.

Walk each one. Adobe documents two ways. Select an article in the panel and choose Options → Read Article to follow it. Or select the Article box tool (All tools → Edit a PDF → More → Article box in current Acrobat): every box then shows a label of its article number and its position, 1-1, 1-2, 1-3, so you can page through and read the sequence off the page (Adobe: PDF articles).

Or list it. Without Acrobat, this prints every thread’s beads in order — page and rectangle — with Python and the free pikepdf library:

import sys, pikepdf

pdf = pikepdf.open(sys.argv[1])
pages = {p.objgen: n for n, p in enumerate(pdf.pages, 1)}
for t, thread in enumerate(pdf.Root.get("/Threads", []), 1):
    title = thread.get("/I", {}).get("/Title", "(untitled)")
    bead, n = thread.F, 1
    while True:
        x0, y0, x1, y1 = (round(float(v)) for v in bead.R)
        print(f"thread {t} {title}  bead {n}: page {pages[bead.P.objgen]}, "
              f"x {x0}-{x1}, y {y0}-{y1}")
        bead, n = bead.N, n + 1
        if bead.objgen == thread.F.objgen:
            break

PDF coordinates start bottom-left, so on one page a smaller x is further left and a larger y is higher up.

Compare with the tags. Walk the same pages in the Tags panel with Highlight Content on, or read the structure order however you normally would. Every point where the thread and the tags disagree is a defect in one of them — and if the tags are the ones that are wrong, that is 09-001, not this, and the reading-order guide is the place to start.

How to fix it free

Delete it. PDF/UA does not require threads. If nobody uses them, removing a wrong thread is a complete fix: select the article in the Articles panel and press Delete.

Or correct it. Adobe documents the pieces in Acrobat Pro: to remove one box from an article, right-click it and choose Delete, then Box in the warning (choosing Article removes the whole article). To insert a box, select the box the new one should follow, click the + at its foot, and draw the new box; the boxes after it renumber automatically. Adobe documents no way to reorder boxes directly, so a box in the wrong place is deleted and drawn again in the right one.

Or regenerate it from the source, if the layout application produced it, after fixing the frame order there.

What Taggart does

Taggart does not read article threads and has no check for this condition. Its reading-order check, 09-001, compares the structure tree with the page geometry; threads are not part of that comparison, and the reading-order editor moves structure elements, not beads.

Its repairs also leave threads exactly as they were — tested on a generated file whose single thread started in the right column of a page that the tags read left column first. Taggart reported nothing about the thread, and after remediation it still started on the right. The conformance statement stopped at machine checks passed, with 22-001 among the conditions Taggart does not check, and the PDF/UA identifier was written only once a person had confirmed those conditions. So if you reorder a document’s tags in Taggart, check its threads afterwards, before you confirm: the two orders were independent before, and they still are.

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.

Where this sits in the standards

Related conditions

• 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.
• 28-001 An annotation is not in correct reading orderThe annotation's position in the structure tree does not match where it appears on the page.
• 27-001 No tests specific to navigation are requiredPDF/UA-1 sets no machine test here, but a long document without bookmarks fails WCAG 2.4.5 in practice and is the single most common procurement complaint.
• TG-RTL-004 Reading order is not right-to-left awareAuto-tagging tools order blocks left-to-right, top-to-bottom. In a Hebrew two-column layout the correct order is right column first.

Other conditions in checkpoint 22

Checkpoint 22 covers article threads. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.

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 2026-10-02. The Acrobat steps follow Adobe’s documentation and were not walked through by hand. Last updated 2026-10-02.