WCAG 3.1.1 : Langue de la page

WCAG 3.1.1 exige que la langue humaine par défaut de chaque page web puisse être déterminée de manière programmatique, principalement en définissant un attribut lang valide sur l’élément HTML. Cela permet aux technologies d’assistance comme les lecteurs d’écran de prononcer correctement le contenu et aide les personnes ayant des handicaps cognitifs ou liés au langage à comprendre la page.

Ce que signifie cette règle

WCAG 3.1.1 — Langue de la page est un critère de succès de niveau A relevant du principe Compréhensible. Il exige que la langue humaine principale de chaque page web soit exposée de manière à ce que les technologies d’assistance puissent la détecter de façon programmatique. En pratique, cela signifie presque toujours placer un attribut lang valide directement sur l’élément <html> de la page.

La valeur de l’attribut lang doit être une balise de langue BCP 47 valide. Les balises BCP 47 se composent d’un sous-tag de langue primaire (comme en pour l’anglais, tr pour le turc, fr pour le français) et éventuellement d’un sous-tag de région séparé par un tiret (comme en-US, tr-TR ou pt-BR). La balise de langue doit refléter avec précision la langue dominante dans laquelle le contenu de la page est rédigé. Une page rédigée principalement en turc doit déclarer lang='tr' ou lang='tr-TR' ; une page rédigée en anglais doit déclarer lang='en' ou une variante régionale.

Une page réussit ce critère lorsque l’élément <html> porte un attribut lang dont la valeur est une balise de langue BCP 47 non vide, syntaxiquement valide, qui identifie correctement la langue principale de la page. Une page échoue lorsque l’attribut lang est totalement absent, lorsque la valeur est vide (lang=''), ou lorsque la valeur n’est pas une balise de langue BCP 47 reconnue (par exemple lang='turkish' ou lang='en_US' avec un underscore au lieu d’un tiret).

Pour les pages XHTML servies avec un type MIME XML, l’attribut lang et l’attribut d’espace de noms XML xml:lang doivent tous deux être présents, et leurs valeurs doivent correspondre. Une divergence entre les deux — comme lang='en' avec xml:lang='tr' — constitue un échec à la fois de ce critère et de la règle axe-core associée html-xml-lang-mismatch.

WCAG mentionne explicitement une exception : si la page est purement décorative, est un CAPTCHA qui n’a intentionnellement aucune langue discernable, ou se compose entièrement de contenu non linguistique (comme une page qui n’est qu’une image sans texte), elle peut ne pas avoir de langue déterminable. Cependant, cette exception est étroite, et la grande majorité des pages réelles contiennent suffisamment de texte pour nécessiter une déclaration de langue.

Pourquoi c’est important

Les principaux bénéficiaires d’une langue de page correctement déclarée sont les utilisateurs de lecteurs d’écran, dont la majorité sont aveugles ou ont une déficience visuelle sévère. Les lecteurs d’écran tels que NVDA, JAWS et VoiceOver utilisent l’attribut lang pour sélectionner la voix de synthèse vocale (TTS) et le moteur de prononciation appropriés. Lorsqu’un utilisateur turc visite une page qui déclare correctement lang='tr', son lecteur d’écran bascule vers une voix TTS turque, appliquant la phonologie, les schémas d’accentuation et les diacritiques turcs corrects. Sans cette déclaration, un lecteur d’écran peut revenir à la langue système de l’utilisateur ou à une langue complètement incorrecte, produisant une prononciation incompréhensible qui rend le contenu inintelligible.

Considérons un scénario concret : un citoyen turc malvoyant visite le site web d’une institution publique pour télécharger un formulaire administratif. Le site omet l’attribut lang. L’installation NVDA de l’utilisateur utilise par défaut un profil TTS anglais. Les mots turcs sont lus avec la phonologie anglaise — des mots comme « şehir » (ville) ou « başvuru » (demande) deviennent méconnaissables. L’utilisateur ne peut pas remplir le formulaire sans assistance d’une personne voyante, ce qui va à l’encontre de tout l’objectif du service numérique.

Les personnes ayant des handicaps cognitifs et des troubles d’apprentissage en bénéficient également. Les navigateurs utilisent l’attribut lang pour proposer des suggestions de traduction précises ; certaines personnes dyslexiques s’appuient sur des outils de traduction intégrés au navigateur pour convertir le contenu dans une langue qu’elles trouvent plus facile à traiter. Un attribut lang incorrect ou manquant amène ces outils à mal identifier la langue source, produisant de mauvaises traductions ou aucune proposition de traduction.

Les personnes ayant des déficiences motrices qui s’appuient sur des logiciels de commande vocale tels que Dragon NaturallySpeaking dépendent du fait que le logiciel interprète correctement la langue d’une page pour faire correspondre les commandes vocales au texte à l’écran. Une langue de page mal identifiée rompt cette correspondance.

Au-delà de l’accessibilité, il existe des bénéfices SEO tangibles : les moteurs de recherche utilisent l’attribut lang comme l’un des signaux permettant de déterminer la langue et la région cibles d’une page, améliorant la précision des résultats de recherche localisés. Un balisage linguistique correct améliore également la fiabilité des fonctions de vérification orthographique et grammaticale du navigateur pour tous les utilisateurs, et pas seulement pour ceux qui utilisent des technologies d’assistance. Selon l’Organisation mondiale de la Santé, environ 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle, dont une part importante s’appuie sur des lecteurs d’écran — ce qui fait de la déclaration correcte de la langue l’une des améliorations d’accessibilité les plus impactantes et les moins coûteuses à mettre en œuvre.

Règles Axe-core associées

html-has-lang — Cette règle vérifie si l’élément <html> possède un attribut lang. Elle signale toute page où l’attribut lang est complètement absent de la balise racine <html>, que l’attribut apparaisse ou non ailleurs dans le document. C’est l’un des constats automatisés les plus fréquents et les plus impactants, car la correction consiste en l’ajout d’un seul attribut.
html-lang-valid — Cette règle vérifie si la valeur de l’attribut lang sur l’élément <html> est une balise de langue BCP 47 valide. Elle signale les valeurs qui ne sont pas des codes de langue reconnus, comme lang='turkish' (qui utilise le nom anglais complet au lieu du code ISO 639-1 tr), lang='en_US' (qui utilise un underscore comme séparateur au lieu d’un tiret), ou lang='xx' (un espace réservé sans langue assignée). Un attribut lang existant mais contenant une valeur invalide est tout aussi problématique qu’un attribut manquant, car les technologies d’assistance ne peuvent pas s’y fier.
html-xml-lang-mismatch — Cette règle s’applique spécifiquement aux pages XHTML qui portent à la fois un attribut lang et un attribut xml:lang sur l’élément <html>. Elle signale les cas où les deux attributs spécifient des codes de langue différents — par exemple lang='en' et xml:lang='tr'. Lorsque ces valeurs sont en conflit, les technologies d’assistance et les processeurs XML reçoivent des signaux contradictoires et peuvent se comporter de manière imprévisible. Les deux valeurs doivent spécifier le même sous-tag de langue primaire.

Bien que ces trois règles couvrent les échecs programmatiques les plus courants, les outils automatisés ne peuvent pas vérifier l’exactitude sémantique — c’est-à-dire qu’ils ne peuvent pas déterminer si la langue déclarée correspond réellement à la langue dans laquelle la page est rédigée. Une page entièrement écrite en turc mais déclarant lang='en' passera les trois règles axe-core, mais échouera néanmoins à WCAG 3.1.1, car la langue déclarée ne reflète pas la langue principale réelle de la page. Un examen manuel est donc toujours nécessaire en complément de l’analyse automatisée pour confirmer que la langue déclarée est correcte.

Comment tester

Analyse automatisée avec axe DevTools ou Lighthouse : Ouvrez la page dans Chrome ou Firefox. Ouvrez les DevTools (F12), accédez au panneau axe DevTools ou à l’onglet Lighthouse, et lancez un audit d’accessibilité complet. Recherchez spécifiquement les violations des règles html-has-lang, html-lang-valid et html-xml-lang-mismatch. Axe mettra en évidence l’élément <html> et décrira l’échec spécifique. Lighthouse fera remonter des problèmes similaires dans sa catégorie Accessibilité. Notez toutes les violations signalées et les corrections recommandées.
Inspection manuelle du code source : Affichez le code source de la page (Ctrl+U dans la plupart des navigateurs) et localisez la balise d’ouverture <html>. Vérifiez qu’elle contient un attribut lang, que la valeur de cet attribut est une balise BCP 47 valide (vérifiez-la dans le registre IANA des sous-tags de langue), et qu’elle reflète avec précision la langue dans laquelle le contenu de la page est rédigé. Pour les pages XHTML, vérifiez également que tout attribut xml:lang porte le même sous-tag de langue primaire que lang.
Test avec lecteur d’écran, NVDA et Firefox : Installez NVDA (gratuit, Windows) et ouvrez la page dans Firefox. Appuyez sur NVDA+T pour lire le titre de la page et écoutez la voix TTS utilisée. Si la page est en turc, la voix doit être une voix TTS turque, et les mots turcs doivent être prononcés correctement. Si vous entendez une voix anglaise ou une autre voix incorrecte sur du contenu turc, l’attribut lang est manquant ou incorrect. Répétez avec JAWS dans Chrome et VoiceOver dans Safari sur macOS (Cmd+F5 pour activer VoiceOver, puis naviguez jusqu’à la page et écoutez la prononciation du texte du corps de page).
Vérification de la détection de langue par le navigateur : Ouvrez la page dans Chrome. Recherchez la barre de traduction intégrée du navigateur — Chrome proposera de traduire les pages qu’il identifie comme étant dans une langue étrangère par rapport aux paramètres du navigateur. Si Chrome identifie incorrectement la langue de la page ou ne propose pas de traduction alors qu’il le devrait, c’est un signal pratique indiquant que l’attribut lang est erroné ou manquant. Ce n’est pas un test d’accessibilité définitif, mais c’est un indicateur secondaire utile.
Vérification de l’exactitude sémantique (manuelle uniquement) : Lisez le contenu de la page et confirmez que la valeur lang déclarée correspond à la langue principale réelle de la page. Les outils automatisés ne peuvent pas effectuer cette vérification. Portez une attention particulière aux sites multilingues qui servent différentes versions linguistiques à partir d’URL différentes — la page de chaque URL doit déclarer sa propre langue correcte, et non hériter d’une valeur globale unique.

Comment corriger

Attribut lang manquant — Incorrect

<!DOCTYPE html>
<html>
  <head>
    <meta charset='UTF-8'>
    <title>Başvuru Formu</title>
  </head>
  <body>
    <h1>Hoş Geldiniz</h1>
  </body>
</html>

Attribut lang manquant — Correct

<!DOCTYPE html>
<html lang='tr'>
  <!-- lang='tr' indique aux lecteurs d’écran d’utiliser une voix TTS turque -->
  <head>
    <meta charset='UTF-8'>
    <title>Başvuru Formu</title>
  </head>
  <body>
    <h1>Hoş Geldiniz</h1>
  </body>
</html>

Valeur d’attribut lang invalide — Incorrect

<!DOCTYPE html>
<html lang='turkish'>
  <!-- 'turkish' n’est pas une balise BCP 47 valide ; axe signalera html-lang-valid -->
  <head>
    <title>Kurumsal Site</title>
  </head>
  <body>
    <p>Şirketimiz hakkında bilgi edinmek için buraya tıklayın.</p>
  </body>
</html>

Valeur d’attribut lang invalide — Correct

<!DOCTYPE html>
<html lang='tr'>
  <!-- Utilisez le code ISO 639-1 à deux lettres 'tr', et non le mot anglais 'turkish' -->
  <head>
    <title>Kurumsal Site</title>
  </head>
  <body>
    <p>Şirketimiz hakkında bilgi edinmek için buraya tıklayın.</p>
  </body>
</html>

Incohérence XHTML xml:lang — Incorrect

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN'
  'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'>
<html xmlns='http://www.w3.org/1999/xhtml' lang='en' xml:lang='tr'>
  <!-- lang et xml:lang ne sont pas d’accord — violation html-xml-lang-mismatch -->
  <head><title>XHTML Sayfası</title></head>
  <body><p>İçerik burada.</p></body>
</html>

Incohérence XHTML xml:lang — Correct

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN'
  'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'>
<html xmlns='http://www.w3.org/1999/xhtml' lang='tr' xml:lang='tr'>
  <!-- lang et xml:lang valent tous deux 'tr' — cohérent et valide -->
  <head><title>XHTML Sayfası</title></head>
  <body><p>İçerik burada.</p></body>
</html>

Mauvaise langue déclarée sur un site multilingue — Incorrect

<!-- Version anglaise du site, mais lang est défini globalement sur 'tr' -->
<html lang='tr'>
  <head><title>About Us</title></head>
  <body>
    <p>Welcome to our company. We specialize in accessible web solutions.</p>
  </body>
</html>

Mauvaise langue déclarée sur un site multilingue — Correct

<!-- Chaque version linguistique déclare son propre attribut lang correct -->
<html lang='en'>
  <!-- Ceci est la page anglaise ; la page turque à /tr/ déclare lang='tr' -->
  <head><title>About Us</title></head>
  <body>
    <p>Welcome to our company. We specialize in accessible web solutions.</p>
  </body>
</html>

Erreurs courantes

Utiliser le nom anglais complet de la langue au lieu de son code BCP 47 — écrire lang='turkish', lang='english' ou lang='arabic' au lieu des codes corrects tr, en et ar. Ces valeurs ne sont pas reconnues par les technologies d’assistance.
Utiliser un underscore comme séparateur de région — écrire lang='en_US' ou lang='tr_TR' au lieu des formes avec tiret lang='en-US' et lang='tr-TR'. BCP 47 exige des tirets, pas des underscores.
Définir l’attribut lang sur <body> au lieu de <html> — l’attribut lang doit se trouver sur l’élément racine <html> pour satisfaire la règle axe-core html-has-lang et fournir aux technologies d’assistance le contexte linguistique de la page avant l’analyse de tout contenu.
Laisser lang comme chaîne vide — définir lang='' est traité comme un attribut manquant par la plupart des technologies d’assistance et sera signalé par html-has-lang, car une chaîne vide n’est pas une balise de langue valide.
Copier un modèle provenant d’un projet dans une autre langue sans mettre à jour l’attribut lang — un problème très courant dans les flux de travail de développement en Turquie où un modèle en anglais est réutilisé et où le lang='en' de la balise <html> n’est jamais remplacé par lang='tr'.
Déclarer le bon attribut lang mais ne pas le mettre à jour lors du lancement d’une nouvelle version linguistique du site — les sites multilingues qui utilisent le rendu côté serveur doivent s’assurer que l’attribut lang est défini dynamiquement par locale, et non codé en dur avec une valeur unique dans un modèle de mise en page partagé.
Supposer qu’un CMS ou un framework définit automatiquement correctement l’attribut lang — de nombreuses plateformes CMS (y compris certaines configurations de WordPress, Joomla et des frameworks personnalisés) ne définissent pas par défaut un attribut lang valide. Les développeurs doivent le vérifier au niveau du modèle, et non supposer que c’est géré.
Confondre l’attribut lang (pour HTML) avec l’en-tête HTTP Content-Language — l’en-tête HTTP affecte la mise en cache et la négociation de contenu mais n’est pas utilisé par les lecteurs d’écran. L’attribut lang dans le document, sur <html>, est le mécanisme correct pour la conformité à WCAG 3.1.1.
Utiliser un sous-tag régional valide mais incorrect qui implique un dialecte différent — par exemple, déclarer lang='zh-TW' (chinois traditionnel, Taïwan) sur une page rédigée en chinois simplifié (zh-CN) peut amener un lecteur d’écran à sélectionner un profil de voix et des règles de prononciation inadaptés.
Oublier de définir lang sur du contenu de page complet injecté dynamiquement dans des applications monopage (SPA) — si une SPA charge du contenu dans plusieurs langues au sein d’une même coquille de document sans mettre à jour l’attribut lang, les utilisateurs qui naviguent entre les sections linguistiques ne bénéficieront pas d’une prononciation TTS correcte pour les nouvelles sections de contenu.

Lien avec la réglementation turque en matière d’accessibilité

WCAG 3.1.1 Langue de la page a une portée juridique directe en Turquie en vertu de la Circulaire présidentielle 2025/10, publiée au Journal officiel n° 32933 le 21 juin 2025. Cette circulaire établit des exigences obligatoires en matière d’accessibilité web alignées sur WCAG 2.2 et désigne la conformité de niveau A comme norme minimale obligatoire pour toutes les entités concernées.

La circulaire couvre un large éventail d’organisations des secteurs public et privé. Les institutions publiques — y compris les ministères, les municipalités, les universités d’État, les hôpitaux publics et l’ensemble des organismes gouvernementaux centraux et locaux — doivent atteindre une conformité complète de niveau A dans un délai d’un an à compter de la publication de la circulaire. Les entités du secteur privé couvertes par la réglementation disposent d’un délai de conformité de deux ans et incluent les plateformes de commerce électronique, les banques et institutions financières, les hôpitaux et prestataires de soins privés, les opérateurs de télécommunications comptant 200 000 abonnés ou plus, les agences de voyage, les entreprises de transport privées et les écoles privées opérant sous autorisation du ministère de l’Éducation nationale (MoNE).

Parce que WCAG 3.1.1 est un critère de niveau A, il fait partie du socle obligatoire pour chaque entité couverte par la circulaire. Le site web d’une institution publique turque qui omet lang='tr' sur son élément <html> — ou qui déclare une balise de langue incorrecte ou invalide — est en non-conformité directe avec une norme légalement obligatoire. Pour les organisations du secteur privé telles que les banques et les plateformes de commerce électronique, le même manquement, dans leur fenêtre de conformité, constitue une violation réglementaire.

La conséquence pratique pour les équipes web turques est significative : chaque modèle de page, chaque mise en page de CMS, chaque coquille de SPA et chaque page générée dynamiquement doit être audité pour confirmer la présence d’un lang='tr' valide (ou d’une variante appropriée) sur l’élément HTML racine. Il ne s’agit pas simplement d’une recommandation de bonne pratique — en vertu de la Circulaire 2025/10, c’est une obligation légale. Étant donné que les règles axe-core html-has-lang et html-lang-valid peuvent détecter automatiquement la majorité de ces échecs, il n’existe aucun obstacle technique à l’identification et à la correction de ce problème avant l’échéance de conformité.

Les organisations soumises à la circulaire devraient traiter la conformité à WCAG 3.1.1 comme un élément de remédiation prioritaire : c’est l’un des critères les plus simples à corriger (un seul attribut sur un seul élément), mais il a un impact disproportionné sur l’accessibilité de chaque page pour les utilisateurs de lecteurs d’écran — le groupe dont les droits sont le plus directement visés par la réglementation.

Sources et références

Articles connexes

AWCAG 1.1.1 : Contenu non textuel AWCAG 1.2.1 : Audio seul et vidéo seule (préenregistrés)AWCAG 1.2.2 : Sous-titres (préenregistré)