WCAG 3.1.2 Language of Parts: How to Mark Changes in Language

What WCAG 3.1.2 requires

Success Criterion 3.1.2, Language of Parts, requires that any passage or phrase whose language differs from the primary language of the page be identifiable in code. The goal is that assistive technology and other user agents can determine the language so pronunciation and rendering can be correct.

Why marking language changes matters

Screen readers use language information to switch pronunciation, hyphenation, and text-to-speech rules. Search engines and translation tools also rely on language tags. When language is not declared, users who rely on speech output may hear mispronounced text, which can change the meaning.

How to mark language changes in HTML

Use the HTML lang attribute on the element that contains the foreign-language text. For XML-based documents, use xml:lang. Do not try to set language with ARIA attributes or visual styles; these do not convey language to assistive technology.

Basic examples

• Document primary language on <html>: <html lang="en-GB">

• Phrase in another language: <span lang="es">¿Cómo estás?</span>

• Block in another language: <p lang="fr">Bonjour tout le monde.</p>

Nested language changes

If a phrase inside a foreign-language passage switches back to the page language, mark that inner element with the appropriate code.

<p lang="en">She said <span lang="es">¿Cómo estás?</span> and smiled.</p>

<p lang="fr">Le mot <span lang="en">software</span> est courant en français.</p>

Choosing language tags

Use BCP 47 tags such as en, en-GB, es, or zh-Hant. Include region or script subtags when pronunciation or word forms differ by region or script.

Examples:

• en-GB for British English
• pt-BR for Brazilian Portuguese
• zh-Hans for Simplified Chinese

When you do not need to mark language

Short words or names borrowed into the primary language often need no explicit tag. If a single word is common and pronounced like the page language, you can omit a tag. Still, if pronunciation matters for understanding, mark it.

Common mistakes to avoid

• Relying on visual styling to indicate language. Visual cues do not help screen readers.
• Using ARIA attributes to set language. ARIA does not define document language.
• Setting language only on the <html> element and ignoring inline passages that differ.
• Using incorrect or malformed BCP 47 codes such as english or gb.

CMS and dynamic content: practical steps

Make language a stored field for content blocks and posts. When editors add inline translated phrases, provide an inline control to add a language tag. For WYSIWYG editors, enable an element wrapper with a lang attribute rather than inserting plain text markup.

For dynamically generated content, ensure server-side templates output the correct lang attributes. If you use client-side rendering, set attributes on elements as part of the DOM update, not only in innerHTML strings.

Testing and verification

Automated checkers can catch missing lang on the root element. They may miss inline or nested language changes. Combine automated tools with manual checks.

Quick manual checks

• Open the page source or use the browser inspector and check the lang attributes on elements.
• Scan for foreign-language fragments without a surrounding element that has a lang attribute.
• Use a screen reader to listen. If a phrase is pronounced wrong, confirm the element has the correct language tag.

Automated checks to use

• HTML validators to ensure attributes are well formed.
• Accessibility linters and scanners for missing root lang.

Real-world example: multilingual product description

Imagine a product page in British English with quoted customer comments in Spanish. Mark the page as lang="en-GB". Wrap each customer quote in an element with lang="es". If a quoted sentence contains an English trademark, mark that word back to en-GB.

<html lang="en-GB">
  <body>
    <h2>Coffee machine</h2>
    <blockquote lang="es">Me encanta. Funciona muy bien.</blockquote>
    <p>The brand <span lang="en-GB">SuperBrew</span> is popular in Europe.</p>
  </body>
</html>

Checklist: apply WCAG 3.1.2

• Set the primary language on the <html> element.
• Wrap any passage or phrase in a tag with the correct lang or xml:lang.
• Use valid BCP 47 language tags and include subtags when needed.
• Do not rely on ARIA or CSS for language declaration.
• Test with browser inspector and a screen reader. Add automated scans as an extra layer.

Where to get help

If you have an accessibility team or vendor, ask them to audit inline language use as part of content reviews. Developers can add validation rules in the CMS to require language metadata before content is published.

Bottom line: mark any passage whose language differs from the page language using lang or xml:lang. That simple step prevents mispronunciation, improves clarity for assistive users, and helps meet the Language of Parts requirement.