Commencer avec WCAG 2.1 AA : Guide Pratique pour les Développeurs
Un guide complet pour implémenter les normes WCAG 2.1 AA sur vos sites. Couvre les critères essentiels et comment les appliquer concrètement.
Navigation au Clavier : Implémenter une Interaction Complète
Apprenez à rendre tous vos composants interactifs accessibles au clavier. Couvre les focus visibles, l’ordre de tabulation, et les raccourcis clavier essentiels.
9 min de lecture
Intermédiaire
Avril 2026
La navigation au clavier n’est pas un bonus, c’est une nécessité. Des millions de personnes dépendent du clavier pour utiliser le web — que ce soit par choix ou par besoin. Les utilisateurs souffrant d’arthrite, de tremblements, ou simplement ceux qui préfèrent la productivité du clavier, doivent pouvoir accéder à chaque fonction de votre site sans souris.
Mais voilà le problème : beaucoup de sites modernes cassent complètement la navigation au clavier. Les focus ne sont pas visibles, l’ordre de tabulation est chaotique, et certains boutons ne répondent qu’au clic. C’est frustrant pour l’utilisateur et contraire aux standards WCAG 2.1 AA que vous devriez déjà respecter.
Les Fondamentaux : Focus et Tabulation
Commençons par les bases. Chaque élément interactif — un lien, un bouton, un champ de formulaire — doit être accessible au clavier. Et ça ne veut pas dire « on peut y accéder si on appuie longtemps ». Ça veut dire que la touche Tab doit fonctionner naturellement.
L’ordre de tabulation doit suivre l’ordre logique de la page. De gauche à droite, de haut en bas, comme vous le liriez normalement. Si quelqu’un appuie sur Tab et qu’il saute du pied de page au header sans raison, c’est cassé. Vous pouvez contrôler cet ordre avec l’attribut
tabindex
, mais honnêtement, si votre HTML est bien structuré, vous n’en aurez pas besoin.
Le focus visuel est tout aussi important. Ce petit contour qui apparaît quand vous naviguer au clavier — beaucoup de gens l’enlèvent avec
outline: none
. Mauvaise idée. Vous devez le garder ou fournir une alternative visuelle clairement visible. Un utilisateur au clavier a besoin de savoir où il est sur la page.
Conseil Pratique
Testez votre site vous-même en enlevant la souris pendant 10 minutes. Naviguez uniquement au clavier. Vous découvrirez rapidement ce qui ne fonctionne pas.
Composants Personnalisés : Le Vrai Défi
Les boutons natifs du HTML ? Ils fonctionnent au clavier par défaut. Les éléments
<input>
? Pareil. Mais dès que vous créez un composant personnalisé — un menu déroulant custom, un carrousel, un système d’onglets — vous devez gérer le clavier vous-même.
C’est là que les choses deviennent intéressantes. Un menu déroulant custom doit supporter Tab pour entrer dans le menu, puis les flèches pour naviguer entre les options. Entrée pour sélectionner. Échap pour fermer. Ce ne sont pas des conventions aléatoires — ce sont les patterns établis par ARIA Authoring Practices Guide.
Vous devez aussi gérer le focus management. Quand un menu se ferme, le focus doit revenir au bouton qui l’a ouvert. Quand une modale s’ouvre, le focus doit entrer dedans et être piégé là jusqu’à ce qu’elle se ferme. C’est ce qu’on appelle le « focus trap ».
Articles Connexes
ARIA et HTML Sémantique : Structurer pour les Lecteurs d’Écran
Maîtrisez les attributs ARIA et le HTML sémantique pour une meilleure compatibilité avec les lecteurs d’écran et technologies d’assistance.
Accessibilité Visuelle : Contraste, Taille Police et Modes Sombres
Accommodez les utilisateurs malvoyants avec des contrastes adéquats, des tailles de police ajustables et un support natif du mode sombre.
Important à Savoir
Cet article fournit des informations éducatives sur l’accessibilité au clavier. Les standards et recommandations mentionnés (WCAG 2.1 AA, ARIA Authoring Practices) sont des ressources publiques. La mise en œuvre exacte dépendra de votre contexte spécifique, de votre stack technologique, et de vos utilisateurs. Consultez les guides officiels du W3C et testez avec de vrais utilisateurs de technologies d’assistance.
Mettre Tout en Pratique
Donc, comment démarrer ? Commencez par l’audit. Testez votre site au clavier. Vérifiez que le focus est visible partout. Assurez-vous que l’ordre de tabulation a du sens. Si vous utilisez des composants personnalisés, consultez les patterns d’ARIA Authoring Practices et implémentez les raccourcis clavier attendus.
Ensuite, automatisez. Utilisez des outils comme axe DevTools ou Lighthouse pour détecter les problèmes courants. Mais rappelez-vous : aucun outil n’est parfait. Le test manuel avec de vrais utilisateurs reste la meilleure approche.
La navigation au clavier est un élément fondamental de l’accessibilité. Ce n’est pas compliqué une fois qu’on comprend les principes. Et c’est un investissement qui bénéficie à tout le monde — pas seulement aux utilisateurs de technologie d’assistance.
Véronique Desmet
Directrice de l’Accessibilité Numérique
Directrice de l’accessibilité numérique chez Accès Inclusif SPRL, Véronique Desmet est une experte belge reconnue en conformité WCAG 2.1 AA et conception inclusive.