WCAG 3.1.2 : Langue des parties

Ce que signifie cette règle

WCAG 3.1.2 — Langue des parties est un critère de niveau AA relevant du principe Compréhensible. Il s’appuie directement sur 3.1.1 (Langue de la page), qui exige que la langue principale d’une page entière soit déclarée. Le critère 3.1.2 va plus loin : chaque fois qu’un passage, une expression ou une section de contenu est rédigé dans une langue différente de la langue par défaut de la page, cette portion doit porter un attribut lang identifiant sa langue spécifique.

En termes HTML pratiques, cela signifie appliquer l’attribut lang à tout élément qui englobe un changement de langue. La valeur de l’attribut doit être une balise de langue BCP 47 valide — par exemple, lang='en' pour l’anglais, lang='fr' pour le français, lang='de' pour l’allemand, ou lang='tr' pour le turc. Les sous-balises de région (telles que lang='en-US' ou lang='tr-TR') sont autorisées et recommandées lorsque la prononciation spécifique à un dialecte est importante.

Un succès se produit lorsque chaque segment linguistique distinct qu’un lecteur humain percevrait comme appartenant à une langue différente est enveloppé dans un élément avec l’attribut lang correct. Un échec se produit lorsqu’un passage dans une autre langue est présent mais ne porte aucun attribut lang, ou en porte un incorrect — par exemple, étiqueter une phrase française avec lang='de'.

Les WCAG reconnaissent trois exceptions explicites à ce critère. Premièrement, les noms propres — noms de personnes, noms de marques, noms géographiques — n’ont pas besoin d’un balisage de langue même lorsqu’ils proviennent d’une autre langue. Deuxièmement, les termes techniques qui sont reconnus comme des éléments de vocabulaire dans la langue principale (comme la locution latine in vitro utilisée dans une page médicale en anglais) sont exemptés. Troisièmement, les mots de langue indéterminée — des mots qui ont été tellement intégrés dans la langue principale que leur origine est ambiguë — sont également exemptés. Ces exceptions reflètent la réalité pratique selon laquelle de nombreux mots empruntés ne nécessitent pas de changement de prononciation pour être compris correctement.

L’attribut lang peut être placé sur n’importe quel élément HTML, y compris <span>, <p>, <div>, <blockquote>, <section> ou même <td> dans une cellule de tableau. L’attribut est hérité par tous les éléments descendants, de sorte que le balisage d’un conteneur de haut niveau est suffisant si tout un bloc est dans la langue cible. Vous n’avez besoin de baliser des éléments en ligne individuels que lorsque de courtes expressions sont intercalées dans des paragraphes par ailleurs monolingues.

Pourquoi c’est important

Les principaux bénéficiaires de ce critère sont les utilisateurs de lecteurs d’écran, en particulier les personnes aveugles ou malvoyantes. Les lecteurs d’écran s’appuient sur des moteurs de synthèse vocale (TTS) spécifiques à une langue. Lorsqu’un lecteur d’écran turc rencontre une phrase française sans attribut lang='fr', il tente de prononcer les mots français en utilisant les règles phonétiques turques, produisant un résultat largement inintelligible. L’auditeur peut même ne pas se rendre compte qu’un changement de langue s’est produit — il entend simplement un son brouillé et perd complètement la compréhension du contenu.

Considérez un scénario réel courant sur les sites turcs de commerce électronique et de tourisme : une page produit rédigée en turc qui inclut le nom de la marque et un court slogan marketing en anglais, suivi d’une clause de non-responsabilité en français pour les clients européens. Sans balisage de langue sur les segments anglais et français, un utilisateur aveugle qui s’appuie sur une voix TTS turque entendra trois segments tous prononcés comme s’ils étaient en turc. Le slogan anglais peut être deviné par similarité phonétique, mais le texte juridique français devient totalement incompréhensible — ce qui peut amener l’utilisateur à manquer des informations contractuelles ou de sécurité essentielles.

Les utilisateurs ayant des handicaps cognitifs qui s’appuient sur des outils de lecture à voix haute (et pas seulement sur des lecteurs d’écran dédiés) sont également concernés. De nombreuses extensions de navigateur d’aide à la lecture grand public utilisent l’attribut lang pour sélectionner la voix correcte. Sans celui-ci, l’outil ignore le changement de langue ou se contente d’une seule voix pour toute la page, ce qui nuit à la compréhension.

Au-delà de l’accessibilité, un balisage linguistique correct procure des bénéfices SEO mesurables. Les moteurs de recherche utilisent les attributs lang pour indexer correctement le contenu multilingue, améliorant la probabilité que des pages spécifiques à une langue apparaissent dans les résultats de recherche ciblés géographiquement et linguistiquement. Les navigateurs utilisent également l’attribut pour proposer des suggestions de traduction précises, et les outils de vérification orthographique s’y réfèrent pour appliquer le bon dictionnaire. En résumé, un marquage linguistique approprié profite à tous les utilisateurs — pas seulement aux personnes handicapées.

On estime que plus de 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle, et que des dizaines de millions s’appuient quotidiennement sur des lecteurs d’écran. Le contenu Web multilingue devient de plus en plus la norme sur les marchés internationaux, ce qui rend la conformité à Langue des parties essentielle pour tout site qui s’adresse à un public mondial ou multilingue.

Règles Axe-core associées

WCAG 3.1.2 nécessite un test manuel car les outils automatisés ne peuvent pas identifier de manière fiable quelles parties du texte d’une page sont rédigées dans une langue différente de la langue par défaut de la page sans appliquer des algorithmes de détection automatique de la langue (NLP) — et même ceux-ci peuvent être incertains avec de courtes expressions, des noms propres et une terminologie technique.

• Inspection manuelle — détection de la langue : Des analyseurs automatisés tels qu’axe-core peuvent vérifier que l’attribut lang sur l’élément <html> est présent et valide (couvert par les règles html-has-lang et html-lang-valid), mais ils ne peuvent pas parcourir l’intégralité du corps de texte et déterminer si un passage donné est linguistiquement français, allemand ou japonais. Un outil n’a aucune compréhension sémantique de la question de savoir si la chaîne "Bonjour tout le monde" est du français ou une expression inventée, il ne peut donc pas signaler l’absence de lang='fr' sur l’élément environnant.
• Inspection manuelle — valeurs lang incorrectes : Si un développeur a placé un attribut lang sur un élément mais a attribué le mauvais code de langue (par exemple, marquer du texte espagnol avec lang='pt'), les outils automatisés verront une balise BCP 47 valide et ne signaleront aucune erreur. Seul un examinateur humain qui lit les deux langues peut identifier la discordance.
• Inspection manuelle — portée des changements de langue : Même lorsque des attributs lang existent, un humain doit confirmer que l’attribut couvre toute l’étendue du passage en langue étrangère — pas seulement la première phrase, et sans déborder sur le contenu adjacent qui appartient à la langue principale. Les outils automatisés n’ont pas la compréhension de lecture nécessaire pour porter ce jugement.

Comment tester

1. Analyse de base automatisée : Exécutez axe DevTools (extension de navigateur ou intégration CI) ou Google Lighthouse sur la page. Recherchez toute violation de html-has-lang ou html-lang-valid — celles-ci indiquent que même la déclaration de langue au niveau de la page est manquante ou incorrecte, ce qui est un problème préalable à corriger avant de traiter 3.1.2. Notez qu’aucun de ces outils ne signalera les attributs lang en ligne manquants, de sorte que cette étape ne sert qu’à établir une base.
2. Audit visuel du contenu : Lisez l’intégralité du contenu de la page et identifiez chaque passage, expression ou bloc qui est visiblement rédigé dans une langue autre que la langue déclarée de la page. Tenez une liste de ces éléments, en notant leur emplacement dans le DOM. Vérifiez pour chaque élément (ou son ancêtre le plus proche) la présence d’un attribut lang dans l’inspecteur DOM du navigateur (Outils de développement du navigateur → panneau Éléments). Vérifiez que la valeur est une balise BCP 47 valide correspondant à la langue réelle du contenu.
3. Test avec lecteur d’écran — NVDA + Firefox (Windows) : Ouvrez la page avec NVDA actif en utilisant Firefox. Parcourez le contenu avec les touches fléchées, en vous concentrant sur les passages en langue étrangère que vous avez identifiés. Écoutez attentivement : NVDA doit changer automatiquement de prononciation lorsqu’il rencontre un attribut lang correctement balisé. Si le texte étranger est lu avec les règles de prononciation de la langue par défaut sans aucun changement de voix perceptible, il est probable que l’attribut lang soit manquant ou incorrect.
4. Test avec lecteur d’écran — JAWS + Chrome (Windows) : Avec JAWS en cours d’exécution dans Chrome, utilisez le curseur virtuel pour lire la page. Le comportement de JAWS reflète celui de NVDA — il bascule les moteurs TTS en fonction des valeurs lang. Activez le mode de parole détaillé pour entendre les annonces de langue. Notez tout passage où la prononciation semble incorrecte pour la langue visible.
5. Test avec lecteur d’écran — VoiceOver + Safari (macOS/iOS) : Activez VoiceOver et parcourez la page avec VO+Flèche droite. Pour les tests mobiles sur iOS, faites glisser le doigt sur le contenu. VoiceOver dans Safari respecte également les attributs lang et change de voix en conséquence. Si votre appareil dispose de packs de voix installés pour les langues étrangères attendues, vous entendrez un changement de voix distinct sur les éléments correctement balisés.
6. Validation des balises BCP 47 : Pour toutes les valeurs lang que vous trouvez, validez-les par rapport au registre IANA Language Subtag ou utilisez un validateur BCP 47 en ligne. Les erreurs courantes incluent l’utilisation de lang='en-us' (le code de région en minuscules est techniquement valide mais peu conventionnel) ou de codes invalides comme lang='english'.

Comment corriger

Expression étrangère en ligne dans un paragraphe en turc — Incorrect

<p>
  Bu ürün uluslararası standartlara uygundur ve
  <em>state of the art</em> teknoloji kullanmaktadır.
</p>

Expression étrangère en ligne dans un paragraphe en turc — Correct

<p>
  Bu ürün uluslararası standartlara uygundur ve
  <!-- lang='en' tells screen readers to switch to an English TTS engine -->
  <em lang='en'>state of the art</em> teknoloji kullanmaktadır.
</p>

Bloc de citation multisentences dans une langue étrangère — Incorrect

<blockquote>
  <p>La liberté commence où l'ignorance finit.</p>
  <p>— Victor Hugo</p>
</blockquote>

Bloc de citation multisentences dans une langue étrangère — Correct

<!-- lang='fr' applied to the blockquote covers all descendant content -->
<blockquote lang='fr'>
  <p>La liberté commence où l'ignorance finit.</p>
  <p>— Victor Hugo</p>
</blockquote>

Menu de navigation bilingue — Incorrect

<nav>
  <ul>
    <li><a href='/tr/anasayfa'>Anasayfa</a></li>
    <li><a href='/en/home'>Home</a></li>
    <li><a href='/de/startseite'>Startseite</a></li>
  </ul>
</nav>

Menu de navigation bilingue — Correct

<nav>
  <ul>
    <!-- Primary language (Turkish) needs no extra attribute if html lang='tr' -->
    <li><a href='/tr/anasayfa'>Anasayfa</a></li>
    <!-- English and German links receive their own lang attributes -->
    <li><a href='/en/home' lang='en'>Home</a></li>
    <li><a href='/de/startseite' lang='de'>Startseite</a></li>
  </ul>
</nav>

Tableau avec cellules de données multilingues — Incorrect

<table>
  <tr>
    <th>Ülke</th>
    <th>Slogan</th>
  </tr>
  <tr>
    <td>Fransa</td>
    <td>Liberté, Égalité, Fraternité</td>
  </tr>
  <tr>
    <td>Almanya</td>
    <td>Einigkeit und Recht und Freiheit</td>
  </tr>
</table>

Tableau avec cellules de données multilingues — Correct

<table>
  <tr>
    <th>Ülke</th>
    <th>Slogan</th>
  </tr>
  <!-- lang applied to individual td elements containing foreign text -->
  <tr>
    <td>Fransa</td>
    <td lang='fr'>Liberté, Égalité, Fraternité</td>
  </tr>
  <tr>
    <td>Almanya</td>
    <td lang='de'>Einigkeit und Recht und Freiheit</td>
  </tr>
</table>

Erreurs courantes

• Omission des attributs lang sur de courtes expressions en ligne : Les développeurs balisent souvent de grandes sections en langue étrangère mais négligent de courtes expressions comme un slogan marketing anglais de deux mots intégré dans une phrase par ailleurs en turc. Même les termes étrangers d’un seul mot qui ne sont pas des noms propres exemptés ou du vocabulaire technique nécessitent un balisage.
• Utilisation d’une balise BCP 47 incorrecte : Écrire lang='english', lang='turkish' ou lang='français' au lieu des codes ISO corrects (lang='en', lang='tr', lang='fr') rend l’attribut invalide et les lecteurs d’écran peuvent l’ignorer complètement.
• Se fier au CSS ou au style visuel pour suggérer un changement de langue : Changer la police, la couleur ou mettre en italique le texte étranger signale la différence de langue aux utilisateurs voyants mais ne fournit aucune information programmatique aux technologies d’assistance. L’attribut lang est le seul mécanisme qui fonctionne pour les lecteurs d’écran.
• Supposer que les utilisateurs de lecteurs d’écran « s’en sortiront » grâce au contexte : Attendre d’un utilisateur aveugle qu’il déduise qu’un passage au son brouillé est en réalité du français parce que le texte turc environnant faisait référence à la France est une attente déraisonnable qui transfère la charge de la compréhension à l’utilisateur.
• Ne baliser que le premier élément d’un bloc étranger multi-éléments : Si trois éléments <p> consécutifs contiennent un passage en français, placer lang='fr' uniquement sur le premier paragraphe laisse les deux paragraphes restants non balisés. L’approche correcte consiste soit à envelopper les trois dans un élément parent avec lang='fr', soit à ajouter l’attribut à chaque paragraphe individuellement.
• Confondre noms propres et expressions complètes en langue étrangère : L’exception des WCAG pour les noms propres couvre des noms comme « Paris » ou « Volkswagen » — pas des phrases entières ou des textes marketing rédigés en français ou en allemand. Les développeurs appliquent parfois mal cette exception pour justifier l’omission du balisage lang sur un contenu substantiel en langue étrangère.
• Contenu injecté dynamiquement sans attributs de langue : Lorsque du contenu en langue étrangère est chargé via JavaScript (par exemple, un bloc de FAQ géré par un CMS ou une description de produit traduite récupérée depuis une API), les développeurs oublient souvent d’inclure l’attribut lang dans le balisage injecté. Les chaînes de rendu côté serveur ou côté client doivent transmettre les métadonnées de langue en même temps que le contenu textuel.
• Utilisation de xml:lang dans des documents HTML5 sans lang : Dans les contextes XHTML, xml:lang était l’attribut approprié. En HTML5, lang est l’attribut correct. Utiliser uniquement xml:lang dans un document HTML5 peut fonctionner dans certains navigateurs mais n’est pas universellement pris en charge par toutes les technologies d’assistance.
• Placer lang sur un conteneur trop large qui inclut également du contenu dans la langue principale : Envelopper une section qui contient à la fois du texte turc et français entièrement dans lang='fr' entraînera une mauvaise prononciation des parties en turc. La portée de l’attribut doit correspondre précisément à la frontière linguistique.
• Ne pas tester avec de vrais lecteurs d’écran après avoir appliqué des correctifs : Les développeurs ajoutent fréquemment des attributs lang et considèrent la correction comme terminée sans vérifier le résultat TTS réel. Tester avec NVDA, JAWS ou VoiceOver est le seul moyen de confirmer que l’amélioration de la prononciation est perceptible pour les utilisateurs finaux.

Lien avec la réglementation d’accessibilité de la Turquie

La Circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit un cadre contraignant pour l’accessibilité numérique dans un large éventail d’entités des secteurs public et privé. La circulaire intègre formellement WCAG 2.2 comme norme technique, la conformité de niveau AA constituant l’exigence de base pour la conformité légale.

WCAG 3.1.2 — Langue des parties est un critère de niveau AA, ce qui le place clairement dans l’objectif de conformité obligatoire défini par la circulaire. Les entités qui exploitent des sites Web multilingues — ce qui est courant en Turquie compte tenu de la position du pays comme carrefour du commerce européen, moyen-oriental et d’Asie centrale — ont une obligation accrue de mettre correctement en œuvre ce critère. Une banque turque qui publie des conditions de devises étrangères en anglais, un opérateur télécom qui inclut des clauses d’accord d’itinérance en allemand, ou le site Web d’un hôpital qui reproduit des formulaires de consentement des patients en arabe doivent tous s’assurer que chaque passage en langue étrangère est balisé de manière programmatique.

Les types d’entités couverts par la circulaire incluent les institutions et agences publiques, les plateformes de commerce électronique, les banques et institutions financières, les hôpitaux et prestataires de soins de santé, les entreprises de télécommunications comptant 200,000 abonnés ou plus, les agences de voyage, les entreprises de transport privé et les écoles privées autorisées par le ministère de l’Éducation nationale (MoNE). Pour toutes ces entités, le non-respect de la conformité de niveau AA — y compris 3.1.2 — peut entraîner des sanctions administratives et l’inéligibilité au Logo d’accessibilité (Erişilebilirlik Logosu) délivré par le ministère de la Famille et des Services sociaux.

L’Erişilebilirlik Logosu est de plus en plus reconnu comme un signal de confiance sur le marché turc, en particulier dans le commerce électronique et les services financiers. L’obtention et le maintien du logo exigent une conformité démontrée à tous les critères de niveau AA, et Langue des parties est particulièrement pertinent pour les entités turques qui servent des clients internationaux ou publient des documents juridiquement contraignants dans plusieurs langues. Étant donné que la loi turque exige que certaines informations (telles que les avis sur les droits des consommateurs et les conditions des produits financiers) soient compréhensibles pour les utilisateurs handicapés, le balisage linguistique n’est pas simplement une bonne pratique technique — il fait partie de l’obligation de communication accessible intégrée dans le mandat plus large de la circulaire.

Les organisations qui recherchent le logo sont invitées à mener des audits structurés de contenu pour identifier tous les passages en langue étrangère sur l’ensemble de leurs propriétés numériques, à mettre en œuvre un processus de développement qui impose l’application de l’attribut lang au niveau de la gestion de contenu, et à inclure Langue des parties dans leurs protocoles réguliers de test d’accessibilité, parallèlement aux cycles d’examen automatisés et manuels.