Utiliser une page au clavier

Débranche la souris et appuie sur Tab : chaque lien, bouton et champ doit s'allumer à son tour, dans l'ordre où tu lis la page.

Qui utilise le clavier

Beaucoup de gens ne touchent jamais une souris. Certains ne peuvent pas la tenir sans trembler ; d'autres utilisent un contacteur, une baguette buccale ou une reconnaissance vocale qui envoie des frappes ; les utilisateurs de lecteurs d'écran se déplacent eux aussi surtout au clavier. Le critère de succès 2.1.1 Clavier des WCAG 2.2, de niveau A, dit que tout ce qui est sur la page doit fonctionner au clavier. Le critère 2.1.2 Pas de piège au clavier ajoute que si le focus peut entrer dans une partie de la page, il doit pouvoir en ressortir au clavier.

Utiliser des éléments qui fonctionnent déjà

Les liens avec un href, button, input, select et textarea peuvent recevoir le focus d'emblée et réagissent aux bonnes touches. Un div avec un gestionnaire de clic, non : on ne peut pas l'atteindre avec Tab, Entrée ne fait rien, et un lecteur d'écran ne l'annonce pas comme un bouton. Le conseil de MDN est simple. N'utilise pas tabindex pour faire jouer à un div le rôle d'un bouton ; utilise l'élément button, qui a déjà son rôle et son comportement au clavier.

L'ordre du focus et tabindex

L'ordre de Tab suit l'ordre des éléments dans le code source HTML. Le critère 2.4.3 Parcours du focus demande que cet ordre préserve le sens et l'utilisation de la page : la façon la plus simple de corriger un ordre étrange est donc de réorganiser le HTML. MDN distingue trois sortes de valeurs de tabindex. Zéro place un élément dans l'ordre normal. Une valeur négative, en général -1, le retire de l'ordre de Tab mais permet encore à un script d'appeler focus() sur lui, ce qui est utile pour une boîte de dialogue ou un message d'erreur. Une valeur positive force l'élément avant tout le reste, et MDN recommande de n'utiliser que 0 et -1, car les valeurs positives rendent l'ordre difficile à suivre.

Voir où l'on se trouve

Les utilisateurs du clavier doivent voir quel élément a le focus. Le critère 2.4.7 Visibilité du focus, de niveau AA, demande un indicateur de focus visible : une règle de style comme outline: none sans rien pour la remplacer est donc un échec. Les WCAG 2.2 ont ajouté deux critères liés. Le critère 2.4.11 Focus non masqué (minimum), de niveau AA, dit que l'élément qui a le focus ne doit pas être entièrement caché derrière quelque chose ajouté par l'auteur, comme un pied de page fixe ou un bandeau de cookies. Le critère 2.5.8 Taille de la cible (minimum), lui aussi AA, demande que ce sur quoi on clique ou on appuie mesure au moins 24 sur 24 pixels CSS, ou ait assez d'espace autour.

Un motif de plus aide énormément : le lien d'évitement. Sur un site au long menu, les utilisateurs du clavier doivent passer avec Tab par chaque élément du menu sur chaque page. Un lien placé en premier dans la page, qui pointe vers le contenu principal, leur permet de sauter le menu en une seule touche. Il peut rester masqué visuellement jusqu'à ce qu'il reçoive le focus.

Le test prend deux minutes. Clique dans la barre d'adresse, puis appuie plusieurs fois sur Tab pour parcourir toute la page. Vérifie que chaque commande est accessible, que l'ordre correspond à l'ordre de lecture, que tu vois toujours où est le focus, et qu'Entrée et Espace font ce que ferait un clic de souris. Appuie ensuite sur Maj+Tab pour revenir. Toute commande impossible à atteindre, ou tout endroit où le focus disparaît, est un bug.