3.1.1 Language of Page
- Level A
- Understandable
- Since WCAG 2.0
Summary
Screen readers pick their pronunciation rules from the language the page declares, not from the language the text happens to be written in. When the declaration is missing or wrong, the synthesiser applies the wrong phoneme set to every word: an English voice reading a German page with English pronunciation rules produces output that is garbled from the first sentence to the last. The people most affected are screen reader users, but braille translation tables, automatic captioning, and translation tools all rely on the same signal, so one attribute quietly underpins several assistive technologies at once.
The auditor's mental model is a three-part check performed once per page: is a default language declared at all, is the declared code a valid language code, and does it match the language most of the content is actually written in? All three must hold to pass. This is one of the cheapest criteria to fix and one of the most damaging to fail, because a wrong page-level declaration degrades the entire page rather than a single component.
Official wording
The default human language of each web page can be programmatically determined.
EN 301 549 mapping
- Web pages
- Clause 9.3.1.1
- Software and native apps
- Clause 11.3.1.1 (via Table 11.10)
- Closed functionality (kiosks, terminals)
Closed systems with speech output must meet clause 5.1.3.14 on spoken languages.
Clause 9.3.1.1 applies this criterion to web pages unchanged. For software, clause 11.3.1.1 carries an adapted version (Table 11.10) named for software rather than pages. Closed systems with speech output must meet clause 5.1.3.14 on spoken languages.
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
Open the browser developer tools and inspect the html element. It should carry a lang attribute with a valid BCP 47 code (en, de, fr-CA, pt-BR) that matches the primary language of the page's content. A bare primary subtag is sufficient: lang="en" passes on a British English page, and a regional subtag like en-GB is a refinement, not a requirement. Codes must be real: values like lang="english" or a wrong code such as sp for Spanish are not programmatically determinable language declarations. The attribute belongs on the html element; a lang on body or a wrapper div sets the language of that subtree, not the page default.
Then verify the code against the content, not against the site's intent. The classic failure pattern is a shared template: a CMS or framework layout hardcodes lang="en" and every translated variant of the site inherits it, so the German and French pages all declare English. Check at least one page per language variant. In single-page applications, the declaration lives on the app shell; if client-side routing swaps content between languages without updating document.documentElement.lang, pages after the switch declare the wrong language even though the initial load was correct.
Finish by listening. Load the page with a screen reader (VoiceOver with Safari, or NVDA on Windows) and confirm the voice and pronunciation match the content language. Mispronunciation of ordinary body text across the whole page is the audible symptom of a missing or wrong declaration.
iOS
The European standard carries an adapted version of this requirement for software, named for software rather than pages, so native apps are in scope. On iOS the page-level lang attribute has no direct equivalent; the platform's localisation system does the job. Apps declare their supported localisations, the system resolves a locale from the user's language settings, and VoiceOver selects its voice and pronunciation rules from the resolved app locale. An app that ships its strings through the standard localisation bundles gets this criterion largely for free, which is why the audit here is a listening check rather than an attribute inspection.
Test by running VoiceOver over each screen and confirming the announced pronunciation matches the language of the visible text. The mismatch cases are where findings live: strings hardcoded in a different language from the app's locale (an English-localised app with German legal text pasted into a settings screen), server-driven content delivered in another language, or an app whose UI is fully translated but whose locale declaration only lists the original development language, so VoiceOver reads the translation with the wrong voice. Accessibility Inspector in Xcode can confirm what VoiceOver will speak, but the definitive evidence is the audio itself.
Android
The same adapted software requirement in the European standard applies. Android resolves language through locale resources: string resources under locale-qualified folders, plus the app's declared supported locales (including per-app language settings on current Android versions). TalkBack picks its text-to-speech voice from the resolved locale and can switch languages when content is tagged with a different one, so a correctly localised app announces in the right voice without any extra work from the developer.
Audit by listening with TalkBack enabled: navigate each screen and confirm the pronunciation matches the content language. Failure spots mirror iOS: hardcoded literals that bypass the resource system and remain in the development language inside a translated app, server-delivered content in a different language from the app locale, and translated apps whose declared locale list omits the translation so the synthesiser applies the wrong rules. Where the product is a closed system with speech output (a kiosk or embedded device with no user-installed assistive technology), the European standard expects the speech output itself to handle the spoken languages appropriately, so grade the built-in speech, not a hypothetical screen reader.
Pass and fail examples
Passes:
- An English page with
lang="en"on thehtmlelement: declared, valid, and matching. - A German page with
lang="de", confirmed by NVDA reading the content with German pronunciation. - A British English page declaring
lang="en"without theGBregion subtag: primary subtags are sufficient. - An iOS app whose strings all flow through localisation bundles, where VoiceOver announces every screen in the voice matching the displayed language.
- An Android app with locale-qualified string resources and per-app language support, announced correctly by TalkBack in each supported language.
Fails:
- No
langattribute on thehtmlelement at all: the default language cannot be programmatically determined. - A wholly French page declaring
lang="en"because every locale shares one hardcoded template. lang="english"orlang="sp": not valid language codes, so no determinable language.- A single-page application that swaps from English to Spanish content on a route change without updating
document.documentElement.lang. - A translated Android app with hardcoded development-language strings on key screens, read by TalkBack with the wrong pronunciation rules against the surrounding translated content.
Not a fail under this criterion:
- An inline foreign phrase (a French quotation in an English article) without its own language mark-up: that is Language of Parts, which governs passages within a correctly declared page.
- Alt text that is unhelpful, inaccurate, or written in the wrong language: text alternative quality is graded under SC 1.1.1 Non-text Content, not here.
- A correctly declared language for which the user has not installed a matching synthesiser voice: the declaration is the author's responsibility, the voice is the user's platform configuration.
lang="en"on a page written in American English audited from the UK: region subtags are not required, and a plausible regional variant is not a mismatch.
Commonly confused with
- Language of Parts, SC 3.1.2. The sibling criterion at Level AA. 3.1.1 asks whether the whole page declares its default language; 3.1.2 asks whether passages in another language are individually marked. A German paragraph on an English page is a 3.1.2 finding; an English declaration on a German page is a 3.1.1 finding. File by scope: whole page here, inline passages there.
- Text alternative quality, SC 1.1.1 Non-text Content. Auditors sometimes file wrong-language or poor alt text here because a screen reader mispronounces it. The pronunciation of a page follows the page declaration; the content of a text alternative is a 1.1.1 question.
- Understandability criteria, SC 3.1.3 Unusual Words (Level AAA). 3.1.1 is about machines identifying the language, not about humans understanding the vocabulary. Jargon-heavy but correctly declared English is not a finding here.
- Locale formatting. Dates, currencies, and number formats in an unexpected regional convention are a localisation quality issue, not a failure to programmatically determine the page language.
How AUDITSU tests this
AUDITSU's audit walkthrough runs with a screen reader active, so this criterion is tested the way users experience it. On web audits the walkthrough prompts you to inspect the html element's lang attribute once per page, confirm the code is valid and matches the content, and listen for wrong-language pronunciation as you traverse the screen. On iOS and Android audits the check is auditory: with VoiceOver or TalkBack running, you confirm the announced pronunciation matches the content language on each screen, which catches hardcoded strings and locale mismatches that a static inspection misses.
Each check records a pass, fail, or not applicable result per screen with evidence attached, so a template-wide wrong declaration surfaces as a consistent pattern across pages rather than a scatter of duplicates, and a single hardcoded screen in an otherwise localised app is pinned to the exact screen where it occurs.
For the full guided workflow, see the audit platform.