Composant d'interface

Un composant d'interface est un élément de page avec lequel l'utilisateur interagit : bouton, lien, champ de saisie, menu ou système d'onglets. Quand il s'agit d'un élément HTML natif, le navigateur gère l'accessibilité. Quand il est construit en JavaScript, c'est au développeur de reproduire ce comportement avec WAI-ARIA et la gestion clavier.

Un <button> HTML est accessible dès sa création : les lecteurs d'écran l'annoncent comme un bouton, il reçoit le focus, il réagit aux touches Entrée et Espace. Un <div> avec un onclick ne fait rien de tout cela. La différence tient en un mot : sémantique.

#Natif vs custom : ce que vous perdez

Les éléments HTML interactifs (<button>, <a>, <input>, <select>) embarquent un comportement accessible intégré. Le navigateur sait quel rôle ARIA leur attribuer, comment les rendre focusables, et quelles touches clavier les déclenchent.

Quand vous construisez un composant sur mesure en JavaScript, vous partez de zéro. Le navigateur ne devinera pas que votre <div> est un bouton. Un <div> transformé en bouton doit recevoir :

<!-- Le minimum pour un bouton custom -->
<div role="button" tabindex="0"
     onclick="action()"
     onkeydown="if(event.key==='Enter'||event.key===' ')action()">
  Valider
</div>
 
<!-- Ou simplement -->
<button onclick="action()">Valider</button>

Le glossaire du RGAA résume le concept : un composant d'interface est un élément avec lequel l'utilisateur peut interagir. Lien, bouton, champ de saisie, mais aussi menu, fenêtre de dialogue, système d'onglets.

#Quand le composant dépasse le simple bouton

Un bouton custom est gérable. Un système d'onglets, un menu déroulant, une modale, c'est une autre histoire.

Pour un système d'onglets, le WAI-ARIA Authoring Practices Guide exige les rôles tablist, tab et tabpanel, les attributs aria-selected et aria-controls, et la navigation par flèches entre les onglets. Oubliez un seul de ces éléments et le composant devient opaque pour un lecteur d'écran.

<div role="tablist">
  <button role="tab" aria-selected="true"
          aria-controls="panel-1">Onglet 1</button>
  <button role="tab" aria-selected="false"
          aria-controls="panel-2" tabindex="-1">Onglet 2</button>
</div>
<div role="tabpanel" id="panel-1">Contenu du premier onglet.</div>

Le principe est le même pour les menus (role="menu"), les modales (role="dialog") ou les accordéons. Chaque motif a ses rôles, ses états et ses raccourcis clavier documentés. AcceDe Web publie ces motifs en français avec des implémentations de référence.

#L'erreur la plus coûteuse

Ajouter role="button" et oublier le clavier. Le rôle ARIA ne donne que l'étiquette, il ne fournit aucun comportement. Un lecteur d'écran annoncera « bouton », l'utilisateur appuiera sur Entrée, et rien ne se passera. La documentation MDN le dit clairement : role="button" sans gestion clavier est pire que pas de rôle du tout.

#En résumé

Utilisez les éléments HTML natifs chaque fois que possible. Si vous construisez un composant custom, suivez les motifs de conception du W3C APG : rôle, états, propriétés et interactions clavier. Testez au clavier et avec un lecteur d'écran avant de déclarer le composant terminé. Un rôle ARIA sans le comportement associé est une promesse non tenue.