3.1.2 Language of Parts
- Level AA
- Understandable
- Since WCAG 2.0
Summary
This criterion protects screen reader users, and anyone relying on text-to-speech or braille output, when a page switches language mid-stream. Speech synthesisers pronounce text using language-specific rules: a French sentence read with English pronunciation rules comes out as garble, and a braille display may apply the wrong translation table. When a passage or phrase in another language is programmatically marked, assistive technology switches its pronunciation engine at that point and switches back afterwards. Without the markup, the user hears the foreign passage mangled through the wrong phonetics.
The auditor's mental model: the whole page has a default language (that is SC 3.1.1); this criterion covers everything inside the page that departs from it. Any passage or phrase in a different human language needs its language identified in a way software can read, unless it falls under one of four exceptions: proper names, technical terms, words of indeterminate language, and words that have become part of the vernacular of the surrounding text. Most grading disputes turn on that last exception, so hold it firmly in mind: "rendezvous" in English prose is English now, and marking it as a fail is the most common mistake auditors make with this criterion.
Official wording
The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.
EN 301 549 mapping
- Web pages
- Clause 9.3.1.2
- Software and native apps
- No software requirement: the corresponding chapter 11 clause is void in the standard.
Clause 9.3.1.2 applies this criterion to web pages unchanged. For software the standard declares the corresponding clause void, so native apps carry no mandatory equivalent: marking up the language of every piece of text in every location of a software interface was judged impossible, so no software equivalent exists.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
First find the foreign passages. Sweep each page for quotes and testimonials in another language, embedded legal or regulatory text, addresses, taglines, and, above all, language-switcher navigation: links such as "Deutsch", "Français", or "日本語" are written in their own language and are squarely in scope. Each of those links should carry its own lang attribute (<a lang="de" href="...">Deutsch</a>), because the link text is a phrase in that language regardless of where the link leads.
Then check the markup. In browser developer tools, inspect the element containing the foreign passage and look for a lang attribute on the element itself or the nearest ancestor that scopes it correctly. The effective language of any text node is set by the closest ancestor with a lang attribute, so a Spanish blockquote inside an English page needs lang="es" on the quote (or a wrapper), not merely lang="en" on the html element. Verify the value is a valid language tag ("es", "fr", "zh-Hans"): a misspelt or invalid code is not programmatically determinable.
Finally, confirm with a screen reader where the stakes are high. With VoiceOver in Safari, read through the passage: when the markup is correct and a matching voice is installed, pronunciation audibly switches at the passage boundary. Grade on the markup, though, not on the audio; a missing voice on the test machine does not make correct markup a failure.
iOS
The European standard declares this criterion void for software: marking up the language of every piece of text in every location of a software interface was judged impossible, so native apps carry no mandatory equivalent of 3.1.2 under that standard. When an audit is scoped to the European standard, record the criterion as not applicable for native iOS screens rather than inventing failures.
Auditors still apply good-practice guidance, clearly marked as guidance. iOS lets developers carry language information on text: attributed strings can specify a speech language for a run of text, and an element's accessibility language can be set so VoiceOver reads it with the right voice. Where an app displays substantial foreign passages (a quotation feature, mixed-language content, a language picker listing options in their own languages), check with VoiceOver whether pronunciation switches; use Accessibility Inspector to examine the element. If it does not switch, raise it as a usability recommendation with a note that the fix exists in the platform, not as a WCAG conformance failure.
Android
The position is the same as iOS: the European standard declares this criterion void for software, because requiring language markup on every string in every location of an interface was judged impossible. Native Android screens have no mandatory equivalent, so scope it as not applicable in audits against that standard.
As guidance, Android provides LocaleSpan for marking a run of text within a spannable string as belonging to a specific locale, and TalkBack switches its text-to-speech language when it encounters one (subject to the voices installed on the device). When reviewing an app with mixed-language content, run TalkBack across the foreign passages and note whether pronunciation switches; inspect the text implementation with Layout Inspector if you need to confirm how strings are composed. Report gaps as recommendations for the development team, attributed to platform good practice rather than to this criterion.
Pass and fail examples
Passes:
- An English page quotes a German proverb in a blockquote carrying
lang="de": the passage's language is programmatically determinable. - A language switcher offers "English", "Français", and "Deutsch", each link element carrying its own
langattribute matching its text. - "Rendezvous", "déjà vu", and "ad hoc" appear unmarked in English body copy: these are part of the English vernacular, so the exception applies.
- A customer's name, "François Dubois", appears unmarked in an English testimonial byline: proper names are excepted.
- A biology article uses the unmarked Latin binomial "Homo sapiens": technical terms are excepted.
Fails:
- A full customer testimonial in Spanish sits on an English page with no
langattribute on the quote or any wrapper: a screen reader reads Spanish text with English pronunciation rules. - A language-switcher link reading "日本語" has no
lang="ja": the phrase is Japanese and its language is not programmatically determinable. - A German legal notice paragraph appears in an English checkout flow, unmarked: a complete passage in another language with no markup.
- A French quotation is wrapped in an element whose
langvalue is invalid or misspelt ("francais" instead of "fr"): the language cannot be programmatically determined from a broken tag.
Not a fail under this criterion:
- The page as a whole has no default language on the
htmlelement: that is a Language of Page finding under SC 3.1.1, not a Language of Parts finding. - Loanwords absorbed into the surrounding language ("cliché", "kindergarten", "per se") left unmarked: the vernacular exception covers them, and citing them is the most common false fail against this criterion.
- A correctly marked passage that a screen reader still mispronounces because the matching voice is not installed on the device: the author's obligation is the programmatic markup, not the quality of the user's speech engine.
- An invented brand name or product string of no identifiable human language left unmarked: words of indeterminate language are excepted.
Commonly confused with
- Language of Page, SC 3.1.1. The Level A sibling covers the default language of the whole document; 3.1.2 covers passages and phrases inside it that differ from that default. A missing
langon thehtmlelement files under 3.1.1; a missinglangon a foreign blockquote files here. One finding per criterion, never both for the same evidence. - Vernacular loanwords. Words and phrases that have become part of the surrounding language are explicitly excepted. "Rendezvous" in English prose needs no markup, and neither does "café" or "et cetera". Flagging absorbed loanwords is the most common false fail here; reserve findings for genuine passages and phrases in another language.
- Screen reader pronunciation quality. How well a speech engine renders correctly marked text (accent quality, missing voices, awkward phrasing) is a property of the assistive technology and the user's device, not of the content. The author's criterion is satisfied by valid programmatic language identification.
- SC 3.1.6 Pronunciation. The Level AAA criterion about providing the specific pronunciation of ambiguous words (heteronyms, for example) within the same language. Confusing which of two same-language pronunciations applies is 3.1.6 territory; identifying which language a passage is in is 3.1.2.
How AUDITSU tests this
AUDITSU's audit walkthrough covers Language of Parts on every screen you review. The per-screen questions prompt you to identify passages or phrases in a language other than the page default, including quotes, testimonials, and language-switcher links, and to check the markup on each before grading. Where a screen reader is part of the review, the walkthrough has it running so you can hear whether pronunciation switches at passage boundaries, while the recorded evidence stays anchored to the markup itself. Each check records a pass, fail, or not applicable result per screen with evidence attached.
For native app screens audited against the European standard, the walkthrough reflects that the criterion is void for software: those screens record as not applicable, and any language-marking gaps you observe are captured as good-practice recommendations rather than conformance failures.
For the full guided workflow, see the audit platform.