Language of Page
Every page has to declare its main language in a way software can read, and on the web that means one attribute on the html element. A screen reader reads it to pick a pronunciation engine. Leave it off and the software guesses. English text can then come out through French pronunciation rules, which turns clear sentences into noise. The rule asks for the default language, and on a page that mixes two languages the default is the one used most. So a German page carrying an English quote or two is still a German page, and de is the right answer.
Why it matters
One attribute decides how every word on the page gets pronounced, which makes this the cheapest fix in the whole standard. It costs about ten characters in one template. Screen readers read it to load the right pronunciation rules. Braille software reads it to insert the control codes that stop it building the wrong contractions in Grade 2 braille, the shorthand most braille readers use. Visual browsers read it to render characters and scripts correctly. Media players read it to pick a caption track. Four kinds of tool, one line of markup, written once.
Who this rule protects
Screen reader users hear the whole page mispronounced when the attribute is missing or wrong, because their software has nothing else to go on. People who find reading hard, and who use text-to-speech to get through a page, hit the same wall for the same reason. Braille displays and translation tools depend on the attribute too. So do people relying on captions, since a media player uses the page language to decide which track to show.
How to check it yourself
- View the page source and confirm the html element carries a lang attribute whose value is a real language tag, such as en or ar rather than english.
- Read the page and decide what language it is actually in, then check the tag matches. On a page that mixes languages the answer is whichever language is used most, and a tie goes to the one that appears first.
- Check templates and error pages on their own. A 404, a print view or a transactional page is often generated by a different system, and it gets missed when the main layout is fixed.
- If the site swaps languages without a page load, switch language and look again. The rule applies to the page as the user has it, not as the build produced it.
- Check any PDF you publish separately, since a PDF carries its own language declaration in the document catalog rather than inheriting one from your HTML.
Failures we see most often
- The page carries no lang attribute at all, so the screen reader falls back to whatever voice the user has set and reads the page in that.
- A migrated site kept lang="de" on what is now English content, left over from the template it was built on. It is well formed, it passes both approved rules, and it is wrong.
- A fully Arabic page has lang="en" hardcoded in the layout, so a screen reader tries to read Arabic script with English pronunciation rules.
- The server sends a Content-Language header and the html element carries nothing. Setting the language in the HTTP header is an advisory technique rather than a sufficient one, so on its own it does not satisfy this rule.
- A single-page app switches its whole interface to French and leaves lang="en" in place, because the attribute was written once at build time and never touched again.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Blind and screen reader userspeople who cannot see the screen
How this one is tested
We list 3 ACT rules against 3.1.1. Each one defines exactly what a checker looks at, which is how automated tools decide what to flag. Each one also checks a slice, so passing every rule here is not the same as meeting the criterion, and a rule can be proposed rather than approved or need a person to finish it. The note beside each says which.
- HTML page has lang attributeA tool can check this
- HTML page lang attribute has valid language tagA tool can check this
- HTML page language subtag matches default languageA tool can check this
How to fix it
- Set the lang attribute on the html element in your base layout, and drive its value from the page's own language instead of hardcoding one string. Do it once and every page in that layout inherits the fix.
- On a page that genuinely mixes languages, declare the one used most and mark the exceptions individually. Marking the exceptions is 3.1.2, which sits at AA, and the Working Group asks multilingual sites to follow it even when they are only aiming at Level A.
- Use the primary language code, such as en, fr or ar. Region subcodes like fr-CA are optional refinements, so add one only where the regional difference changes something for your reader.
- Declare the language on PDFs too, in the document catalog, since each document carries its own and none of them inherit yours.
Step-by-step fix guides (4)
Passes vs. fails
Passes
The page ships as <html lang="en">, so every word is pronounced as English, on every page that layout renders.
Fails
The page ships as an html element with no lang attribute, so a screen reader reads it in whatever voice the user last set, and the words arrive as sounds rather than as English.
In audits and lawsuits
A scanner will catch a missing attribute and a malformed one, because those are the two approved automated rules for this criterion. What it will not catch is the more common case, which is a tag that is well formed and simply wrong. An English page that still says lang="de" from the template it was built on passes both rules and fails every user. The rule that compares the declared language against the actual content is still only proposed, so no tool is obliged to run it. That gap is why we read the tag and the page together, and it is why a clean scan on this criterion proves less than it looks like it proves.