Ce qui se passe mal lors de l'utilisation au clavier uniquement
L'erreur la plus courante lors de l'utilisation au clavier uniquement est que les éléments interactifs sont visibles, mais pas accessibles avec la touche Tab. Pensez à un menu qui ne s'ouvre qu'au clic de la souris, un bouton qui n'obtient pas le focus, ou une fenêtre contextuelle qui ne peut pas être fermée sans la souris. Pour les personnes qui ne peuvent pas utiliser la souris en raison de limitations motrices, ou qui utilisent un lecteur d'écran qui fonctionne sur la navigation au clavier, cela signifie qu'une partie du site Web est simplement inutilisable.
La cause se trouve presque toujours dans les éléments personnalisés : un développeur construit un beau menu déroulant, un sélecteur de date personnalisé ou un filtre déroulant avec du HTML et du JavaScript personnalisés, mais oublie le support du clavier que les éléments HTML standard obtiennent gratuitement. L'élément a l'air bien et fonctionne avec la souris, donc personne ne remarque pendant les tests que la touche Tab le saute simplement.
Pourquoi c'est souvent négligé
Cette erreur est tenace parce qu'elle n'est pas visible à l'œil nu. Quiconque clique dans une boutique en ligne avec une souris ne voit aucun problème. Ce n'est que lorsque vous oubliez la souris et ne naviguez dans la page qu'avec Tab, Maj+Tab, Entrée et les touches fléchées que devient visible où la navigation s'arrête. Comme ces tests ne font rarement partie d'un processus standard de livraison, le problème reste souvent inaperçu pendant des années — jusqu'à ce qu'un visiteur ou une autorité de surveillance le rencontre.
Une deuxième raison est que bon nombre de ces défauts se produisent précisément aux endroits les plus visibles lors de l'utilisation : l'étape d'achat, l'écran de connexion, un filtre de recherche. Ce sont précisément les éléments qui sont souvent développés séparément du reste du site, avec des composants personnalisés qui ne reçoivent pas toujours le même soin que la navigation principale.
Comment vous pouvez vérifier cela vous-même
Un premier contrôle simple consiste à lâcher la souris et à parcourir une séquence de pages en utilisant uniquement le clavier. Prêtez attention à trois choses : chaque élément cliquable est-il accessible via Tab, est-il clair à tout moment quel élément a le focus, et chaque élément qui s'ouvre — un menu, un filtre, une fenêtre contextuelle — peut-il également être fermé sans la souris. Si le focus s'arrête dans une fenêtre contextuelle, saute à un endroit inattendu ou disparaît complètement, c'est un signal qu'il y a du travail à faire.
Une analyse automatisée peut détecter certains de ces problèmes, par exemple les indicateurs de focus manquants ou les éléments sans accès au clavier qui sont techniquement reconnaissables dans le code source. Cependant, qu'un menu déroulant puisse être utilisé de manière logique et prévisible est quelque chose qu'une analyse ne peut pas évaluer complètement — c'est en essence un test humain. Cela s'applique d'ailleurs à d'autres exigences WCAG, et nous le mentionnons toujours dans le rapport. lancez l'analyse rapide gratuite de vos pages les plus importantes pour voir quelle part de ce type de problèmes est déjà automatiquement détectée.
Comment vous pouvez l'éviter
La solution ne réside généralement pas dans une technologie supplémentaire ajoutée au site Web, mais dans l'utilisation correcte des éléments existants. Un bouton ou un lien HTML standard est automatiquement accessible via Tab et utilisable avec Entrée ; si au lieu de cela vous rendez un morceau de texte ou une image cliquable avec JavaScript, vous devez ajouter vous-même ce support au clavier. Pour les composants personnalisés tels que les menus, les filtres et les fenêtres contextuelles, une entente claire avec le développeur est nécessaire : chaque élément doit pouvoir être ouvert, utilisé et fermé au clavier, et le focus doit rester visible et prévisible.
Ce qui n'aide pas ici, c'est un widget d'accessibilité qui prétend corriger ce type de défauts avec un script détaché. Un tel overlay ne change rien au code sous-jacent et donc rien à la véritable utilisabilité ; la loi demande un site web accessible, pas une couche par-dessus. Nous refusons délibérément de vendre ce type de widgets.
Voulez-vous savoir quelles parties de votre site web ou de votre application contiennent ce type de problèmes structurels, et quel poids cela a dans la liste des priorités de votre plan d'amélioration ? Dans la base de connaissances organisée par sujet vous lisez par type de défaut ce qui se passe, et comment notre évaluation est exactement élaborée vous voyez quelle partie en est évaluée automatiquement et quelle partie demande une attention manuelle.
Avez-vous d'autres questions sur ce qui relève ou non de cette exigence, ou sur le reste du cadre d'évaluation ? Les réponses aux questions fréquemment posées donnent déjà une réponse à la plupart d'entre elles.
Le scan rapide gratuit d'axessia.eu donne immédiatement une indication de la présence de ce type de problèmes de clavier sur votre site, sans que vous ayez besoin d'un compte.