Accessible et activable par le clavier

Un composant est « accessible au clavier » quand on peut le sélectionner avec Tab, et « activable » quand on peut déclencher son action avec Entrée ou Espace. Les éléments HTML natifs comme <a>, <button> et <input> le sont par défaut. Un <div> avec un onclick, non.

Un <span> avec un onclick fonctionne à la souris. Au clavier, rien ne se passe. Pas de focus, pas d'activation, pas de retour. L'utilisateur qui navigue sans souris est bloqué sur place.

#Deux notions distinctes

Le RGAA distingue deux choses :

• Accessible : l'utilisateur peut atteindre le composant avec la touche Tab (prise de focus).
• Activable : l'utilisateur peut déclencher l'action avec Entrée ou Espace.

Les éléments HTML natifs (<a>, <button>, <input>, <select>) remplissent ces deux conditions sans aucun effort. Le critère WCAG 2.1.1 (niveau A) exige que toute fonctionnalité soit utilisable via le clavier, sauf si elle dépend du tracé d'un mouvement (comme le dessin à main levée).

#L'erreur classique : le faux bouton

Voici un composant inaccessible au clavier :

<!-- ❌ Inaccessible au clavier -->
<span onclick="valider()">Valider</span>

La souris fonctionne. Le clavier, non. L'élément ne reçoit pas le focus et ne réagit pas à Entrée.

La correction la plus simple :

<!-- ✅ Nativement accessible et activable -->
<button type="button" onclick="valider()">Valider</button>

Si vous devez utiliser un <div> (cas rare), il faut reconstituer tout le comportement :

<!-- ⚠️ Possible, mais fragile -->
<div role="button" tabindex="0" onclick="valider()" onkeydown="if(event.key==='Enter'||event.key===' ')valider()">
  Valider
</div>

Trois attributs et un gestionnaire d'événement pour reproduire ce qu'un <button> fait en une ligne.

#Focus visible et piège au clavier

Rendre un élément focusable ne suffit pas. Deux autres exigences complètent le tableau.

Le focus doit rester visible. Supprimer outline: none en CSS sans fournir d'alternative revient à retirer les repères visuels d'un utilisateur qui navigue au clavier. Le critère WCAG 2.4.7 l'exige au niveau AA.

Le focus ne doit jamais être piégé. Si un utilisateur entre dans une modale ou un menu et ne peut pas en sortir avec Tab ou Échap, c'est une violation du critère WCAG 2.1.2. Chrome Lighthouse teste ce point automatiquement.

#En résumé

Utilisez les éléments HTML natifs. Ils sont déjà accessibles et activables au clavier. Si vous construisez un composant personnalisé, ajoutez tabindex="0", le role ARIA approprié et un gestionnaire keydown. Testez avec Tab, Entrée, Espace et Échap, sans toucher la souris.