WCAG 3.1.1 Language of Page is a Level A success criterion that requires the default human language of every web page to be set in the code so software can read it. In plain terms: each page must declare what language it’s written in — almost always with a lang attribute on the <html> element, like <html lang="en">.

What WCAG 3.1.1 actually requires

The full text of the criterion is short: “The default human language of each Web page can be programmatically determined.” Programmatically determined means a machine — a screen reader, a braille display, a browser’s translation engine — can read the value directly from your markup instead of guessing.

The required language is the one used most on the page. If a page mixes German and English but is mostly German, the default is German (lang="de"). When two languages are used equally, the W3C guidance says to declare whichever appears first.

That’s the whole obligation at Level A: one correct declaration per page. It does not require you to mark up individual foreign phrases — that’s the separate Level AA criterion, SC 3.1.2 Language of Parts, which the W3C “strongly encourages” you to adopt too on multilingual sites.

Who it affects

This is a quiet criterion with a loud impact for a specific group of users.

  • Screen reader users (JAWS, NVDA, VoiceOver, TalkBack). A screen reader loads pronunciation rules — phonemes, intonation, syllable timing — based on the declared language. With no language set, it falls back to the operating system default. So a French page read by an English-configured screen reader becomes a stream of mangled, often unintelligible sound. Setting lang="fr" makes the same content read in a natural French voice. See how screen readers work for the bigger picture.
  • Braille display users. As the W3C’s technique H57 notes, the language tag lets braille translation software handle accented characters and contractions correctly. A wrong language can produce garbled braille.
  • People with dyslexia, low literacy, or cognitive disabilities who rely on text-to-speech to read along — the correct voice and pacing matter for comprehension.
  • Anyone using browser translation or a dictionary lookup, which both key off the declared language.

For non-disabled visitors the page looks identical either way, which is exactly why this defect survives for years until a scanner or a tester finds it.

Concrete failures and the fixes

These are the patterns we find and correct during remediation.

Failure 1 — No lang attribute at all. The most common form. Many themes and page builders ship <html> with no language.

<!-- Fails 3.1.1: no language declared -->
<html>

<!-- Passes: declare the page's primary language -->
<html lang="en">

Failure 2 — An invalid or made-up value. lang="english" is not a BCP 47 tag, so it fails even though it looks intentional. Use the ISO 639 code instead.

<!-- Fails: not a valid language tag -->
<html lang="english">

<!-- Passes: en, with optional region subtag -->
<html lang="en">      <!-- generic English -->
<html lang="en-US">   <!-- US English -->
<html lang="pt-BR">   <!-- Brazilian Portuguese -->

Failure 3 — The wrong language. A Spanish-language site that inherited lang="en" from a starter template will be read aloud by an English voice. The fix is to match the declaration to the content the page actually uses most.

Failure 4 — Template copies the wrong root for XHTML. If you serve XHTML, set both attributes: <html lang="en" xml:lang="en">. For ordinary HTML5 pages, lang alone is enough.

Failure 5 — A multilingual page with no marked-up parts. If your mostly-English page embeds a Spanish testimonial, 3.1.1 is satisfied by <html lang="en">, but a screen reader will read the Spanish in an English accent. Marking the passage (<blockquote lang="es">…</blockquote>) is the 3.1.2 Language of Parts fix — worth doing, and required at AA.

How to test it

You can verify 3.1.1 in under a minute, and it’s one of the few criteria automated tools catch reliably.

  1. View source. Look at the opening <html> tag. Confirm a lang attribute exists and holds a real language code that matches the page content.
  2. Run a scanner. Browser tools and automated checkers flag “missing document language” or “invalid language tag.” A free Curbcut scan surfaces it immediately.
  3. Validate the tag value. Confirm it’s a valid BCP 47 tag (e.g. en, es, fr, zh-Hans), not a guess like lang="us" or lang="english".
  4. Spot-check with a screen reader. Turn on VoiceOver or NVDA and listen to the first sentence. If the accent matches the content, the declaration is working.

Because this defect is invisible on screen, pair the scan with manual review on any site with more than a handful of templates — a CMS can apply the right language to one layout and miss another.

Why it matters legally

WCAG 3.1.1 carries weight beyond user experience. Missing document language is genuinely widespread: the 2026 WebAIM Million report found 13.5% of the top one-million home pages had an absent or invalid document language — down from 15.8% the year before, but still roughly one site in seven. Because it’s machine-detectable, it’s an easy item for a plaintiff’s tester to document.

That matters because website accessibility litigation keeps climbing. Plaintiffs filed 3,117 website accessibility lawsuits in U.S. federal court in 2025, a 27% jump over 2024, according to the Seyfarth ADA Title III blog; counting state courts, UsableNet tracked more than 5,000 digital accessibility cases for the year. Courts and the DOJ treat WCAG 2.1 AA as the practical yardstick for an accessible site, and 3.1.1 is a Level A item — the floor — so a missing lang attribute is among the cheapest findings to list in a demand letter.

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

Fixing it the right way

Setting lang correctly is a one-line change per template — but doing it across a real site means auditing every layout, confirming each value matches the content, and adding 3.1.2 part-level markup where languages mix. Curbcut handles this as hands-on code work. We are deliberately anti-overlay: an overlay widget can’t reliably set or correct your document language, and it won’t satisfy WCAG conformance or a skeptical court. (More on why overlays don’t work.)

Language of Page is one of dozens of checkpoints in a full WCAG 2.1 AA review, alongside color contrast, alt text, and keyboard support. It’s low-effort and high-certainty, which makes it a smart place to start. Run a free scan and we’ll tell you exactly what your pages declare — then fix the gaps in your code.