Matterhorn 11-001 · PDF/UA-1 UA1:7.2-3
Set the PDF language so a screen reader uses the right voice
No /Lang is in effect for some text: neither on the catalog, nor on an enclosing structure element, nor on a marked-content sequence.
The condition, as the protocol states it. “Natural language for text in page content cannot be determined.”
Matterhorn Protocol 1.1, checkpoint 11, index 11-001, section UA1:7.2-3. Software can decide this one on its own.
How Acrobat reports it
If you came here from another checker's report, these are its lines for this condition.
- Acrobat Accessibility Checker, Document: “Primary language”
What a screen reader actually does
The reader uses its default voice. Hebrew read with an English synthesiser is unintelligible; English read with a Hebrew synthesiser equally so.
What is in the file
One entry on the catalog covers the whole document:
1 0 obj
<< /Type /Catalog
/Lang (en-US)
/Pages 2 0 R
/StructTreeRoot 6 0 R
/MarkInfo << /Marked true >>
>>
endobj
Any structure element can override it for its subtree:
14 0 obj
<< /Type /StructElem /S /P /Lang (he-IL) /Pg 3 0 R /K [ 2 ] >>
endobj
Condition 11-001 fires when text exists for which no /Lang is in effect anywhere up the chain — and, in Taggart’s implementation, also when a /Lang is present but is not a well-formed BCP 47 tag, since a reader that cannot parse it behaves exactly as if it were missing.
What the user hears
An English synthesiser reading French produces something a French speaker can usually decode with effort. The same synthesiser reading Hebrew produces nothing decodable at all: the letters are outside its phoneme inventory, so it spells them, announces them by name, or falls silent.
This is why the condition matters far more in Hebrew and Arabic documents than the checker’s severity suggests. In a Latin-script document a missing language is an irritation. In a Hebrew document it makes the file unusable, and it is the second most common Hebrew PDF defect after reading order.
How to fix it free, in Acrobat Pro
Thirty seconds, and it is the highest-value half-minute in PDF remediation:
File → Properties→ Advanced tab.- Reading Options → Language — pick from the list, or type a BCP 47 tag.
- Save.
For 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 inside it.
Upstream, again, is better. Word carries the language of each run into the export: select the text, Review → Language → Set Proofing Language. InDesign carries the language set on the paragraph or character style. Doing it in the source means the per-passage overrides come across automatically, which is the tedious part to do by hand.
The mistake that passes every checker
Setting /Lang (en-US) on a Hebrew document.
The catalog has a language. It is well-formed. Every checker passes it, including PAC and veraPDF, because condition 11-001 asks whether a language can be determined, not whether it is right. Whether it is right is condition 11-007, which the protocol marks as requiring human judgement.
It is extremely common, because English is the default in most PDF producers and nobody changes it. The result is a document that is formally conformant and completely unusable.
Where Taggart differs
Taggart reports the missing case with the count of affected elements and a sample of their structure paths, so you can see whether it is the whole document or one stray subtree.
For the “wrong language” case it does something a validator normally will not: it decides. Hebrew and Arabic are decidable from the script, so Taggart compares the characters actually used against the language declared:
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.
It does the same per element, so an English abstract inside a Hebrew paper is caught in both directions.
The fix proposes a value — from the letters for Hebrew and Arabic, from the commonest words for eight languages written in Latin letters — and waits for confirmation before writing it. “Mostly Hebrew” is not the same as “this document is Hebrew”, and a document is allowed to be about something other than what its characters suggest. Per-run /Lang for right-to-left passages is handled by TG-RTL-002, which sets he-IL or ar on each detected run.
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 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
Where does the language actually go?
The document default is /Lang on the catalog. Any structure element can override it with its own /Lang, and that override applies to everything beneath it. A marked-content sequence can carry one too. The language in effect for a piece of text is the nearest /Lang up the tree.
What format does the value take?
A BCP 47 language tag: en-US, he-IL, ar, fr-CA. Not a full language name, not a locale code with an underscore. Taggart validates the syntax and reports a malformed tag rather than accepting it, because a reader that cannot parse the tag falls back to its default just as if it were absent.
Do I need to tag every paragraph, or is the document language enough?
The document language covers everything by default. You only override where the language actually changes — a quotation in another language, an English abstract in a Hebrew paper, a bibliography of foreign titles. WCAG 3.1.2 Language of Parts (Level AA) is the criterion that requires those overrides.
Does this affect anything other than screen readers?
Yes. Hyphenation, search indexing, machine translation and text-to-speech in reading apps all use it. It also affects how a braille display renders the text, since braille contractions are language-specific.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint 11 (Declared Natural Language), index 11-001 |
| 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. |
Guides that cover it
- Which screen reader to test PDFs withNVDA, JAWS and VoiceOver disagree about PDFs in specific, documented ways. Which to use, what each one hides, and what a disagreement between them means.
- How to check if a PDF is accessible: four free checkersCheck PDF accessibility free, online or on your own machine: four checkers against PDF/UA and WCAG, what each catches, and the failures none of them see.
- What a PDF remediation deliverable should containA fixed file is not a deliverable. What a compliance buyer needs in the record, why a green tick is not evidence, and a structure that survives review.
- How to produce a tagged PDF from LaTeXLaTeX's tagging project reached usable in 2024. What works now, what still needs post-processing, and the maths problem nobody has solved.
Related conditions
- 11-007 Natural language is not appropriateA 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 determinedAlternative text, actual text and expansion text are announced by the reader and therefore need a determinable language just as page content does.
- 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.
- 06-003 XMP metadata stream does not contain dc:titleThe Dublin Core title property is missing from the XMP packet.
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-002 Natural language for Alt, ActualText and E cannot be determinedAlternative 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 determinedBookmark titles have no determinable language.
- 11-004 Natural language in the Contents entry for annotations cannot be determinedAnnotation Contents strings — link descriptions, comments — have no determinable language.
- 11-005 Natural language in the TU entry for form fields cannot be determinedForm field tooltips are the accessible name of the field and need a determinable language.
- 11-006 Natural language for document metadata cannot be determinedThe XMP dc:title (and other metadata) has no xml:lang and the catalog has no /Lang.
- 11-007 Natural language is not appropriateA 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.
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 .