Comparer deux défauts d’accessibilité qui n’ont rien en commun, seulement parce qu’ils touchent au même composant, mène souvent à corriger le mauvais problème. Un audit relève un sélecteur de langue peu accessible sur un site multilingue ; le développeur, en cherchant une explication rapide, tombe sur une mention de role="presentation" dans la documentation ARIA, et croit avoir trouvé la cause. En réalité, ce rôle particulier n’a jamais été posé sur ce composant, et ne concerne pas ce type de problème.
Cette confusion vient d’une lecture trop rapide de la documentation d’accessibilité, où plusieurs notions proches, mais distinctes, se croisent autour d’un même composant sans jamais désigner le même défaut.
Ce que fait réellement role= »presentation »
L’attribut role="presentation", comme son synonyme role="none", indique explicitement à une technologie d’assistance qu’un élément HTML ne porte aucune signification sémantique propre, malgré la balise utilisée. Un tableau utilisé uniquement pour une mise en page visuelle, sans rapport tabulaire réel entre les données, en est l’exemple classique : role="presentation" masque alors sa nature de tableau aux lecteurs d’écran, qui l’annonceraient sinon comme un tableau de données sans intérêt réel pour l’utilisateur.
Ce rôle retire de la sémantique, il n’en ajoute jamais. Poser role="presentation" sur un menu de navigation ou un sélecteur de langue reviendrait à masquer sa nature réelle aux technologies d’assistance, ce qui serait précisément l’inverse de ce que recherche une équipe soucieuse d’accessibilité sur ce composant.
Le vrai problème d’un sélecteur de langue mal balisé
Le défaut réellement rencontré sur un sélecteur de langue typique est bien différent : il s’agit le plus souvent d’un élément <div> cliquable, stylé pour ressembler à un menu déroulant, mais dépourvu de toute sémantique native de bouton ou de liste. Un tel composant n’a besoin d’aucun rôle de présentation à corriger : il lui manque au contraire une sémantique interactive correcte, qui n’a jamais existé.
<!-- Version problématique -->
<div class="selecteur-langue" onclick="ouvrirMenu()">
Français
</div>
La correction de ce défaut passe par une balise nativement interactive, ou par un ajout de rôle ARIA approprié pour signaler un menu, jamais par la suppression d’une sémantique déjà absente :
<!-- Version corrigée -->
<button
type="button"
aria-haspopup="true"
aria-expanded="false"
>
Français
</button>
<ul role="menu" hidden>
<li role="menuitem"><a href="/en/">English</a></li>
<li role="menuitem"><a href="/es/">Español</a></li>
</ul>
Deux familles de défauts à ne pas mélanger
| Situation | role= »presentation » | Sélecteur de langue non sémantique |
|---|---|---|
| Ce qui manque ou ce qui est en trop | Sémantique retirée volontairement | Sémantique jamais construite |
| Élément typique concerné | Tableau de mise en page | Div stylée en bouton |
| Correction attendue | Rien à ajouter, usage volontaire | Ajouter balise ou rôle ARIA adapté |
Pourquoi cette confusion revient si souvent
Les deux sujets partagent un même vocabulaire technique, ARIA, rôle, sémantique, ce qui pousse un développeur pressé à chercher une explication commune. Un audit d’accessibilité mentionnant les deux défauts sur des pages voisines du même site, par exemple un tableau mal balisé sur une page produit et un sélecteur de langue défaillant dans l’en-tête, peut laisser croire à un problème unique alors qu’il s’agit de deux défauts indépendants, nécessitant des corrections totalement différentes.
- Toujours vérifier ce que fait réellement un rôle ARIA avant de l’invoquer comme explication.
- Un sélecteur de langue accessible repose sur une sémantique interactive correcte, pas sur l’absence d’un rôle de présentation.
- Traiter chaque ligne d’un rapport d’audit indépendamment des autres, sans supposer une cause commune.
Un repère simple avant toute correction : demandez-vous si le composant a une sémantique en trop à retirer, ou une sémantique manquante à construire. Ce sont deux chantiers différents, jamais le même correctif.
Notre verdict
Confondre ces deux défauts fait perdre du temps sans résoudre le vrai problème d’accessibilité rencontré par les utilisateurs de technologies d’assistance sur un sélecteur de langue. Prendre le temps de qualifier précisément chaque anomalie relevée dans un audit, avant de chercher une correction, évite d’appliquer un correctif qui ne changera rien au comportement réellement observé.
