Matterhorn 11-007 · PDF/UA-1 UA1:7.2-3
Wrong document language: Hebrew declared as en-US
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.
The condition, as the protocol states it. “Natural language is not appropriate.”
Matterhorn Protocol 1.1, checkpoint 11, index 11-007, section UA1:7.2-3. The protocol marks this as requiring human judgement.
What a screen reader actually does
Hebrew read with an English voice sounds like random consonants. This is the most common real-world Hebrew PDF failure after reading order.
The failure that passes everything
/Lang (en-US) on a Hebrew document.
The catalog has a language. It is well-formed BCP 47. Every conformance checker — PAC, veraPDF, Acrobat’s own — reports the language requirement as satisfied, because it is. The condition they are testing is whether a language can be determined.
Whether the determined language is the right one is condition 11-007, and the protocol marks it H: human judgement. So no validator reports it, and the file passes.
Meanwhile a Hebrew-speaking screen reader user opens it and hears nothing usable.
Why it is worse than it sounds
An English synthesiser reading French produces something a French speaker can decode with effort. The phoneme inventories overlap; the prosody is wrong but the words are recoverable.
English and Hebrew share almost nothing. Given שלום, an English voice has no phoneme for ש, no rule for the vowel, and no notion of right-to-left. Depending on the engine it spells the letters by name, produces noise, or falls silent.
The user is not hearing accented Hebrew. They are hearing nothing.
The same is true in reverse, and it is the case people forget: an English abstract inside a Hebrew paper inherits he-IL from the catalog and is read by a Hebrew voice.
How this happens
Almost always the same way. The producer defaults to the interface language of whoever exported the file — usually en-US. Nobody changes it, because nothing on screen looks wrong and the checker says the language requirement is met.
The document may then go through a full remediation pass, get tagged, get alt text, get a reading order, and ship. The language is the one defect that survives a careful process, because the process is looking at a checker that cannot see it.
How to check it free
Acrobat: File → Properties → Advanced → Reading Options → Language. Compare it against the document. This takes five seconds and catches the whole-document case.
Any screen reader: open the document and listen. Wrong-language text is unmistakable within a sentence.
exiftool or pdfinfo will show the catalog /Lang for a scripted check across a batch:
$ exiftool -Language *.pdfFor per-passage language you need the Tags panel: right-click an element → Properties → Tag tab shows the /Lang in force.
How to fix it free, in Acrobat Pro
Whole document, which handles most files:
File → Properties→ Advanced tab.- Reading Options → Language — pick from the list or type a BCP 47 tag.
- Save.
A passage in another language:
- 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 short; for anything not on it, the tag Properties dialog accepts a typed tag.
Upstream is much better for mixed documents, because doing it by hand is 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 on the paragraph or character style, under Advanced Character Formats.
Where Taggart differs
Taggart decides the decidable cases rather than deferring all of them. It counts strong-direction characters per document and per element and compares them against the language in force:
The document declares /Lang ‘en-US’ but 138 of 138 strong-direction characters are hebrew. The declared language does not match the script actually used.
and per element:
<P>is written in hebrew script but the language in scope is ‘en’.
It reports both directions, so the English abstract inside the Hebrew paper is caught as well as the Hebrew paragraph in the English one.
The fix proposes a value from the dominant script and waits for confirmation before writing it. “Mostly Hebrew” is not the same as “this document is Hebrew” — a bilingual form is legitimately one or the other depending on its purpose, and only a person knows which.
For right-to-left runs specifically, per-run /Lang is handled by TG-RTL-002, which sets he-IL or ar on each detected run at the same time as the logical-order repair.
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 Set the document 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
Why do checkers pass this?
Because condition 11-001 asks whether a natural language can be *determined*, and en-US is perfectly determinable. Whether it is *correct* is condition 11-007, which the Matterhorn Protocol marks as requiring human judgement — so no validator reports it, and the file sails through.
How can a tool decide it if the protocol says a human must?
For most language pairs it cannot. But Hebrew and Arabic are decidable from the characters: a paragraph written in Hebrew script cannot be en-US, whatever the catalog says. Taggart decides the cases that are decidable and leaves the rest as review items.
What about a document that quotes another language?
That is exactly what per-passage /Lang is for, and WCAG 3.1.2 Language of Parts requires it at Level AA. Taggart checks both directions — a Hebrew paragraph inheriting en-US, and an English abstract inheriting he-IL.
Should I tag individual foreign words?
No. WCAG explicitly exempts proper names, technical terms and words absorbed into the surrounding language. Tagging every instance of 'PDF' inside Hebrew prose produces a document that stutters between voices and helps nobody.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint 11 (Declared Natural Language), index 11-007 |
| PDF/UA-1 (ISO 14289-1) | Clause 7.2-3 |
| WCAG 2.1 | 3.1.1 Language of Page — Level A |
| 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. |
Related conditions
- 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.
- TG-RTL-002 A right-to-left run has no language declaration The document declares en-US at the catalog and never overrides it, so Hebrew paragraphs inherit English.
- 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.
- 11-006 Natural language for document metadata cannot be determined The XMP dc:title (and other metadata) has no xml:lang and the catalog has no /Lang.
Other conditions in checkpoint 11
Checkpoint 11 covers declared natural language. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.
- 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-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.
- 11-003 Natural language in the Outline entries cannot be determined Bookmark titles have no determinable language.
- 11-004 Natural language in the Contents entry for annotations cannot be determined Annotation Contents strings — link descriptions, comments — have no determinable language.
- 11-005 Natural language in the TU entry for form fields cannot be determined Form field tooltips are the accessible name of the field and need a determinable language.
- 11-006 Natural language for document metadata cannot be determined The XMP dc:title (and other metadata) has no xml:lang and the catalog has no /Lang.
Check your own file. Taggart’s validator is free and unlimited — every machine-checkable Matterhorn condition, no watermark, no expiry, and no account needed up to 60 pages.
Verified against a real document on . Last updated .