Criterion 8.5 requires that every web page declares its default language. Concretely, that's the `lang` attribute on the `<html>` tag. One word, one attribute — and yet one of the most frequent omissions in e-commerce, because it's invisible to the eye and no visual bug flags it.

Why it genuinely matters

Without `lang`, a screen reader set to French pronounces English text with French phonetics — "add to cart" turns into incomprehensible mush. The language declaration drives the synthetic voice, but also word hyphenation, typographic quotes and the browser's automatic-translation prompt. It's a setting that serves everyone, not just blind users.

The strict minimum

<html lang="en">

This line must appear on every page. ISO 639-1 codes (fr, en, de, es, it) are accepted; regional codes (en-US, fr-FR) are recommended when the variant matters. One value per page: that of the page's majority language.

How to check in 10 seconds

  1. 01Open the page, right-click, "View page source"
  2. 02Check the very first tag: `<html lang="en">` and not a bare `<html>`
  3. 03On a multilingual site, reload an /fr/ page and confirm the value switched to `fr`

Multilingual sites

The `lang` must change dynamically with the page served — an /fr/ that stays at `lang="en"` is as wrong as a missing attribute. On Nuxt with @nuxtjs/i18n, it's `htmlAttrs.lang` handled via `useHead({ htmlAttrs: { lang: locale.value } })`. On PrestaShop, the base theme normally injects the right value from `iso_code_lang` — recheck it after every theme change. On multilingual WooCommerce (WPML, Polylang), the plugin handles the attribute, but a custom theme can override it.

The silent error from a bought template

Many sites carry a `lang="en"` inherited from a purchased HTML template, never corrected to the real language. The whole site is then read with the wrong voice by screen readers. Nobody sees it — except the affected user.

Quotes in another language (criterion 8.6)

If part of a page is in a language other than the main one — a foreign customer testimonial, a foreign product name, a legal notice — wrap it in a `<span lang="fr">…</span>`. The screen reader then switches its pronunciation for the duration of the passage. That's criterion 8.6, a direct cousin of 8.5: often forgotten, trivial to fix.

// The link with multilingual SEO

The `lang` attribute isn't a direct ranking signal, but it works together with your `hreflang` tags: a site whose declared language contradicts its `hreflang` sends an inconsistent message to search engines. Consistent `lang` + `hreflang` = a clean multilingual signal.

Frequently asked questions

en or en-US?

Both are valid. `en` is enough for compliance. `en-US` (or `en-GB`) specifies the regional variant and is only useful if you actually serve regionalised content. What matters most is consistency across the whole site.

A lang everywhere, or only on <html>?

A single `lang` on `<html>` for the page's default language (8.5). Local `lang` attributes only on passages in another language (8.6). No need to put one on every tag.

Does my language switcher change the lang on its own?

Not automatically. Switching language via a selector must serve a new page (or re-render the app) with the `lang` updated. If your switcher only translates the text without touching the attribute, criterion 8.5 stays failing.

Check the `lang` of every page of your store, automatically:

→ Run an audit