Matterhorn 11-002 · PDF/UA-1 UA1:7.2-3
Alt text with no language to read it in
Alternative text, actual text and expansion text are announced by the reader and therefore need a determinable language just as page content does.
The condition, as the protocol states it. “Natural language for text in Alt, ActualText and E attributes cannot be determined.”
Matterhorn Protocol 1.1, checkpoint 11, index 11-002, section UA1:7.2-3. Software can decide this one on its own.
What a screen reader actually does
Alt text in Hebrew is read with an English voice, or vice versa.
What is in the file
Three attributes carry text that a reader announces but that is not page content:
/Alt— what a figure conveys./ActualText— what a run of glyphs actually says, when the glyphs and the characters disagree./E— the expansion of an abbreviation.
All three are strings that come out of a speech synthesiser, so all three need a natural language the reader can determine. PDF/UA-1 clause 7.2 says so, and the language is resolved the way every language is in a PDF: the element’s own /Lang, or the nearest ancestor’s, or the document catalogue’s.
This condition fires when that chain reaches the end with nothing.
What the user hears
A synthesiser given text and no language uses its default voice, and a default voice applies its own phonetics to whatever bytes arrive.
For Latin text in a Latin-default voice the result is usually intelligible, which is why this condition is easy to underrate in English-speaking testing. For anything else it is not a matter of accent:
Alt text:
תרשים הכנסות לפי רבעון, עולה בכל רבעוןRead by an English voice: a run of consonant sounds with no relationship to any word.
The user is told a figure is present, told that it has a description, and given a noise instead of the description. That is worse than a missing /Alt, because a missing one at least signals that something is absent — here the document claims to have described the image and the claim is unusable.
The same applies to an English product name inside a Hebrew document’s alt text and to a Hebrew street sign described inside an English one.
Where it comes from
No document language at all. The commonest case by a wide margin, and it takes out every /Alt in the file at once. It is condition 11-001 as well, and fixing that one fixes this one.
Alt text in a second language with no per-element /Lang. Authoring tools let you type alt text; almost none let you say what language you typed it in. Word, InDesign and Acrobat all write the string and inherit the document language, whatever the string actually is.
Structure rebuilt by a tool that carried the /Alt across and dropped the /Lang that was on the element.
How to check it free
Listen to it. Turn on a screen reader, move to the figure, and hear the description. If it comes out as noise, this is why. Fifteen seconds and more conclusive than any validator.
veraPDF reports it against clause 7.2 and names the element.
Acrobat Pro shows an element’s language in the Tags panel: right-click → Properties → Tag tab → Language. Blank means inherited, which is correct when the inheritance leads somewhere.
Check the document language first, because it is the usual answer: File → Properties → Advanced → Reading Options → Language.
How to fix it free, in Acrobat Pro
If the document has no language, set that first and most of these disappear:
File → Properties → Advanced → Reading Options → Language.
For alt text in a different language from the document, set it on the element that carries the /Alt:
- Tags panel → find the
<Figure>. - Right-click → Properties → Tag tab.
- Set Language to the language of the alternative text, not of the surrounding page.
That second point is the one people get wrong. The language belongs to the string being announced. A Hebrew document with an English chart described in English needs en on that figure, even though every paragraph around it is Hebrew.
Where Taggart differs
document-language is not a safe fix, and the reason is the one Taggart applies to every inference about meaning: mostly Hebrew is not the same claim as this document is Hebrew.
So Taggart measures rather than assumes, and shows the measurement:
No determinable language for 12 /Alt strings. The document declares no /Lang. Of 1,847 strong-direction characters in this file, 1,806 are Hebrew and 41 are Latin.
That is a proposal with its evidence, and it is a different sentence from “we set the language to Hebrew”. The person approving it can see what the number rests on.
Where alt text is in a different script from the document’s own, Taggart reports it separately rather than folding it into the document-language finding — because setting the catalogue language correctly does not fix a Hebrew description inside an English document, and a report that resolved both into one line would say the problem was solved when half of it was not.
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 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
Does the document language not cover it?
It does, and that is usually the fix. The condition fires when there is no determinable language at all — no /Lang on the element, none on any ancestor, and none on the catalogue. A document with a catalogue /Lang covers every Alt in it that does not contradict it.
When does alt text need its own language?
When it is not in the document's language. A Hebrew report with an English chart label, or an English report describing a Hebrew sign in the photograph. The alt text is a separate string from the page content and it can legitimately be in a different language from the paragraph around it.
Is this really audible?
Very. A speech synthesiser set to English applies English phonetics to whatever bytes it receives. Hebrew read that way is not accented — it is a run of consonant sounds with no relationship to the words. The same is true in reverse, and it is the single most common complaint about Hebrew PDFs after reading order.
What about ActualText and E?
Same rule and same reason. /ActualText replaces content for extraction — a ligature, a stylised word — and /E expands an abbreviation. Both are announced, so both need a language. They are covered by this condition alongside /Alt.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint 11 (Declared Natural Language), index 11-002 |
| PDF/UA-1 (ISO 14289-1) | Clause 7.2-3 |
| 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.
- 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.
- 13-004 Figure tag alternative or replacement text missing A Figure element has neither /Alt nor /ActualText. Every Figure must have one or the other; if the image is decorative it should be an artifact instead of a Figure.
- 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.
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-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.
- 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.
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 .