Taggart rule TG-RTL-004
Hebrew two-column PDFs tagged in left-to-right order
Auto-tagging tools order blocks left-to-right, top-to-bottom. In a Hebrew two-column layout the correct order is right column first.
The rule, as Taggart states it. “In a document whose primary script is right-to-left, the structure order of columns or floated blocks follows left-to-right geometry.”
A Taggart rule, not part of the Matterhorn Protocol or PDF/UA-1: it covers something those standards do not test.
What a screen reader actually does
The reader announces the second column before the first, so every page reads as two interleaved halves.
The failure
A Hebrew newsletter, two columns. Sighted readers start at the top right, read down, move to the top left, read down. The page is unambiguous.
The tagger walked it top-left to bottom-right. The structure tree now reads: left column paragraph 1, left column paragraph 2, … then right column paragraph 1. A screen reader user gets the second half of every article first, then the first half — two coherent streams of Hebrew, interleaved into nonsense.
This is 09-001 — tags not in logical reading order — with a specific, mechanical, entirely predictable cause. It is worth its own condition because the cause tells you both how to find it and how to fix it in bulk.
Why every auto-tagger does this
Automatic tagging derives reading order from geometry, and the geometric rule is essentially universal:
sort blocks by vertical band; within a band, sort by increasing x.
Increasing x is left to right. That is correct for Latin script and wrong for every right-to-left script, and the tools do not condition the rule on the script of the content — the rule lives in the layout analyser, which runs before anything knows what language the text is in.
Acrobat’s Add Tags to Document, most commercial batch pipelines and the auto-tag pass in several remediation suites all inherit this. It is not a bug anyone introduced; it is a default nobody localised.
Where it shows up
Four layouts produce it reliably:
- Two- and three-column Hebrew editorial — newsletters, university bulletins, municipal magazines.
- Israeli government forms with a right-hand instruction rail. The rail is tagged last, so the instructions are read after the fields they explain.
- Arabic and Hebrew academic papers in two-column templates, where an English abstract in column one makes the mis-ordering harder to spot.
- Sidebars and pull-quotes floated left in an RTL page. Left is the end of an RTL line, so the float should be read after the body block it sits beside, and it is read before.
What is in the file
Nothing is wrong with the page description. The glyphs are painted where they belong; the file renders perfectly. The defect is entirely in the order of the kids array of the structure tree:
% Structure tree, in the order it will be read
/StructTreeRoot
/Document
/P -> MCID 14 % left column, x ≈ 60 .. 280
/P -> MCID 15 % left column
/P -> MCID 2 % right column, x ≈ 315 .. 535 <- should be first
/P -> MCID 3 % right columnThe give-away is the MCIDs. Marked-content ids are assigned in paint order, and layout engines usually paint an RTL page’s right column first. So a structure tree whose kids run 14, 15, 2, 3 on an RTL page has almost certainly been re-sorted by geometry after the fact.
How to find it in ten seconds, free
Open the file in Acrobat Reader — no Pro licence needed — and use the Read Out Loud feature (View → Read Out Loud → Activate, then Read This Page Only). You do not need to understand what it says. Listen for whether the first thing read is the text at the top right of the page.
Faster still, for a file you cannot listen to: select all the text on one page and paste it into a plain-text editor. Copy order follows structure order when a document is tagged. If the paste starts with the left column, the tags are in left-to-right order.
How to fix it free, in Acrobat Pro
The Reading Order tool cannot reorder anything — it only assigns types. Reordering happens in the Tags panel, and for a two-column page it is faster than it looks:
View → Show/Hide → Navigation Panes → Tags.View → Show/Hide → Navigation Panes → Orderalongside it, and turn on Show reading order panel so you can see the page regions numbered.- In the Tags tree, expand the page and identify the two runs. Click each element to see the highlighted region on the page — that is the only reliable way to tell which column an element belongs to.
- Select the whole right-column run (click the first element, shift-click the last).
- Drag it above the left-column run. Acrobat drops between elements, not into them, so aim for the horizontal insertion line at the same indent level.
- Repeat per page.
Two cautions from doing this on real files. Acrobat’s Tags panel has no multi-level undo for drags — one mis-drop can nest a run inside a paragraph, and you will not see it in the tree without expanding. Save a copy before you start. And a drag that lands inside an element rather than between two changes the semantics silently, so re-check the nesting depth after each move.
For a 40-page Hebrew bulletin this is roughly 40 minutes of careful dragging, which is the number this product exists to change.
How Taggart does it
Column detection runs on the marked-content geometry, not on laid-out lines. That distinction is the whole trick: a text extractor groups by baseline, so the last line of the right column and the first line of the left column — which share a y — become one line and the two columns dissolve. Taggart takes the bounding box of every MCID, clusters their horizontal spans, and finds the gutter as the widest empty vertical band.
Once the bands are known, the page’s primary script decides the order: if the strong-direction characters on the page are predominantly Hebrew or Arabic, bands are ordered by decreasing x. Within a band, order is by decreasing y as usual.
The reorder is a reading-order fix, which is not in the safe set. It changes what the document means, so Taggart proposes the new order, shows it as numbered badges over the rendered page, and waits. You can accept it, reorder by hand with Alt and the arrow keys, or reject it with a justification — and whichever you do goes into the remediation report with a timestamp and an actor.
How Taggart handles it
Taggart checks for this condition automatically and reports it as a blocker, with where in the file it found it.
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
Acrobat's checker passes the file. Why is this still a failure?
Because no checker can read. PDF/UA requires the structure order to be the intended reading order, and whether an order is the intended one is a human judgement — the Matterhorn Protocol classifies it that way explicitly. A checker can confirm that tags exist and that they are in some order. It cannot confirm that the order is the one a person would read the page in.
Does setting the document language to Hebrew fix the column order?
No. Language and reading order are independent. /Lang tells the synthesiser which voice to use; the structure tree tells it what sequence to say. A Hebrew-language document with left-to-right column order is read in fluent Hebrew, in the wrong order.
How does Taggart know which column comes first?
It measures rather than guesses. Columns are detected from the horizontal spans of the marked-content regions on the page, not from laid-out lines — text in two columns that happens to share a baseline is one line to a layout engine and two columns to a reader. Once the column bands are known, the primary script of the page decides which band leads.
What about a page that is genuinely mixed, like a bilingual form?
Taggart proposes an order and puts it in the guided review queue rather than applying it. Bilingual layouts are exactly where an automatic rule is most likely to be confidently wrong, so the decision, the justification and who made it are recorded in the remediation report.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Taggart | Rule TG-RTL-004. Not part of PDF/UA-1 or the Matterhorn Protocol. |
| WCAG 2.1 | 1.3.2 Meaningful Sequence — 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. |
| IS 5568 (Israel) | Included in Taggart’s IS 5568 profile. Confirm the statutory scope for your obligation with a licensed מורשה נגישות — Taggart makes no legal determination. |
Guides that cover it
- How to fix PDF reading orderA working method for finding and repairing reading order, free in Acrobat and faster in Taggart, including the two-column case that costs the most time.
- Hebrew PDF accessibility: the three failures that matterVisual-order storage, wrong document language, and left-to-right column order. All three are invisible to a sighted reviewer and to every mainstream checker.
- Arabic PDF accessibility: what breaks and whyArabic adds contextual letter shaping and ligatures on top of every right-to-left problem Hebrew has. What that does to extracted text, and how to check it.
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.
- TG-RTL-001 Right-to-left text is stored in visual orderOlder Israeli government, legal and DTP systems lay out Hebrew by reversing the character order and then rendering left-to-right. The page looks correct, but the stored text is backwards. Extracting it gives you the sentence mirrored, and the bidi algorithm then reverses it a second time.
- TG-RTL-003 A mixed-direction run is not correctly orderedHebrew sentences containing English product names, dates, percentages or citation numbers are the hardest bidi case. Producers frequently reverse the RTL and leave the LTR runs alone, or reverse everything.
- 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.
Other conditions in checkpoint TG-RTL
Checkpoint TG-RTL covers right-to-left text and reading order (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.
- TG-RTL-001 Right-to-left text is stored in visual orderOlder Israeli government, legal and DTP systems lay out Hebrew by reversing the character order and then rendering left-to-right. The page looks correct, but the stored text is backwards. Extracting it gives you the sentence mirrored, and the bidi algorithm then reverses it a second time.
- TG-RTL-002 A right-to-left run has no language declarationThe document declares en-US at the catalog and never overrides it, so Hebrew paragraphs inherit English.
- TG-RTL-003 A mixed-direction run is not correctly orderedHebrew sentences containing English product names, dates, percentages or citation numbers are the hardest bidi case. Producers frequently reverse the RTL and leave the LTR runs alone, or reverse everything.
- TG-RTL-005 Right-to-left punctuation or numerals are misplacedA full stop that renders at the left edge of a Hebrew line must be stored at the end of the logical string, not the beginning. Brackets must be stored as the logical opening/closing character, not the visually mirrored one.
- TG-RTL-006 Right-to-left storage order could not be determinedTwo signals decide whether a right-to-left line is stored in visual or logical order: the direction successive text-showing operations move across the page, and whether letters that only ever end a word are sitting at the ends of words. Some lines give neither — a line painted as one operation has no direction to read, and a short line may carry no position-locked letters. Those lines are listed here rather than counted as passing. A document whose remaining lines were all repaired but which still holds undecided ones has not been shown to be correct; it has been shown not to be provably wrong, which is a different claim.
Check your own file. Taggart’s validator is free and unlimited — 75 of the 87 Matterhorn conditions software can decide, with the other 12 listed for you to confirm; no watermark, no expiry, and no account needed up to 60 pages.
Verified against a real document on . Last updated .