vendredi 25 septembre 2026

À propos

Contact

Accessibilité

Auditer l’accessibilité d’un site multilingue et de son sélecteur de langue

Un cabinet d'avocats présent dans quatre pays nous a demandé un audit d'accessibilité de son site WordPress traduit avec WPML. Le sélecteur de langue à lui seul cachait trois anomalies distinctes.

Par Clément Hadrot • 19 octobre 2022 • 5 min de lecture • Aucun commentaire
Auditer l'accessibilité d'un site multilingue et de son sélecteur de langue

Un cabinet d’avocats d’affaires, présent en France, en Belgique, en Espagne et au Royaume-Uni, nous a confié l’audit d’accessibilité de son site institutionnel WordPress, traduit en quatre langues avec l’extension WPML. La demande initiale portait sur l’ensemble du site, mais c’est le sélecteur de langue, présent sur chaque page, qui a concentré une part disproportionnée des anomalies relevées.

Ce billet raconte comment nous avons audité ce composant en apparence anodin, et pourquoi un sélecteur de langue mal construit peut, à lui seul, rendre tout un site difficile à utiliser pour une personne malvoyante.

Premier constat : des drapeaux sans texte

Le sélecteur affichait quatre petits drapeaux dans l’en-tête du site, sans aucun texte visible ni texte alternatif. Un lecteur d’écran annonçait simplement « image, image, image, image », sans distinguer laquelle correspondait à quelle langue. Le drapeau britannique posait en plus un problème de sens : il représente un pays, pas une langue, ce qui prête à confusion pour l’anglais parlé également en dehors du Royaume-Uni.

Deuxième constat : l’attribut lang ne changeait jamais

En inspectant le code source des quatre versions linguistiques, nous avons remarqué que l’attribut lang de la balise <html> restait figé sur fr-FR quelle que soit la langue réellement affichée. WPML gère normalement cet attribut automatiquement, mais un script de personnalisation ajouté par un précédent prestataire l’écrasait après le chargement de la page.

L'essentiel à retenir : L'attribut lang doit changer avec le contenu affiché ; Un drapeau seul ne constitue jamais un nom accessible ; Chaque langue doit être annoncée dans sa propre langue
<html lang="fr-FR">
  <!-- contenu de la page en espagnol -->
</html>

Cette anomalie est particulièrement grave, car un lecteur d’écran s’appuie sur cet attribut pour choisir la voix et la prononciation correctes. Un texte espagnol lu avec un moteur de synthèse vocale réglé sur le français devient rapidement incompréhensible, en particulier sur les noms propres et les termes juridiques spécifiques à chaque pays.

Troisième constat : un menu de langue non identifié comme tel

Le conteneur du sélecteur de langue n’utilisait ni <nav>, ni aucun attribut aria-label permettant de le repérer rapidement parmi les raccourcis de navigation d’un lecteur d’écran. Un utilisateur pressé, habitué à naviguer par landmarks pour aller directement au sélecteur de langue en arrivant sur une page qu’il ne comprend pas, ne pouvait pas le localiser sans parcourir l’intégralité du menu principal.

La correction mise en place

Nous avons reconstruit le composant en trois temps. D’abord, chaque drapeau a reçu un texte visible accompagnant l’icône, avec le nom de la langue écrit dans sa propre langue plutôt que traduit : « Français », « English », « Español », « Nederlands » pour la version belge. Ensuite, le script qui écrasait l’attribut lang a été supprimé, laissant WPML gérer correctement cet attribut selon la langue active. Enfin, le conteneur du sélecteur a reçu <nav aria-label="Choix de la langue">.

<nav aria-label="Choix de la langue">
  <ul>
    <li><a href="/fr/" lang="fr" hreflang="fr">Français</a></li>
    <li><a href="/en/" lang="en" hreflang="en">English</a></li>
    <li><a href="/es/" lang="es" hreflang="es">Español</a></li>
    <li><a href="/nl/" lang="nl" hreflang="nl">Nederlands</a></li>
  </ul>
</nav>

L’attribut lang posé directement sur chaque lien du sélecteur permet à un lecteur d’écran de prononcer correctement le nom de la langue cible, même lorsque la langue actuellement affichée diffère.

Points de vigilance supplémentaires relevés pendant l’audit

  • Certains passages en langue étrangère à l’intérieur d’une page, comme une citation en latin dans les pages juridiques, n’étaient pas balisés avec un lang local
  • Le focus clavier, après changement de langue, restait positionné en haut de la nouvelle page, ce qui était correct et à conserver
  • Les URL générées par WPML respectaient une structure cohérente d’une langue à l’autre, ce qui facilitait la maintenance du composant

Un sélecteur de langue est souvent le premier composant rencontré par un visiteur qui ne comprend pas encore la langue par défaut du site. C’est précisément le pire endroit pour accumuler des obstacles d’accessibilité.

Notre verdict

Ce composant, que le client considérait comme un détail cosmétique, concentrait à lui seul trois anomalies distinctes, dont une, l’attribut lang figé, affectait en réalité l’intégralité des quatre versions linguistiques du site. Nous recommandons systématiquement d’auditer en priorité les composants transverses présents sur chaque page, comme les sélecteurs de langue, avant de s’attarder sur le contenu spécifique de chaque gabarit, car leur impact se multiplie par le nombre de pages concernées.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi