Composants inaccessibles au clavier : « ça marche à la souris » ne suffit pas

Essayez de débrancher votre souris et de naviguer sur votre site uniquement avec Tab, Maj+Tab, Entrée et les flèches. Si vous ne parvenez pas à atteindre chaque élément interactif, ou si vous ne savez pas où vous vous trouvez dans la page, vous venez de découvrir un échec d'accessibilité au clavier - et de vivre le site tel que l'éprouvent par défaut toutes les personnes naviguant au clavier, utilisant un dispositif à contacteur, ou un lecteur d'écran, puisque ces outils passent par la même interface clavier plutôt que par un pointeur.

Les données du secteur situent l'inaccessibilité au clavier autour de 61 % des plaintes fondées sur l'ADA - le quatrième problème le plus cité, et l'un de ceux que les outils automatisés ne détectent que partiellement (le critère 2.1.1 n'est que partiellement automatisable : un analyseur peut signaler des motifs suspects comme un tabindex non nul, mais confirmer l'utilisabilité complète au clavier suppose de parcourir réellement la page).

Les erreurs les plus fréquentes

Une <div> ou un <span> mis en forme pour ressembler à un bouton, avec un simple gestionnaire onclick. Les clics souris le déclenchent ; la tabulation passe à côté, car une <div> ordinaire n'entre pas dans l'ordre de focus et ne possède aucune activation native par Entrée ou Espace.

<!-- Avant : invisible pour les personnes au clavier -->
<div class="button" onclick="submitForm()">Envoyer</div>

<!-- Après : un vrai bouton, focusable et activable par Entrée/Espace sans effort -->
<button type="submit">Envoyer</button>

Listes déroulantes, fenêtres modales et menus faits main qui ne réagissent qu'à mouseover/mouseout et n'implémentent jamais les événements clavier (Échap pour fermer, flèches pour parcourir les options, Entrée pour valider).

Un indicateur de focus visible supprimé. Même une page entièrement utilisable au clavier échoue en pratique si outline: none (ou équivalent) est appliqué globalement sans remplacement : on peut techniquement parcourir la page, mais sans jamais voir où l'on se trouve. Cela recoupe le critère 2.4.7 (Visibilité du focus).

Des valeurs positives de tabindex (tabindex="1", tabindex="2", etc.) censées contrôler manuellement l'ordre de tabulation : elles produisent presque toujours un ordre pire que l'ordre naturel du DOM qu'elles remplacent, et axe-core signale tout tabindex positif pour cette raison précise.

Comment le corriger

Privilégiez les véritables éléments interactifs natifs (<button>, <a href>, <input>, <select>) plutôt que de recréer leur comportement sur des éléments génériques : ils apportent gratuitement la prise en charge du clavier, la gestion du focus et la sémantique pour les lecteurs d'écran. C'est le même principe « HTML sémantique plutôt qu'ARIA » qui s'applique à la plupart des corrections d'accessibilité : ne reconstruisez pas ce que la plateforme fournit déjà correctement.

Si un composant sur mesure est inévitable, il lui faut l'ensemble des interactions clavier attendues pour son rôle (le guide des pratiques de rédaction WAI-ARIA documente le contrat clavier exact de chaque modèle courant : menus, onglets, dialogues, listes combinées), plus un style de focus visible et un tabindex="0" (jamais un nombre positif) pour l'intégrer à l'ordre naturel de tabulation.

Références officielles

• Deque University : tabindex