Accessibilité au clavier

L’accessibilité au clavier signifie que chaque action qu’un utilisateur peut effectuer sur une page peut être réalisée en utilisant uniquement le clavier. Il s’agit de l’exigence d’accessibilité la plus fondamentale : sans elle, aucune autre technologie d’assistance ne fonctionne.

L’interface clavier est l’interface universelle

Lecteurs d’écran, dispositifs de commutation, commande vocale, suivi du regard — toutes les technologies d’assistance utilisées sur le web passent en fin de compte par la couche clavier. Un utilisateur sans aucun handicap moteur ne pressera peut-être jamais Tab, mais le même site doit être entièrement opérable de cette façon pour que les personnes handicapées puissent l’utiliser.

C’est pourquoi 2.1.1 Clavier est un critère de niveau A : ne pas le respecter ne rend pas le site plus difficile, il le rend inutilisable pour des populations entières d’utilisateurs.

Ce que « opérable au clavier » requiert concrètement

• Tab et Maj+Tab déplacent le focus en avant et en arrière parmi les éléments interactifs.
• Entrée active les liens et la plupart des boutons.
• Espace active les boutons et bascule les cases à cocher et boutons radio.
• Les touches fléchées naviguent dans les widgets composites (onglets, menus, groupes de boutons radio, zones de liste, curseurs).
• Échap ferme les fenêtres modales, les popovers et les menus déroulants.
• Page précédente/suivante, Début/Fin naviguent dans les contenus longs selon la convention de la plateforme.

Un widget qui n’implémente pas le contrat clavier attendu par les utilisateurs de lecteurs d’écran pour son rôle — par exemple un ARIA combobox qui répond aux clics mais pas aux touches fléchées — est techniquement focusable mais fonctionnellement inutilisable.

L’audit manuel le plus rapide

Parcourez une page à partir du tout début (focus sur la barre d’adresse, puis Tab) jusqu’au pied de page. L’ordre de focus doit correspondre à l’ordre visuel. Chaque élément cliquable doit recevoir le focus exactement une fois. Appuyer sur Entrée ou Espace sur un élément focalisé doit produire le même résultat que le cliquer. Appuyer sur Échap dans une fenêtre modale doit la fermer. Si un élément est inaccessible, si des éléments sont atteints dans le mauvais ordre, ou si le focus reste piégé, ce sont des anomalies à corriger.

Cinq minutes de navigation disciplinée à la touche Tab révèlent davantage de problèmes d’accessibilité que quinze minutes d’analyse avec axe-core.

Patterns d’échec courants

• <div onclick> pour les cartes cliquables. Non focusable, non activable au clavier, complètement invisible pour les lecteurs d’écran en tant qu’élément interactif. Il faut utiliser <button> (pour les actions) ou <a href> (pour la navigation).
• Menus déroulants personnalisés qui ne s’ouvrent pas avec Entrée/Espace. Construits avec des gestionnaires de clic uniquement ; les utilisateurs au clavier peuvent mettre le focus sur le déclencheur mais pas ouvrir la liste.
• Fenêtres modales qui ne piègent pas le focus. Tab déplace le focus hors de la modale vers la page (visuellement masquée) derrière. Les utilisateurs ne savent plus où ils se trouvent.
• Fenêtres modales qui piègent trop le focus. Échap ne ferme pas. L’utilisateur est bloqué.
• Cible du lien d’évitement non focusable. Le lien d’évitement saute vers #main mais <main id="main"> n’a pas tabindex="-1", donc le focus ne se déplace pas réellement et le Tab suivant repart du début de la page.

Deux bibliothèques méritent d’être connues : focus-trap pour gérer le focus dans les fenêtres modales, et tabbable pour trouver les éléments focusables dans un conteneur. Toutes deux sont légères et sans opinion.