# TranslatePress contre Weglot : l’accessibilité du sélecteur de langue

> Comparatif de l'implémentation ARIA des sélecteurs de langue proposés par défaut par TranslatePress et Weglot, sans entrer dans la qualité de traduction.

- Auteur : WordPress Développement
- Publié le : 2024-09-16
- Mis à jour le : 2024-09-16
- Catégorie : Accessibilité
- URL : https://www.wpmoderne.fr/accessibilite/translatepress-weglot-selecteur-langue-aria/

## L’essentiel

- Les deux plugins proposent un menu déroulant personnalisé, pas un select natif
- L'un gère aria-expanded correctement par défaut, l'autre demande un ajustement
- Le focus au clavier diffère nettement entre les deux

`<div class="trp-language-switcher">` contre `<div class="weglot-container">` : deux marqueurs qui trahissent d'emblée un choix d'architecture identique chez ces deux plugins de traduction parmi les plus utilisés sur WordPress, celui d'un menu déroulant personnalisé plutôt qu'un élément `<select>` natif du navigateur.

Ce comparatif s'est construit sur un même thème de test, un thème de blocs par défaut, avec les deux plugins installés séparément et testés au clavier et au lecteur d'écran NVDA, en se concentrant exclusivement sur l'accessibilité du sélecteur de langue, sans juger la qualité des traductions produites par l'un ou par l'autre.

## Structure HTML du sélecteur TranslatePress

Le sélecteur de langue de TranslatePress, dans sa configuration par défaut, génère un bouton principal suivi d'une liste de langues disponibles, avec un attribut `aria-expanded` déjà présent sur le bouton d'ouverture.

```
<div class="trp-language-switcher">
  <div class="trp-current-language" aria-expanded="false" tabindex="0" role="button">
    Français
  </div>
  <ul class="trp-ls-shortcode-language">
    <li><a href="/en/">English</a></li>
  </ul>
</div>
```

Le bouton principal utilise `role="button"` sur une `<div>` plutôt qu'un élément `<button>` natif, ce qui a fonctionné correctement au test, mais impose une vigilance supplémentaire : ce rôle ne fonctionne que si `tabindex="0"` et les gestionnaires clavier associés sont bien tous présents, ce qui est le cas dans la version testée.

## Structure HTML du sélecteur Weglot

Weglot, dans sa configuration par défaut, produit un conteneur similaire dans son principe mais sans `aria-expanded` initial sur l'élément déclencheur, un attribut qui n'apparaît qu'après un ajustement manuel de la personnalisation CSS et JavaScript proposée par le plugin.

```
<div class="weglot-container">
  <div class="wg-current-lang" tabindex="0">
    FR
  </div>
  <div class="wg-drop wg-hide">
    <div class="wg-li" data-l="en">EN</div>
  </div>
</div>
```

Sans `aria-expanded`, un utilisateur de lecteur d'écran qui active le bouton principal n'est pas informé que celui-ci ouvre un menu, ni de son état une fois ouvert : il découvre la liste de langues seulement en continuant à naviguer, sans annonce préalable claire.

> L'essentiel à retenir : Les deux plugins proposent un menu déroulant personnalisé, pas un select natif ; L'un gère aria-expanded correctement par défaut, l'autre demande un ajustement ; Le focus au clavier diffère nettement entre les deux

## Comparaison de la navigation au clavier

| Critère | TranslatePress | Weglot |
| --- | --- | --- |
| Bouton atteignable en Tab | Oui | Oui |
| aria-expanded présent par défaut | Oui | Non |
| Fermeture à l'Échap | Oui | Non, par défaut |
| Retour du focus après sélection | Rechargement de page, focus perdu | Rechargement de page, focus perdu |

Sur ce dernier point commun, aucun des deux plugins ne gère un focus restauré après le changement de langue : les deux déclenchent un rechargement complet de la page vers l'URL traduite, ce qui replace naturellement le focus en haut de page, un comportement acceptable mais qui pourrait être amélioré par une annonce explicite du changement de langue effectué.

## Ce qui reste à la charge du développeur dans les deux cas

- Aucun des deux plugins ne définit d'attribut `lang` automatiquement correct sur l'élément `<html>` sans configuration additionnelle vérifiée au cas par cas selon la version installée.
- La personnalisation visuelle du sélecteur, fréquente pour l'intégrer à la charte graphique du thème, peut casser le comportement clavier si elle remplace la structure HTML par défaut sans reprendre les attributs ARIA associés.
- Un test manuel au clavier reste indispensable après chaque mise à jour majeure de l'un ou l'autre plugin, les deux ayant fait évoluer leur structure HTML par le passé.

### Le cas de Weglot corrigé manuellement

Pour combler l'absence d'`aria-expanded` par défaut, un correctif JavaScript simple a été ajouté au thème, écoutant l'ouverture et la fermeture du menu Weglot pour mettre à jour l'attribut manquant, sans toucher au code du plugin lui-même, ce qui préserve la compatibilité avec les futures mises à jour.

> Un plugin de traduction bien noté sur la qualité de sa traduction automatique n'a pas nécessairement soigné l'accessibilité de son propre sélecteur de langue : les deux critères s'évaluent indépendamment.

## Notre verdict

Sur ce point précis, TranslatePress propose un sélecteur de langue plus complet par défaut, avec `aria-expanded` et une fermeture à l'Échap déjà en place, tandis que Weglot nécessite un correctif manuel pour atteindre un niveau équivalent. Aucun des deux ne dispense d'un test clavier après intégration dans un thème personnalisé, la structure par défaut restant fragile face à une surcouche CSS mal maîtrisée.