The four conditions: what makes a non-English document readable

It is tempting to think of accessibility for a regional-language document as one thing to get right. It is four, and they are independent. A document is genuinely readable by a screen reader only when all four hold together. Getting three of them perfect and missing the fourth still leaves the reader with nothing, or with the wrong thing. This entry sets out the four plainly, because they are the checklist behind everything else in this knowledge base.

1. The text is real Unicode

The first condition is that the characters stored in the file are the actual characters of the language, in the universal encoding called Unicode, and not a legacy substitute.

A legacy font stores the script as Roman bytes and only paints the local shapes, so the text underneath is gibberish to any software that reads it.¹ If this condition fails, nothing else matters: there is no real text for tagging, language tagging, or a screen reader to work with. This is the foundation, covered in detail in the entry on legacy fonts.

How it fails: legacy non-Unicode fonts (Kruti Dev, DevLys, TSCII, Bijoy, InPage, and their kind); a missing or incorrect character map (ToUnicode) in an otherwise modern font; or a scanned page with no text layer at all.

How to check: copy a line of the text and paste it into a plain text box. If it comes back in the right script, this condition is met. If it comes back as Roman gibberish, the font is legacy. If nothing pastes, the page is a scan.¹

2. The reading order is logical

The second condition is that the text is stored in the order it is meant to be read and spoken, not the order it happens to be drawn on the page.

This matters more for complex scripts than for English. In Devanagari, Tamil, Bengali, and others, the visual position of a glyph is often not its logical position: the short-i vowel sign is drawn before the consonant it actually follows, and consonant clusters are reshaped and reordered for display.²³ If a document stores text in the order the glyphs were painted, every codepoint can be correct Unicode and the reading order still be wrong, so a screen reader speaks the syllables out of sequence and search cannot find ordinary words.⁴

How it fails: a generator that builds the text layer from the visual glyph order; reordered vowel signs and conjuncts left in display order; right-to-left text (Arabic, Urdu) stored reversed.

How to check: this is harder to confirm by eye. A practical signal is search: if you have to type a word in an unnatural order to find it, the stored order is visual, not logical. At scale it is detected by comparing the stored character order against the script's syllable rules.⁴

3. The language is declared

The third condition is that the document says what language it is in, both overall and for any passage that switches language.

A screen reader chooses its pronunciation rules and its voice from the document's declared language (the /Lang value). If no language is declared, the screen reader falls back to its default, usually English, and reads the text with English pronunciation, which turns correct Hindi or Tamil into noise.⁵⁶ If the wrong language is declared, it reads with the wrong rules, equally unintelligible. And a document that mixes an English administrative wrapper with a regional-language body, very common in the Global South, needs each part tagged with its own language, or the screen reader mispronounces one of them throughout.⁶

How it fails: no document-level /Lang; no per-passage language on mixed-language content; a /Lang value that is wrong or not a valid language tag.

How to check: inspect the document's language setting and confirm it matches the actual language; for mixed documents, confirm each passage carries its own. Note a residual limit the reader should know: even a correct language tag only helps if the reader has a voice for that language installed.⁷

4. The font is Unicode-compliant for the script

The fourth condition is that the font actually used can render the script's characters correctly, including its conjuncts and combining marks, and is itself a proper Unicode font.

This is the one most people reach for first, and on its own it fixes nothing. A Unicode-compliant font wrapped around legacy Roman bytes still produces gibberish underneath; the font is necessary but not sufficient.¹ Where it does matter independently is coverage: a font that claims a script but lacks specific conjuncts or rarer characters renders empty boxes (called tofu) or wrong shapes, and the reader, sighted or not, loses the content.⁸

How it fails: a legacy font (fails condition 1 as well); a Unicode font with incomplete coverage of the script's conjuncts; the wrong font for the script.

How to fix: use a Unicode-compliant font designed for the script, the Noto Sans family is the safe cross-platform default (Noto Sans Devanagari, Tamil, Bengali, and so on), with Lohit and the Windows fonts Mangal and Nirmala UI as alternatives.⁹¹⁰

Why all four, and in this order

The four are a dependency chain in spirit. Real Unicode text (1) is the ground; without it the rest is moot. Logical order (2) and a declared language (3) determine whether the real text is spoken correctly. A compliant font (4) makes it visible and complete. The common and costly mistake is to treat condition 4 as the whole problem, swap in a Unicode font, and ship a document whose bytes are still legacy and still unreadable. The discipline this knowledge base asks for is to check all four, every time, starting from the foundation.

Endnotes