Dans chaque page web, le code de langue de chaque changement de langue est-il valide et pertinent ?
Un lecteur d’écran choisit son moteur de prononciation selon la langue déclarée dans le code. Posez lang="fr" sur un passage en anglais, et NVDA lira « Hello, world » avec une voix française. Résultat : inintelligible. Critère 8.7 exige que les changements de langue soient signalés ; critère 8.8 exige que ces signaux soient corrects.
Deux conditions doivent être réunies pour chaque attribut lang porté sur un changement de langue. Le code doit être valide : conforme à BCP 47, dont la base est ISO 639-1 (codes à deux lettres comme fr, en, de, es). lang="french" ou lang="anglais" sont des codes invalides, ce sont des noms de langues en toutes lettres, pas des identifiants normalisés. Le code doit être pertinent : lang="de" sur un texte en allemand, pas sur un texte en espagnol.
Code invalide et code non pertinent sont deux erreurs distinctes. Un lang="fr" sur un texte anglais, c’est un code valide mais non pertinent. Un lang="english" sur un texte anglais, c’est un code pertinent mais invalide. Les deux font échouer le test 8.8.1.
Un test pour contrôler la validité des codes de langue utilisés
Validité et pertinence du code lang sur les changements de langue
Reprenez chaque passage de texte identifié lors du test 8.7.1 (textes dans une langue différente de la langue par défaut de la page, portant un attribut lang ou xml:lang).
- Vérifiez que le code de langue est valide : il doit être conforme à BCP 47. Exemples valides :
fr,en,de,zh,pt-BR,ar. Exemples invalides :french,allemand,eng-uk(mal formé). - Vérifiez que le code de langue est pertinent : la valeur doit correspondre à la langue réelle du passage. Un texte en japonais marqué
lang="zh"(chinois) est non pertinent. - Si les deux conditions sont remplies pour tous les passages identifiés, le test est validé. Un seul passage invalide ou non pertinent fait échouer le critère.
Exemples
❌ Non conforme : Code de langue invalide : nom de langue au lieu du code normalisé
<p>Pour aller plus loin, consultez notre <span lang="english">knowledge base</span>.</p>lang="english" n’est pas un code BCP 47 valide. Les lecteurs d’écran ne reconnaissent pas ce format et peuvent ignorer la déclaration. Le terme « knowledge base » sera lu avec la voix française par défaut. Le code correct est lang="en".
❌ Non conforme : Code valide mais non pertinent : mauvaise langue déclarée
<blockquote lang="fr">
<p>Das Pferd frisst keinen Gurkensalat.</p>
</blockquote>Ce texte est en allemand, mais l’attribut déclare le français. JAWS et NVDA choisiront la voix française pour lire de l’allemand, produisant une prononciation systématiquement erronée. C’est une erreur plus insidieuse que l’absence de lang, car elle induit activement les technologies d’assistance en erreur.
✅ Conforme : Code valide et pertinent avec sous-étiquette régionale
<p>Notre politique est également disponible en anglais :
<span lang="en-GB">This privacy policy is governed by English law.</span>
</p>lang="en-GB" est un code BCP 47 valide (code primaire en et sous-étiquette régionale GB) et pertinent car le texte est bien en anglais britannique. La sous-étiquette régionale est facultative mais correcte ici. lang="en" seul aurait aussi satisfait le critère.
Astuces et pièges
⚠️ Copier-coller un composant sans vérifier l’attribut lang
C’est l’erreur la plus fréquente en audit. Un développeur copie un bloc HTML avec son lang="fr" et l’intègre dans une section en anglais. Le code reste valide (ISO 639-1), mais il est devenu non pertinent. Les composants réutilisables comme les blocs de citation et les encarts éditoriaux multilingues sont particulièrement exposés.
⚠️ Noms de langue complets au lieu des codes
On rencontre régulièrement lang="french", lang="german", lang="arabic" dans des bases de code anciennes. Ce sont des noms de langues, pas des codes BCP 47. Les valeurs correctes sont fr, de, ar. Le critère 8.8 considère ces valeurs comme invalides même si la langue visée est la bonne, ce qui peut surprendre lors d’un premier audit.
💡 Auditer rapidement tous les attributs lang de la page
Dans la console des DevTools, lancez document.querySelectorAll('[lang]') pour lister tous les éléments portant un attribut lang. Vérifiez chaque valeur : deux lettres minimum, conforme à BCP 47, et correspondant à la langue du contenu visible. Includdy signale automatiquement les codes non reconnus.
⚠️ Sous-étiquettes régionales : obligatoires ou facultatives ?
Le code primaire suffit pour satisfaire le critère 8.8. lang="en" est valide et pertinent pour de l’anglais, qu’il soit britannique ou américain. Les sous-étiquettes en-GB ou en-US sont valides et peuvent affiner la prononciation selon la voix disponible, mais leur absence n’est pas une non-conformité.
⚠️ Termes techniques, noms propres et mots indéterminés
Ces éléments sont hors périmètre du critère 8.7 et donc de 8.8 : vous n’avez pas à marquer « JavaScript » ou « Paris » dans un texte français. En revanche, si vous choisissez de les marquer malgré tout, le code posé doit être valide et pertinent sous peine de faire échouer 8.8.
Questions fréquentes
Quels codes de langue sont valides selon les spécifications HTML et RGAA ?
Les codes conformes à BCP 47, dont la base est ISO 639-1 (deux lettres : fr, en, de, ja, ar, zh). Les codes ISO 639-2 et 639-3 à trois lettres sont valides pour les langues sans équivalent à deux lettres. Les sous-étiquettes régionales bien formées (en-GB, pt-BR, zh-Hant) sont aussi acceptées. Un nom de langue complet en toutes lettres (french, allemand) est systématiquement invalide.
En quoi un attribut lang erroné diffère-t-il d'un lang absent en RGAA ?
Oui, dans la majorité des cas. Sans lang, le lecteur d’écran hérite de la langue de la page et prononce le texte avec cette voix, résultat souvent approximatif mais pas catastrophique. Avec lang="fr" sur du texte anglais, il applique activement les règles phonétiques françaises à un contenu anglais, produisant une prononciation systématiquement erronée. L’erreur de pertinence induit les technologies d’assistance en erreur de façon active.
Comment les critères RGAA 8.7 et 8.8 diffèrent-ils sur la langue de la page ?
Critère 8.7 vérifie la présence du marquage : un changement de langue est-il signalé dans le code source ? Critère 8.8 vérifie la qualité de ce marquage : le code utilisé est-il valide (BCP 47) et pertinent (bonne langue) ? Un passage sans lang échoue à 8.7 et 8.8 n’est pas applicable. Un passage avec lang="french" passe 8.7 mais échoue à 8.8.
Comment détecter automatiquement des attributs lang invalides dans une page web ?
Includdy et le validateur W3C (validator.w3.org) signalent les valeurs lang non reconnues dans BCP 47. Ils couvrent les cas évidents : noms de langues, codes mal formés, valeurs vides. La vérification de pertinence, c’est-à-dire confirmer que le code correspond à la langue réelle du contenu, reste une opération manuelle.
Comment baliser correctement un mot étranger isolé avec l'attribut lang en RGAA ?
Non, seulement sur les passages dans une langue différente de la langue par défaut de la page, comme l’exige critère 8.7. Un mot technique isolé (cache, widget, open source) n’a généralement pas besoin de marquage. Dès qu’il s’agit d’une expression ou d’un passage rédigé dans une autre langue, le marquage s’impose et le code doit être valide et pertinent au sens du critère 8.8.