« Les changements de langue sont-ils indiqués dans le code de chaque page ? » Cette question, formulée presque mot pour mot dans le référentiel RGAA (critère 8.7 dans sa version 4), est souvent la première à faire tomber un site de collectivité lors d’un audit d’accessibilité commandé avant mise en ligne.
Contrairement à un site privé, une collectivité territoriale ou un établissement public a une obligation légale de publier une déclaration de conformité RGAA, avec un plan d’action pour les points non conformes. Le sélecteur de langue, souvent traité comme un simple élément de confort par les équipes de développement, se révèle être l’un des points les plus fréquemment mal implémentés.
Ce que le RGAA vérifie précisément sur la langue
Le référentiel ne se contente pas de vérifier qu’un sélecteur existe. Il porte sur trois niveaux distincts, souvent confondus par les équipes non spécialisées :
- La langue par défaut du document : l’attribut
langsur la balise<html>doit correspondre à la langue principale du contenu affiché - Les changements de langue dans le contenu : tout passage rédigé dans une langue différente de la langue principale de la page doit porter son propre attribut
lang - L’accessibilité du mécanisme de changement de langue lui-même : le sélecteur doit être utilisable au clavier, annoncé correctement par un lecteur d’écran, et ne jamais reposer uniquement sur une couleur ou un drapeau sans texte
La checklist à valider avant chaque livraison
- L’attribut
langde la balise<html>change bien selon la langue affichée (lang="fr",lang="de"), et n’est jamais figé sur une seule valeur quel que soit le contenu - Chaque lien du sélecteur de langue porte un texte visible, jamais un drapeau seul sans alternative textuelle
- L’attribut
hreflangest posé sur les liens du sélecteur, en plus de l’attributlang - Le sélecteur est accessible par tabulation, avec un focus visible qui respecte un contraste suffisant
- Le nom de la langue est annoncé dans la langue elle-même (« Deutsch », pas « Allemand », pour qu’un lecteur d’écran prononce correctement)
- Aucune redirection automatique forcée selon la langue du navigateur : l’usager reste libre de choisir, conformément au critère sur le contrôle laissé à l’utilisateur
- Les citations ou extraits ponctuels rédigés dans une autre langue que la langue principale portent un
<span lang="...">dédié - Le formulaire de contact et les messages d’erreur associés existent bien dans chaque langue proposée, pas seulement les pages de contenu statique
Le piège du drapeau sans texte
Un sélecteur composé uniquement de petites icônes de drapeaux, sans libellé, échoue systématiquement à ce critère lors d’un audit RGAA, pour deux raisons distinctes : un drapeau représente un pays, pas une langue (l’allemand n’est pas parlé que par l’Allemagne), et un lecteur d’écran ne peut pas interpréter une image sans texte alternatif pertinent. La correction la plus simple consiste à toujours accompagner le drapeau d’un libellé textuel visible, ou à l’abandonner complètement au profit du nom de la langue.
Le cas du menu déroulant natif contre le menu personnalisé
Un sélecteur de langue construit avec l’élément HTML natif <select> est nativement accessible au clavier et bien annoncé par les lecteurs d’écran, sans développement supplémentaire. Un menu déroulant personnalisé en JavaScript, plus fréquent visuellement dans les maquettes, demande un travail d’accessibilité bien plus lourd (gestion du focus, des touches flèches, de l’échappement) qu’une équipe pressée par un délai de livraison a tendance à bâcler.
Ce qu’une déclaration de conformité inexacte engage réellement
Publier une déclaration RGAA « totalement conforme » sur un site dont le sélecteur de langue échoue à trois critères n’est pas juste une erreur de forme : c’est un engagement écrit et daté, consultable par n’importe quel usager, qui peut être contesté.
Le plan d’action associé à la déclaration de conformité doit lister précisément les non-conformités constatées, avec un calendrier de correction. Mieux vaut une déclaration honnête avec des points « non conforme » assumés et un plan de correction crédible, qu’une déclaration optimiste qui ne résiste pas au premier audit contradictoire.
En résumé
Le sélecteur de langue d’un site public n’est pas un détail cosmétique : c’est l’un des points les plus fréquemment contrôlés lors d’un audit RGAA, et l’un des plus faciles à corriger en amont si la checklist est suivie dès la conception. Prévoir ce contrôle avant la livraison évite une déclaration de conformité à réviser dans l’urgence après coup.
