Site web : voir où mène la navigation au clavier

Un visiteur parcourt votre site avec la touche Tab. Le menu, les liens et les boutons reçoivent tour à tour le focus : c’est l’élément auquel le clavier s’adresse à cet instant. S’il n’existe aucun repère visible, il devient difficile de savoir ce qu’un appui sur Entrée va déclencher. Le problème peut se cacher derrière une page pourtant soignée à la souris.

Le W3C explique le rôle du focus visible : permettre de reconnaître l’élément actif. Ce repère peut être un contour ou une autre mise en évidence perceptible. Il ne s’agit pas du même état que le survol de la souris. Le supprimer pour obtenir un dessin plus épuré peut donc retirer une information nécessaire à la navigation.

Trois difficultés qui ne se corrigent pas de la même façon

Ce que le visiteur constate	Ce qu’il faut examiner
Le repère disparaît sur un bouton	La visibilité de son état de focus.
Le repère reste visible, mais le menu est inutilisable	Le fonctionnement des commandes au clavier.
Une fenêtre s’ouvre et le visiteur ne retrouve plus la page	La fermeture de la fenêtre et la possibilité de poursuivre au clavier.

La distinction compte pour formuler une demande précise. Le critère WCAG sur le clavier concerne l’accès aux fonctionnalités par une interface clavier, avec une exception liée aux gestes dont la trajectoire est essentielle. Le critère sur les pièges au clavier traite, lui, de la possibilité de quitter un composant. Un contour bien visible ne résout pas à lui seul un menu impossible à ouvrir.

Imaginons une page de réservation : le visiteur atteint « Choisir une date », ouvre le calendrier et sélectionne un jour, mais ne peut plus rejoindre la suite du formulaire. La demande à transmettre est alors « permettre de continuer après le choix de date ». Dire seulement « améliorer le contraste du bouton » passerait à côté du blocage. Cet exemple illustre une situation possible, sans présumer du fonctionnement de votre site.

Observer un parcours complet, avec ses obstacles

Pour préparer un contrôle, choisissez une action représentative : trouver une prestation puis atteindre la demande de contact. Sur un navigateur configuré pour la navigation au clavier, observez le passage avec Tab et le retour avec Maj + Tab. Notez les endroits où le repère devient introuvable ou semble sauter une commande utile. Le test doit porter sur ce que le visiteur essaie d’accomplir, pas uniquement sur la page d’accueil.

Prêtez aussi attention aux bandeaux fixes et aux fenêtres superposées. Le critère WCAG 2.2 sur le focus non masqué demande au niveau minimum que le composant actif ne soit pas entièrement caché par un contenu créé par le site. Un bandeau peut donc compliquer le parcours même lorsque le style du focus est correct. Photographier ou décrire l’élément masqué aide à reproduire le défaut.

Ces observations constituent un relevé ciblé, pas un verdict sur l’accessibilité de tout le site. Un compte rendu utile indique la page, le navigateur, l’action recherchée et le point de blocage. Il permet ensuite de vérifier la correction dans les mêmes conditions, sans confondre préférence graphique et difficulté d’utilisation.

Faire du parcours un critère du projet

Un site facile à parcourir se prépare autour des actions réellement attendues. Les offres de création de sites Gaia présentent un travail sur la structure et l’ergonomie. Apportez à votre projet un parcours concret et les obstacles observés pour préciser les contrôles à prévoir ; cette offre ne doit pas être assimilée à une certification d’accessibilité.