Antipatterns ARIA : role=’button’ sur un div aggrave l’accessibilité

Sur un audit récent, j’ai croisé ce fragment dans le thème d’un client : un <div> avec role="button", un gestionnaire de clic en JavaScript, et rien d’autre. Visuellement, le composant ressemblait à un bouton d’ajout au panier. Pour un lecteur d’écran, il s’annonçait bien comme « bouton ». Mais au clavier, il était totalement inerte : ni focusable, ni activable. Le développeur avait ajouté juste assez d’ARIA pour rassurer un audit automatique, sans jamais tester au clavier.

C’est l’antipattern ARIA le plus fréquent, et l’un des plus trompeurs : il donne l’impression d’avoir corrigé le problème, alors qu’il l’a rendu pire pour une partie des utilisateurs. Un <div> sans rôle du tout est au moins honnête : un lecteur d’écran l’ignore, l’utilisateur sait qu’il n’y a rien à activer ici. Un <div role="button"> mal complété annonce une promesse qu’il ne tient pas.

Ce qu’on voit sur le terrain

<div class="btn-ajouter" role="button" onclick="ajouterAuPanier()">
  Ajouter au panier
</div>

Ce code est fréquent dans les intégrations issues de maquettes Figma copiées trop vite : le designer a dessiné un bouton, l’intégrateur a reproduit son style avec un <div> parce que c’était l’élément déjà présent dans la maquette exportée, puis un role="button" a été ajouté après un premier audit automatique qui signalait « rôle manquant ».

Pourquoi c’est un problème, précisément

Un vrai <button> apporte gratuitement quatre comportements que role="button" seul n’apporte jamais :

• Il est focusable au clavier via Tab, sans tabindex à ajouter.
• Il s’active avec Entrée et avec Espace.
• Il déclenche un style de focus visible par défaut du navigateur.
• Il est reconnu nativement par tous les lecteurs d’écran, sans dépendre de l’implémentation ARIA du navigateur en cours.

Le rôle ARIA, lui, ne modifie que la façon dont l’élément est annoncé à l’API d’accessibilité du système. Il ne fait ni du <div> un élément focusable, ni ne lui ajoute la moindre gestion de touche. La spécification WAI-ARIA le dit d’ailleurs explicitement dans sa règle numéro un : « No ARIA is better than Bad ARIA » — pas d’ARIA vaut mieux qu’un ARIA mal posé.

Le correctif minimal si l’on ne peut vraiment pas utiliser button

Il existe de rares cas où remplacer par un <button> natif est impossible techniquement (un framework tiers qui impose sa structure, par exemple). Dans ce cas, trois ajouts sont indispensables, pas un de moins :

<div class="btn-ajouter" role="button" tabindex="0"
     onclick="ajouterAuPanier()"
     onkeydown="if(event.key==='Enter'||event.key===' '){event.preventDefault();ajouterAuPanier();}">
  Ajouter au panier
</div>

tabindex="0" rend l’élément focusable, et le gestionnaire de touche reproduit l’activation par Entrée et par Espace. Il faut aussi restaurer visuellement un style de focus, car un <div> ne reçoit par défaut aucun contour au focus dans certains navigateurs selon la feuille de style appliquée.

Le vrai correctif : revenir à button

Dans l’immense majorité des cas, remplacer le <div> par un <button type="button"> demande moins de code que de rattraper manuellement son comportement :

<button type="button" class="btn-ajouter" onclick="ajouterAuPanier()">
  Ajouter au panier
</button>

Le style visuel se conserve à l’identique en CSS ; seul l’élément change. Le gain n’est pas cosmétique : il porte sur le clavier, le focus, et la cohérence entre navigateurs et lecteurs d’écran, sans une ligne de JavaScript supplémentaire.

Comment repérer ces div-boutons dans un thème existant

Une recherche grep -rn "role=\"button\"" wp-content/themes/ permet de lister rapidement chaque occurrence. Pour chacune, la question à se poser est toujours la même : cet élément gère-t-il Entrée, Espace et le focus clavier ? Si la réponse est non, ou si elle n’est même pas certaine, direction <button>.

Quoi faire à l’avenir

La règle qui évite ce piège tient en une phrase : ARIA décrit un comportement, il ne le crée pas. Avant d’ajouter un rôle sur un élément générique, la première question est toujours de vérifier s’il existe un élément HTML natif qui porte déjà ce comportement — bouton, lien, case à cocher, champ de formulaire — et de ne recourir à role qu’en dernier ressort, en s’engageant alors à reproduire fidèlement tout ce que l’élément natif offrait gratuitement.