RGAA Lab

RGAA 4.1.2 · Éléments obligatoires · Critère 8.4

Pour chaque page web ayant une langue par défaut, le code de langue est-il pertinent ?

Un code valide mais faux — `lang="en"` sur une page française — est pire qu'une absence : la synthèse vocale applique avec assurance les mauvaises règles de prononciation.

Ce que dit le référentiel

Transcription du RGAA 4.1.2, sans interprétation. C’est ce texte qui fait foi, et celui que vous citez dans un rapport.

  1. 8.4.1
    Pour chaque page web ayant une langue par défaut, le code de langue vérifie-t-il ces conditions ?
    • Le code de langue est valide ;
    • Le code de langue est pertinent.

Comment le vérifier

  1. Lire la valeur de lang sur l'élément html.
  2. Vérifier que c'est une étiquette de langue valide : fr, fr-FR, fr-CA — pas french, pas FR_fr.
  3. Vérifier, en lisant la page, quelle langue est réellement majoritaire.
  4. Une sous-étiquette de région discutable (fr-US) ne rend pas le code invalide, mais rarement pertinent : c'est la langue principale qui compte.

Ce que notre outil fait

Détecté automatiquement

Notre moteur tranche seul sur ce critère : un échec est une non-conformité, avec la preuve qui va avec.

Deux règles se partagent le travail : l'une contrôle que l'étiquette existe au registre, l'autre compare la langue déclarée au vocabulaire réellement employé dans la page. La seconde s'abstient plutôt que de deviner — pages sans mots reconnus, langues hors de nos vocabulaires embarqués — et vous renvoie alors la question.

Règles ACT du W3C mises en œuvre : bf051a, ucwvc8

Comment nous mesurons ce que l'outil sait faire · ce critère s'audite dans l'extension RGAA Lab.

Les pièges

Les erreurs qu’on rencontre vraiment, relevées au fil des audits.

  • Une citation étrangère mal balisée ne rend pas la langue par défaut fausse : elle relève du 8.7, pas d'ici.
  • lang="en-US" laissé par le gabarit d'origine sur un site entièrement français est le cas le plus courant.

À lire avec