Language of Page

In brief

A screen reader has to know which language it is reading. If a Turkish page is not marked as Turkish, the reader may pronounce the words with English rules and the result is nonsense. The same information lets browsers choose the right fonts and hyphenation, translation tools pick the source language, and captions display correctly.

This criterion requires that the default human language of each web page can be programmatically determined. For HTML, that means a valid lang attribute on the html element.

What does it cover?

• The default language: The language used for the page as a whole. If a page mixes languages, the default is the one used most. If they are used equally, it is the one used first.
• How to declare it: In HTML, put lang on the html element (H57). In PDF, set the /Lang entry in the document catalog (PDF16).
• Valid codes: Use a valid language tag (BCP 47) such as en or tr. A region subtag such as en-GB is allowed.
• Every page: The language must be declared on each page, including error pages, pop-up pages and generated pages.
• Changes of language inside a page: They are covered by 3.1.2 (Language of Parts), which is Level AA. For multilingual pages W3C strongly encourages following 3.1.2 as well.
• No exceptions: The criterion itself lists none.

Who does it affect?

Screen reader users, who need the right pronunciation rules. People who use text-to-speech to read more easily, including people with dyslexia and other reading or learning disabilities. Braille users, whose software chooses the right braille table. People who rely on captions that display in the right language. It also helps translation tools and search engines.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. A programmatically available page language is part of "understandable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 3.1.1 by reference and turns it into separate clauses for each kind of ICT.

Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 3.1.1 is the same in WCAG 2.1 and 2.2.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. A missing lang attribute

Without it, a screen reader falls back to a default that may be wrong for the page (H57).

<!DOCTYPE html>
<html>
<head><title>Hoş geldiniz</title></head>

<!DOCTYPE html>
<html lang="tr">
<head><title>Hoş geldiniz</title></head>

2. A value that is not a language code

The value must be a valid language tag.

<html lang="english">

<html lang="en">

3. A language that does not match the content

A page written in Turkish but marked as English is read with the wrong pronunciation.

<html lang="en">
<body><h1>Erişilebilirlik kontrol listesi</h1>

<html lang="tr">
<body><h1>Erişilebilirlik kontrol listesi</h1>

4. A regional variant

A region subtag is allowed and can help with spelling and pronunciation.

<html lang="en_GB"> <!-- underscore is not valid -->

<html lang="en-GB">

5. Put it on the html element, not on body

The default language belongs on the root element so that it applies to the whole document, including the title.

<html>
<body lang="fr">

<html lang="fr">
<body>

6. A language switcher that updates the page

A script that changes the language of the visible content must also change the lang attribute.

showTurkish(); // content changes, lang stays "en"

showTurkish();
document.documentElement.lang = "tr";

Code examples for mobile

Native apps do not have a lang attribute. They take the language from the localisation that the platform selects, so provide proper localised resources rather than hard-coded strings.

iOS (SwiftUI)

import SwiftUI

struct WelcomeView: View {
    var body: some View {
        // The key is looked up in Localizable.strings for the user's language,
        // so the text matches the language the user has chosen
        Text("welcome_title")
    }
}

// Localizable.strings (en)
// "welcome_title" = "Welcome";
// Localizable.strings (tr)
// "welcome_title" = "Hoş geldiniz";

Android (Jetpack Compose)

import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.res.stringResource

@Composable
fun WelcomeTitle() {
    // The string comes from res/values (default) or res/values-tr
    // for the language the platform selects
    Text(stringResource(R.string.welcome_title))
}

// res/values/strings.xml
// <string name="welcome_title">Welcome</string>
// res/values-tr/strings.xml
// <string name="welcome_title">Hoş geldiniz</string>

How to test

• View the source: Open the page source or the developer tools. Does the html element have a lang attribute?
• Check the value: Is it a valid language tag, and does it match the main language of the page?
• Check every template: Test home, content, error, login, checkout and pop-up pages. Each needs the attribute.
• Check generated pages: Emails rendered as web pages, print views and embedded frames can lose the attribute.
• Listen: Read the page with a screen reader. Is the pronunciation right for the language?
• Check documents: In a PDF, check the document language in the document properties.
• Use a checker as a starting point: Tools such as axe (rules html-has-lang and html-lang-valid) detect missing and invalid values. They cannot tell if the value matches the content, so a person must check that.

Common mistakes

• No lang attribute: The most common failure, and the easiest to fix (H57).
• Wrong language: A template with lang="en" used for pages in another language.
• Invalid values: lang="english", lang="en_US" or an empty value.
• Setting it on body or a wrapper: The document title and root remain unmarked.
• A language switcher that does not update lang: The content changes, the declaration does not.
• Forgetting PDFs and documents: The language must also be set in the document properties.
• Only the home page is correct: Other templates are overlooked.
• Believing 3.1.2 replaces it: Marking passages does not remove the need for a default language.

Sources

• Understanding SC 3.1.1: Language of Page (W3C), opens in a new tab
• H57: Using the language attribute on the HTML element (W3C), opens in a new tab
• Declaring language in HTML (W3C Internationalization), opens in a new tab
• Directive (EU) 2019/882, European Accessibility Act (EUR-Lex), opens in a new tab
• EN 301 549 V4.1.1 (ETSI), opens in a new tab
• The European accessibility standard EN 301 549 has been updated (AccessibleEU), opens in a new tab

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.