« Directive (UE) 2019/882 du Parlement européen et du Conseil du 17 avril 2019 relative aux exigences en matière d’accessibilité applicables aux produits et services. » Ce texte, connu sous le nom d’European Accessibility Act (EAA), entre en application le 28 juin 2025 dans l’ensemble des États membres, avec des obligations directes pour de nombreux services numériques, notamment ceux liés au commerce électronique, aux services bancaires et à certains services de transport. Ce sujet ne traite pas du RGAA, le référentiel français déjà couvert par ailleurs, qui reste une obligation distincte, principalement pour le secteur public : l’EAA élargit la contrainte d’accessibilité à des acteurs privés qui n’y étaient pas soumis jusqu’ici.
Sur les sites multilingues concernés par ce champ d’application, un composant précis mérite une attention particulière avant l’échéance : le sélecteur de langue, souvent traité comme un simple élément de navigation secondaire, alors qu’il concentre plusieurs exigences d’accessibilité rarement toutes respectées en pratique.
Pourquoi le sélecteur de langue est un point d’attention spécifique
Un sélecteur de langue combine plusieurs défis d’accessibilité simultanés : il doit être navigable au clavier, correctement annoncé par un lecteur d’écran (y compris le fait qu’il s’agit d’un changement de langue, pas d’un lien de navigation classique), et surtout, l’attribut lang de la page doit changer effectivement après activation du sélecteur pour que la synthèse vocale bascule sur la bonne prononciation. Sur de nombreux sites audités, ce dernier point échoue silencieusement : le contenu change bien de langue visuellement, mais l’attribut lang de la balise <html> reste figé sur la langue précédente si le thème ne le met pas à jour correctement.
Ce que WordPress permet de vérifier dès maintenant
Sur un site utilisant Polylang, l’attribut de langue de la balise <html> est en principe géré automatiquement par la fonction language_attributes() appelée dans le fichier header.php du thème, qui reflète la langue courante définie par Polylang. Le point de vigilance porte sur les thèmes personnalisés plus anciens qui auraient codé en dur cet attribut, ou les configurations où un cache de page agressif servirait une version mise en cache de la balise <html> incohérente avec le contenu réellement affiché après un changement de langue via une requête asynchrone.
<!doctype html>
<html <?php language_attributes(); ?>>
<head>
<meta charset="<?php bloginfo( 'charset' ); ?>">
...
Un test simple, réalisable dès aujourd’hui sans attendre un audit formel, consiste à inspecter l’attribut lang de la balise <html> via les outils de développement du navigateur sur chaque langue du site, et à vérifier qu’il correspond bien au code de langue affiché, y compris pour des variantes régionales (fr-FR, fr-CA) si le site les distingue.
Le sélecteur lui-même : navigation clavier et annonce vocale
Au-delà de l’attribut lang, le sélecteur de langue doit être accessible au clavier (navigable via la touche tabulation, activable via la touche entrée ou espace, sans piège de focus qui empêcherait de sortir du menu déroulant), et correctement structuré sémantiquement, généralement via une liste de liens avec des attributs hreflang corrects sur chaque option, plutôt qu’un menu construit uniquement en JavaScript sans structure HTML sémantique sous-jacente.
| Point de contrôle | Ce qui est attendu |
|---|---|
Attribut lang de la balise html | Correspond exactement à la langue affichée après changement |
| Navigation clavier | Sélecteur atteignable et activable sans souris, sans piège de focus |
| Annonce lecteur d’écran | Le rôle et l’intitulé du sélecteur sont explicites, pas seulement visuels |
Attribut hreflang sur chaque option | Présent et cohérent avec la structure d’URL multilingue du site |
Ce qui reste incertain à ce stade
Au moment de la rédaction de cet article, les textes de transposition nationale de l’EAA ne sont pas encore tous stabilisés dans chaque État membre, et le périmètre exact des sites concernés (taille d’entreprise, nature de l’activité) continue de faire l’objet de précisions officielles. Ce qui ne change pas, en revanche, c’est que les exigences techniques d’accessibilité elles-mêmes s’appuient largement sur des référentiels déjà connus et stables, ce qui permet de commencer les corrections dès maintenant sans attendre la clarification complète du périmètre réglementaire.
- Vérifier dès maintenant que l’attribut
langchange réellement après activation du sélecteur - Tester la navigation clavier complète du sélecteur de langue, sans dépendre de la souris
- S’assurer que chaque option du sélecteur porte un attribut
hreflangcohérent - Suivre les précisions de transposition nationale sans attendre l’échéance pour commencer les corrections
Notre verdict
L’échéance de juin 2025 laisse encore plusieurs mois aux équipes concernées pour traiter un composant aussi central qu’un sélecteur de langue, mais l’expérience des audits d’accessibilité montre que ce composant est systématiquement sous-estimé, précisément parce qu’il paraît trivial. Vérifier dès maintenant l’attribut lang et la navigation clavier du sélecteur reste le geste le plus rentable avant que l’échéance ne transforme cette vérification en urgence.
