What does the lang attribute change?
Screen readers use speech synthesisers, and each synthesiser has voices for particular languages. The lang attribute on <html> tells the screen reader which voice and pronunciation rules to use. With lang="en" and the quote marked as French, only the name “Lac de Grand-Lieu” sounds a little odd. With lang="fr" on an English page, every English word is read with French sounds, and the page becomes very hard to follow.
When lang is missing, the screen reader falls back on the user’s default language. That works by luck for someone whose default matches your page, and fails for someone browsing in a second language. WCAG 2.2 requires it in 3.1.1 Language of Page, at level A.
Other tools use it too. Braille displays use it to pick contraction rules. Browsers use it to offer translation, to choose the right hyphenation for hyphens: auto, and to pick fonts and quotation marks for some scripts. Spell checkers use it in text fields.
<html lang="en">Which language code should you use?
Use a BCP 47 language tag. Most of the time that is a two letter code: en for English, fr for French, cy for Welsh, es for Spanish, de for German. Add a region only when it changes something for the reader, such as en-GB or pt-BR. Most screen readers treat en-GB and en-US as English with a different accent.
Get the code right. A typo such as lang="english" or lang="en_GB" with an underscore is invalid, and screen readers may ignore it and fall back to the default. Check that templates and site builders set it, since many default to en whatever language the content is in.
How do you mark a phrase in another language?
Put lang on the element that holds the foreign text: a <blockquote>, a <p>, or a <span> around a few words. That meets 3.1.2 Language of Parts at level AA. Screen readers that support it switch voice for those words and switch back afterwards.
Mark whole phrases and quotes, not every borrowed word. Words that have become part of English, like “café”, “croissant” or “rendezvous”, are read fine by an English voice. Proper names, such as “Lac de Grand-Lieu”, are also exempt. A French sentence, a Welsh sign or a song lyric in Spanish should be marked.
If the language uses a script written right to left, such as Arabic or Hebrew, add dir="rtl" too, so the browser lays it out correctly.
<blockquote lang="fr">« Le héron pourpré est rare ici, vous avez eu de la chance. »</blockquote>
<p>The café sign says <span lang="cy">Croeso i feicwyr</span>, which means cyclists welcome.</p>Why does the page title matter so much?
The <title> is the name of the page. It is the first thing a screen reader says when the page loads, the text in the browser tab, the default name of a bookmark, and usually the blue headline in search results. WCAG 2.4.2 Page Titled asks that every page has a title that describes its topic or purpose.
Someone with ten tabs open, using a screen reader, moves between them and hears only titles. Ten tabs called “Riverside Bird Club” are useless. Ten tabs called “Untitled” are worse. A good title answers two questions: what is this page, and which site is it on.
What makes a good page title?
Put the specific part first and the site name last: “Herons at Lac de Grand-Lieu, Trip Report, Riverside Bird Club”. Screen reader users hear the unique part straight away, and tabs that are cut short still show something useful. Use the same separator and order across the whole site.
Make every title unique, and keep it close to the page’s <h1>. They do not need to match word for word. For pages that change state, update the title too. A search results page might say “Search results for heron, 12 found”, and a form that failed might start with “Error:” so people hear the problem the moment the page reloads.
In single page apps, the HTML loads once and the content changes with JavaScript. Set document.title on every view change, or screen reader users never hear that they moved anywhere.
<title>Herons at Lac de Grand-Lieu, Trip Report, Riverside Bird Club</title>
<title>Error: Sign up, Riverside Bird Club</title>
How does plain language help accessibility?
Many people with cognitive or learning disabilities, people with dyslexia, people reading in a second language and people who are tired or stressed read more slowly or miss meaning in dense text. Plain language helps every one of them. WCAG 3.1.5 Reading Level, at level AAA, suggests offering a simpler version when text needs more than lower secondary school reading ability.
Use short sentences and common words. Put the most important information first. Use headings, lists and short paragraphs, so people can find their place again. Say who does what in active voice: “We need three days’ notice” is clearer than “Three days’ notice is required”.
Explain or avoid abbreviations. Write the full term the first time, with the short form after it in brackets. The <abbr> element with a title can show the expansion on hover, but touch and keyboard users never see the tooltip and screen readers often ignore it, so put the meaning in visible text.
<p>Riverside Bird Club (RBC) members get free entry.</p>How do you check language and titles?
The **Checks** view flags a missing lang and a missing or empty <title>. It cannot tell whether the language is the right one or whether the title is useful, so look yourself. Read the title aloud alone and ask whether it tells you what the page is.
In the browser, look at the tab text. In DevTools, the Elements panel shows the lang on <html> and on any element inside it. With a real screen reader, listen to a page with a foreign phrase marked up: you should hear the voice change. If you turn on speech for a page with the wrong lang, you will hear the problem within a sentence.
What do AI tools get wrong here?
Generated pages usually include <html lang="en">, even when the content is in another language, because their templates start in English. Check it on every page in a multilingual site. They also give every page the same title, often the site name alone, or a vague one like “Home” or “Page”.
AI tools rarely mark foreign phrases with lang, and sometimes translate quotes silently, so the page loses the original. Ask for the quote in its own language with lang and a translation next to it. Watch too for jargon and long sentences in generated copy, which make pages harder to read for many people.
Field notes
- The
langattribute picks the voice a screen reader speaks with. - Put
lang="en"on<html>for an English page. - Mark a foreign phrase with
langon the element that holds it. - A good title puts the page first and the site name last.
Easy to get wrong
Without lang, screen readers guess the language from the user’s settings and may read the page with the wrong voice.
The title is the first thing a screen reader says and the only text in a tab. It should name the page and the site.
Without lang="fr", an English voice reads the French words with English sounds, and they become hard to understand.
Questions people ask
Does every borrowed word need a lang attribute?
No. Words English has adopted, such as “café”, and proper names are fine without it. Mark phrases and sentences in another language.
What if the page mixes two languages equally?
Pick the main language for <html> and mark the other parts. If the page is a true side by side translation, mark each column with its own lang.
Should the title match the h1 exactly?
It does not have to. The <h1> names the content on the page, and the title adds the site name and sometimes the section. Keep them clearly about the same thing.
Does a wrong lang affect search engines?
Search engines mostly detect language from the text itself. The main effect of lang is on screen readers, braille, translation and hyphenation, which is reason enough to get it right.