Navigation clavier et accessibilité : testez votre site sans souris

Pourquoi la navigation clavier compte pour l'accessibilité

Le W3C rappelle qu'un contenu utilisable au clavier l'est aussi par les personnes aveugles, qui ne peuvent pas se servir d'une souris, laquelle demande une coordination œil-main. Il l'est également par celles qui utilisent un clavier alternatif ou un dispositif qui émule le clavier : logiciels de saisie vocale, systèmes à souffle (sip-and-puff), claviers à l'écran, logiciels de balayage et diverses aides techniques.

Les personnes malvoyantes peuvent avoir du mal à repérer ou suivre le pointeur à l'écran ; pour elles, un logiciel est parfois bien plus facile, voire seulement possible, à utiliser au clavier. Certaines personnes ayant des tremblements des mains trouvent la souris très difficile à utiliser et se servent donc généralement du clavier. Le critère 2.4.7 profite en outre aux personnes ayant des limitations de l'attention, de la mémoire à court terme ou des fonctions exécutives, qui ont besoin de savoir où se trouve le focus.

Point souvent mal compris : les MouseKeys, qui pilotent le pointeur avec les touches, ne suffisent pas à satisfaire le critère 2.1.1. Pour l'application, elles se comportent comme une souris, pas comme un clavier.

Préparer le test de navigation clavier

Choisissez quelques pages représentatives : l'accueil, une page de contenu, un formulaire, et les parcours qui comptent pour vos visiteurs, comme une inscription ou une commande. Débranchez la souris ou laissez-la de côté, puis cliquez une seule fois dans la barre d'adresse si nécessaire pour partir du haut de la page.

Pendant tout le test, n'utilisez que ces touches :

• Tab pour avancer d'un élément interactif au suivant, Maj+Tab pour revenir en arrière ;
• Entrée et Espace pour activer les éléments : le W3C note que les boutons qui ont le focus s'activent généralement avec ces deux touches. Respecter cette convention est une bonne pratique ; un bouton personnalisé qui ne réagit qu'à Entrée satisfait tout de même le critère 2.1.1 ;
• les flèches pour vous déplacer à l'intérieur d'un composant quand Tab ne suffit pas ;
• Échap pour fermer une fenêtre de dialogue ou sortir d'un composant.

Étape 1 : tout est-il atteignable et utilisable au clavier (critère 2.1.1) ?

Le critère 2.1.1 demande que toutes les fonctionnalités du contenu soient utilisables via une interface clavier, sans exiger de rythme particulier pour chaque frappe. Exemple de rythme interdit selon le W3C : devoir répéter plusieurs frappes dans un délai très court, ou maintenir une touche enfoncée longtemps avant qu'elle soit prise en compte.

La seule exception vise les fonctions dont la nature même dépend du tracé du mouvement, et pas seulement de ses points de départ et d'arrivée, comme le dessin à main levée ou un logiciel d'aquarelle dont le trait varie selon la vitesse et la durée du geste. Elle porte sur la fonction, pas sur la technique de saisie : l'écriture manuscrite dépend du tracé, mais la saisie de texte qu'elle sert à produire n'est pas exemptée. De même, tracer une ligne droite, redimensionner une fenêtre ou glisser-déposer un objet vers un emplacement, lorsque le chemin pour y arriver n'a pas d'importance, ne relèvent pas de cette exception.

Le critère n'oblige pas chaque contrôle visible à recevoir le focus : il faut qu'il existe un moyen d'accomplir la même action, ou une action comparable, au clavier. Le W3C cite un formulaire de recherche dont le bouton d'envoi ne reçoit pas le focus, mais qui reste conforme parce qu'on peut valider avec Entrée dans le champ texte. De même, une fonction de glisser-déposer peut proposer couper-coller ou des contrôles de formulaire pour déplacer les objets.

Ce qu'il faut noter pendant le test :

• un menu, un onglet, un carrousel ou un bouton qui réagit à la souris mais jamais au clavier, sans autre moyen d'accomplir l'action au clavier (échec F54 : fonction gérée uniquement par des gestionnaires d'événements propres au pointeur, gestes compris) ;
• un élément qui émule un lien (échec F42, qui concerne aussi les critères 1.3.1, 2.1.3 et 4.1.2) et qui ne fonctionne pas au clavier ;
• un élément qui perd le focus dès qu'il le reçoit à cause d'un script (échec F55) ;
• une iframe contenant des éléments interactifs exclue de l'ordre de tabulation, ou une zone défilante impossible à atteindre en navigation séquentielle.

Étape 2 : aucun piège au clavier (critère 2.1.2)

Le critère 2.1.2 exige que, si le focus peut être déplacé vers un composant au clavier, il puisse aussi en être retiré au clavier seul. Si la sortie demande autre chose que les flèches ou la touche Tab sans modificateur, ou d'autres méthodes de sortie standard, l'utilisateur doit être informé de la méthode. Le W3C précise que, sur la plupart des environnements dotés d'un clavier physique, Échap est une méthode de sortie standard courante.

Ce critère s'applique à tout le contenu de la page, même à un composant qui ne sert pas à satisfaire d'autres critères : un seul piège peut gêner l'utilisation de toute la page. Les pièges apparaissent souvent avec des contenus rendus par des plug-ins ou des applications intégrées, ou avec des composants personnalisés conçus sans penser au clavier.

Restreindre le focus n'est pas toujours une faute. Dans une fenêtre modale, le focus peut tourner du dernier au premier contrôle, à condition que l'utilisateur sache comment en sortir, par exemple en la fermant avec Annuler, OK ou Échap. Dans un éditeur de texte riche où Tab sert à indenter, une consigne peut indiquer le raccourci de sortie, comme Alt+F10 dans l'exemple du W3C.

Pour tester, entrez dans chaque composant (lecteur vidéo, carte, éditeur, widget tiers, modale) puis essayez d'en sortir avec Tab, Maj+Tab, les flèches et Échap. Le critère dispense de consigne uniquement lorsque la sortie se fait avec Tab ou les flèches sans modificateur, ou avec une méthode de sortie standard ; le W3C précise que ces méthodes standard ne sont pas définies par la spécification et dépendent du matériel, du navigateur et du système. Si vous ne pouvez pas sortir au clavier, ou si la sortie demande un autre raccourci sans qu'aucune instruction ne l'indique, c'est un échec.

Étape 3 : le focus est-il toujours visible (critère 2.4.7) ?

Le critère 2.4.7 demande que toute interface utilisable au clavier dispose d'un mode de fonctionnement où l'indicateur de focus est visible. Le W3C est clair : sans indicateur de focus, les personnes voyantes qui naviguent au clavier ne peuvent pas utiliser la page. L'indicateur ne doit pas être limité dans le temps : quand le focus est affiché, il doit rester visible.

Les navigateurs peuvent n'afficher le focus que lorsque le clavier est utilisé ; c'est admis. En revanche, l'échec F78 vise les styles appliqués aux contours ou bordures qui suppriment l'indicateur ou le rendent invisible. Les techniques reconnues incluent l'indicateur par défaut du navigateur ou de la plateforme, un indicateur personnalisé visible, un indicateur bicolore pour garantir le contraste, ou la pseudo-classe CSS :focus-visible.

Attention au contraste : l'indicateur de focus étant généralement un contenu non textuel, comme un contour, il relève aussi du critère 1.4.11 sur le contraste du contenu non textuel (niveau AA). Le critère 2.4.13 (niveau AAA) donne des indications sur la taille et la forme de l'indicateur.

Pendant le test, à chaque appui sur Tab, vous devez pouvoir dire sans hésiter quel élément a le focus : un contour autour du bouton, ou une barre d'insertion dans un champ texte.

Liste de vérification de la navigation clavier

Gardez cette liste sous les yeux pendant le test, page par page, et notez chaque anomalie avec l'élément concerné :

• Chaque lien, bouton, champ et contrôle personnalisé peut être atteint ou son action réalisée autrement au clavier.
• Aucune action n'exige de frappes rapides répétées ni une touche maintenue longtemps.
• Les contenus défilants et les iframes interactives sont accessibles en navigation séquentielle.
• On sort de chaque composant avec Tab ou les flèches sans modificateur, ou avec une méthode de sortie standard comme Échap ; sinon, une consigne indique comment sortir.
• On peut quitter chaque fenêtre modale au clavier, par exemple en la fermant avec Échap ou un bouton.
• Le focus est visible sur chaque élément, sans disparaître au bout de quelques instants.
• Aucun script ne retire le focus d'un élément au moment où il le reçoit.
• Bonne pratique en complément, hors des trois critères étudiés ici : notez si l'ordre de passage du focus vous paraît déroutant par rapport à la lecture de la page.

Compléter le test manuel par une surveillance continue

Le test au clavier reste un geste humain : il faut parcourir les pages et juger ce que l'on voit. Pour ne pas laisser une régression passer inaperçue entre deux tests, vous pouvez lancer un test gratuit de votre site avec Conformly puis activer la surveillance continue, et réserver vos passages manuels au clavier aux parcours clés.

Questions fréquentes

À lire aussi sur Conformly

• Corriger un focus invisible en HTML
• Critère RGAA 12.9 sur les pièges au clavier
• Critère RGAA 7.3 sur les scripts au clavier

Sources

Article appuyé sur les sources officielles citées en fin de page.

• W3C — Comprendre 2.1.1
• W3C — Comprendre 2.1.2
• W3C — Comprendre 2.4.7