Compatible avec les technologies d'assistance

Un contenu web est compatible avec les technologies d'assistance quand le navigateur transmet correctement ses informations (nom, rôle, valeur, états) aux lecteurs d'écran, plages braille et autres outils d'assistance. Les éléments HTML natifs comme <button> ou <input> le sont automatiquement. Les éléments génériques comme <div> ne le sont pas, sauf ajout manuel d'attributs WAI-ARIA et de comportements clavier.

Votre bouton fonctionne à la souris. Il a la bonne couleur, la bonne taille, le bon curseur. Un utilisateur de lecteur d'écran arrive sur la page : ce bouton n'existe pas. Le lecteur d'écran ne le voit pas, ne l'annonce pas, et l'utilisateur ne peut pas l'activer. Le bouton n'est pas compatible avec les technologies d'assistance.

#Ce qui se passe entre le navigateur et le lecteur d'écran

Le navigateur construit un arbre d'accessibilité à partir du DOM. C'est une version simplifiée de la page où chaque élément interactif est décrit par quatre propriétés : son nom (le texte affiché ou l'attribut aria-label), son rôle (bouton, lien, case à cocher…), sa valeur et son état (coché, déplié, désactivé…). Cet arbre est transmis à l'API d'accessibilité du système d'exploitation, qui le rend lisible par les technologies d'assistance.

Un <button> HTML natif expose automatiquement son rôle et son état. Aucun attribut supplémentaire n'est nécessaire. Un <div> avec un onclick, lui, n'expose rien : pour l'arbre d'accessibilité, c'est du texte inerte.

<!-- Compatible : le navigateur sait que c'est un bouton -->
<button>Valider la commande</button>
 
<!-- Incompatible : le navigateur ne sait pas que c'est un bouton -->
<div onclick="submit()">Valider la commande</div>

#Le piège du role sans le comportement

Ajouter role="button" sur un <div> ne suffit pas. Le W3C le résume en une phrase : « Un rôle est une promesse. » En déclarant qu'un élément est un bouton, vous promettez qu'il réagit aux touches Entrée et Espace, qu'il est atteignable au clavier via tabulation, et que ses états sont mis à jour dynamiquement.

<!-- Promesse tenue : rôle + clavier + focus -->
<div role="button" tabindex="0"
     onkeydown="if(event.key==='Enter'||event.key===' ')submit()"
     onclick="submit()">
  Valider la commande
</div>
 
<!-- Promesse non tenue : le lecteur d'écran dit "bouton",
     mais l'utilisateur ne peut pas l'activer au clavier -->
<div role="button" onclick="submit()">
  Valider la commande
</div>

Cinq lignes de code pour recréer ce qu'un <button> fait nativement en une seule. Le critère 4.1.2 des WCAG (niveau A) exige que chaque composant d'interface expose son nom, son rôle et sa valeur via l'API d'accessibilité. Le RGAA reprend cette exigence dans son glossaire et dans ses critères de la thématique 7 (Scripts).

#En résumé

Utilisez les éléments HTML natifs. Ils sont compatibles avec les technologies d'assistance par défaut. Si vous devez utiliser un <div> ou un <span> interactif, ajoutez le rôle ARIA, le tabindex, la gestion clavier et la mise à jour des états. Un rôle sans comportement est pire que pas de rôle du tout.