Matterhorn TG-RTL-002 · PDF/UA-1 Taggart extension
Hebrew pronounced with an English voice: per-run language
The document declares en-US at the catalog and never overrides it, so Hebrew paragraphs inherit English.
The condition, as the protocol states it. “A text run whose script is Hebrew or Arabic inherits a Latin-script /Lang, or has no /Lang in effect.”
Matterhorn Protocol 1.1, checkpoint TG-RTL, index TG-RTL-002, section Taggart extension. Software can decide this one on its own.
What a screen reader actually does
The reader pronounces Hebrew letters with an English synthesiser: a stream of consonant names rather than words.
Why this is worse than it sounds
A missing or wrong language tag is usually a minor defect. An English synthesiser reading French is comprehensible with effort; the phonemes overlap.
Hebrew and English share almost nothing. Given שלום, an English voice has no phoneme for ש, no vowel to attach, and no rule for right-to-left. Depending on the engine it will spell the letters by name, produce noise, or fall silent. The reader is not hearing accented Hebrew. They are hearing nothing usable.
This is why, in a Hebrew document, /Lang is not a polish item. It sits alongside reading order as one of the two things that decide whether the file works at all.
What is in the file
The document default is on the catalog; overrides live on structure elements:
1 0 obj
<< /Type /Catalog /Lang (he-IL) ... >> % document default
endobj
22 0 obj
<< /Type /StructElem /S /P /Lang (en-US) /K [7] >> % an English abstract
endobjThe language in effect for a piece of text is the nearest /Lang walking up the tree. Condition TG-RTL-002 fires when a run that is predominantly Hebrew or Arabic has a Latin-script language in effect — either because the document declares en-US and nothing overrides it, or because there is no /Lang anywhere.
The pattern that produces it
Almost every Hebrew PDF that has this problem got it the same way. The producer defaults to en-US. Nobody changes it, because nothing on screen looks wrong. The document goes through a remediation pass, gets tagged, gets alt text, passes the checker — because 11-001 only asks whether a language can be determined, and en-US is perfectly determinable.
The result is a formally conformant Hebrew document that a Hebrew-speaking screen reader user cannot read.
How to fix it free, in Acrobat Pro
Document level, which handles the majority of files:
File → Properties→ Advanced → Reading Options → Language → Hebrew.- Save.
Per passage, for mixed documents:
- Open the Tags panel.
- Right-click the element containing the passage → Properties → Tag tab.
- Set Language. It applies to that element and everything beneath it.
Acrobat’s language list is limited; for anything not in it, use the tag Properties dialog, which accepts a typed BCP 47 tag.
Upstream is much better for mixed documents, because doing it by hand means one dialog per paragraph. In Word, select the text and use Review → Language → Set Proofing Language; the language of every run is carried into the export. In InDesign it is the language set on the paragraph or character style, under Advanced Character Formats.
Where Taggart differs
Taggart decides the script from the characters rather than asking you to notice:
The document declares /Lang ‘en-US’ and 4 predominantly right-to-left line(s) have no overriding /Lang, so Hebrew or Arabic text will be pronounced with a Latin voice.
It reports the suggested tag alongside the finding, and the per-run fix writes /Lang on each structure element covering a right-to-left run — he-IL for Hebrew, ar for Arabic, en-US for Latin runs inside a Hebrew document.
That last case matters and is easy to miss: an English abstract inside a Hebrew paper inherits he-IL from the catalog and is read by a Hebrew voice, which fails in exactly the same way as the reverse. Taggart reports both directions.
Language is written at the same time as TG-RTL-001’s logical-order repair, because they touch the same structure elements and a Hebrew document usually needs both. Neither modifies a content stream, so the page renders identically before and after.
How Taggart handles it
Taggart detects this condition automatically. It is reported as a blocker, with the page, the structure path and the object id of every occurrence.
The fix is Tag per-run language. 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
Is he or he-IL correct?
Both are valid BCP 47 and both work. he-IL is more specific and is what Taggart writes by default. For Arabic, ar is usually right unless the document is in a specific regional variety that matters for pronunciation.
Does the document-level language cover it?
If the whole document is Hebrew, yes — set /Lang (he-IL) on the catalog and you are done. Per-run language matters for mixed documents: an English abstract in a Hebrew paper, a Hebrew quotation in an English report, a bilingual government form. WCAG 3.1.2 Language of Parts covers exactly this case at Level AA.
Do I need to tag individual English words inside a Hebrew sentence?
No, and you should not. WCAG explicitly exempts proper names, technical terms and words that have become part of the surrounding language. Tagging every occurrence of ISO or PDF inside Hebrew prose produces a document that stutters between voices and helps nobody.
How does Taggart know which runs are Hebrew?
From the characters. Hebrew and Arabic occupy known Unicode ranges, so the script of a run is a fact rather than a guess. Taggart computes the proportion of strong-direction characters per run and proposes he-IL, ar or en-US accordingly — then asks you to confirm before writing anything.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint TG-RTL (Right-to-left text and reading order (Taggart extension)), index TG-RTL-002 |
| PDF/UA-1 (ISO 14289-1) | Taggart extension |
| WCAG 2.1 | 3.1.2 Language of Parts — Level AA |
| 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. |
Related conditions
- TG-RTL-001 Right-to-left text is stored in visual order Older 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.
- 11-001 Natural language for text in page content cannot be determined No /Lang is in effect for some text: neither on the catalog, nor on an enclosing structure element, nor on a marked-content sequence.
- 11-007 Natural language is not appropriate A language is declared but it is the wrong one — a Hebrew document declared en-US, or an English abstract inside a Hebrew paper inheriting he-IL.
- 11-002 Natural language for Alt, ActualText and E cannot be determined Alternative text, actual text and expansion text are announced by the reader and therefore need a determinable language just as page content does.
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 order Older 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 ordered Hebrew 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-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.
- TG-RTL-005 Right-to-left punctuation or numerals are misplaced A 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.
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 .