WCAG 3.1.2 Language of Parts (Level AA) requires that whenever a phrase or passage on your page is written in a different human language than the page default, that change can be programmatically determined — normally by adding a lang attribute. This lets browsers and screen readers apply the right pronunciation and rendering rules to that text.

What WCAG 3.1.2 actually requires

The official wording from the W3C Understanding document is precise:

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.

In plain terms: your page already declares one default language at the top (<html lang="en">). That satisfies the separate Level A criterion, 3.1.1 Language of Page. Criterion 3.1.2 handles the exceptions — the Spanish testimonial, the German book title, the French menu item, the Arabic prayer quote — that sit inside an otherwise English page and need their own language declared.

The four exceptions matter, because they keep this rule sane. You do not have to mark:

  • Proper names — “Renault,” “Volkswagen,” a person’s name.
  • Technical terms — “Homo sapiens,” “habeas corpus,” “hertz.”
  • Words of indeterminate language — text where no single language clearly applies.
  • Words adopted into the vernacular — “rendezvous,” “café,” “podcast,” and “déjà vu” appear in English dictionaries and are pronounced correctly by English screen readers, so they need no markup.

A standalone foreign word that has not been adopted, and any full phrase or passage in another language, does need a lang attribute.

Who it affects

This criterion is squarely about screen reader users and text-to-speech. A speech synthesizer chooses pronunciation rules from the declared language. When the language is wrong or missing, the W3C gives the canonical example: the French word for car, “voiture,” gets read aloud as “voyture” by an English voice — phonetic gibberish to the listener.

It also helps:

  • People with cognitive, language, and learning disabilities, who rely on accurate speech output to follow content.
  • Braille users, because braille translation software applies different control codes (such as accented characters) per language.
  • Users of switchable-voice screen readers like JAWS, NVDA, and VoiceOver, all of which can change voice and accent on the fly when lang tells them to.

Get it wrong and the experience degrades fast: a careless or incorrect tag can make a screen reader announce something completely different from what’s on screen — for example, JAWS reading a price string in the wrong locale and announcing a different currency entirely.

Concrete failures and fixes

Failure 1 — A multilingual quote with no markup. An English page embeds a customer testimonial in Spanish. NVDA reads it with English pronunciation rules, mangling every word.

<!-- Fails 3.1.2: Spanish text, no lang -->
<blockquote>
  El servicio fue excelente y muy rápido.
</blockquote>

<!-- Passes: language change is programmatic -->
<blockquote lang="es">
  El servicio fue excelente y muy rápido.
</blockquote>

Failure 2 — Inline foreign phrases. A restaurant page lists dishes by their French names in running English copy.

<p>
  Tonight's special is the
  <span lang="fr">coq au vin</span>,
  served with seasonal vegetables.
</p>

The W3C’s sufficient technique here is H58: Using language attributes, which simply directs you to put a lang value on the element wrapping the foreign text — a <span>, <blockquote>, <q>, <a>, or <p>.

Failure 3 — A language switcher that doesn’t speak its own name. Many sites offer a “Deutsch / Español / 中文” menu. The link labels are themselves in other languages and should be marked:

<ul>
  <li><a lang="de" href="/de/">Deutsch</a></li>
  <li><a lang="es" href="/es/">Español</a></li>
  <li><a lang="zh-Hant" href="/zh/">中文</a></li>
</ul>

Failure 4 — The wrong code. Use real BCP 47 language tags, the standard the W3C requires. lang="sp" is invalid (Spanish is es); lang="english" is invalid (it’s en). Region subtags are allowed when meaningful — en-GB, fr-CA, pt-BR.

How to test WCAG 3.1.2

Automated scanners can confirm your page has a valid top-level lang (3.1.1), but they generally cannot tell that a paragraph is secretly in Portuguese. This criterion needs human eyes.

  1. Scan the page for any non-default-language content — quotes, names of works, taglines, menu items, legal phrases, testimonials, multilingual navigation.
  2. Inspect each one in DevTools. Confirm there’s a lang attribute on (or inherited by) the element, and that its value matches the actual language.
  3. Validate the codes against BCP 47. A quick check: every value should be a known primary tag (es, de, ja) optionally followed by a subtag.
  4. Listen with a real screen reader. Turn on NVDA (free) or VoiceOver and navigate to the foreign passage. If the voice switches accent, your markup works; if it reads phonetic nonsense, it doesn’t.
  5. Confirm you didn’t over-mark. Single adopted words like “café” or proper names shouldn’t be tagged — that’s the exception clause doing its job.

For the deeper mechanics of why this matters to assistive tech, see our guide to ARIA labels and roles and how announcement order works.

Language markup is one of the most under-tested checkpoints on the web, and the data shows why 3.1.2 hides so easily. The WebAIM Million report — which scans the top million home pages — found that only 85.1% of pages even declared a top-level document language in 2025 (up from 84% in 2024), meaning roughly one in seven sites fails the easier, automatable sibling rule 3.1.1 Language of Page before you ever reach 3.1.2. And that is the floor, not the ceiling: WebAIM’s automated engine can detect a missing or invalid <html lang>, but it has no way to flag a Spanish testimonial or a Japanese product name sitting untagged inside an English page — exactly the language-of-parts failures this criterion targets. Detecting them takes a human reading the content language by language, which is why 3.1.2 survives on sites that score “clean” on a scanner.

That blind spot maps directly to where the rule bites in practice: multilingual brands, immigration-law firms, healthcare portals serving diverse communities, restaurants with foreign menu names, and any site carrying customer quotes, taglines, or work titles in another language. 3.1.2 is rarely the headline of a demand letter, but it is a standard line item in any thorough audit because it is part of WCAG 2.1 AA, the conformance level U.S. courts treat as the practical benchmark for an accessible website under ADA Title III.

The legal pressure is real and not abstract. On April 24, 2024 the U.S. Department of Justice published its ADA Title II web rule, which adopts WCAG 2.1 Level AA — language of parts included — as the binding technical standard for state and local government websites and mobile apps (compliance dates were later extended into 2027–2028). Private plaintiffs cite the same WCAG 2.1 AA target, and digital-accessibility litigation runs in the thousands of federal and state filings per year per UsableNet’s lawsuit tracking. A formal conformance claim or VPAT has to account for every applicable AA criterion, so even though 3.1.2 is small, an untagged foreign passage is a documented gap a tester can point to.

This is general information, not legal advice. For your specific risk and obligations, consult a qualified attorney.

Fixing it the right way

Getting 3.1.2 right is fundamentally a content-and-template job, because the decision it requires — is this passage in another language, and is it one of the four exceptions? — is a human judgment about meaning, not a pattern a script can match. A foreign phrase and an English sentence are both just UTF-8 text; nothing in the markup tells a machine that “El servicio fue excelente” is Spanish but “rendezvous” is naturalized English. That is the whole reason language detection can’t be automated reliably, and why an accessibility overlay bolted onto your page won’t add the right lang values — it can’t read intent any better than the scanner can, and a wrong guess (lang="es" on an English line) makes a screen reader announce phonetic nonsense, which is worse than no tag at all.

Done properly, the work is precise and durable. The fix lives in your source templates and CMS content, not a runtime patch, so the correct experience ships by default to every visitor and survives the next deploy. Curbcut handles it as hands-on remediation: we read your pages language by language, set valid BCP 47 tags on each genuine foreign passage — es, de, zh-Hant, en-GB — while deliberately leaving proper names, technical terms, and vernacular words untagged per the exception clause, then confirm each one switches voice correctly in NVDA and VoiceOver. We can document the result against WCAG 2.1 AA in a VPAT when you need to prove conformance.

If you’re not sure where your multilingual quotes, menu items, or work titles live in the codebase, run a free scan — it confirms your page-level language declaration, and we’ll follow up by reading the content for the untagged foreign passages a scanner can’t see, then mark them by hand.