Scène générée : un clavier avec sa touche Tab devant un écran de démonstration où le lien Contact est entouré de bleu.

Blog 1Design

Sans souris, peut-on vraiment atteindre le contact sur votre site ?

Menu, focus visible, fenêtre à fermer : testez le trajet vers le contact sans souris et transmettez à votre prestataire des défauts reproductibles.

Votre menu s’ouvre au survol, le bouton de contact change de couleur et la fenêtre de réservation semble fonctionner. Mais que se passe-t-il si l’on pose la souris et que l’on essaie de faire le même trajet au clavier ? Un site peut être parfaitement lisible et pourtant laisser une personne bloquée avant la première demande.

Le bon point de départ n’est pas de parcourir toutes les pages au hasard. Choisissez un trajet utile : accueil → prestation → contact, puis vérifiez que l’on peut l’effectuer, comprendre où l’on se trouve et revenir en arrière sans reprendre la souris. Ce contrôle ciblé révèle des obstacles concrets. Il ne constitue ni un audit complet d’accessibilité ni une attestation de conformité.

Le clavier ne sert pas seulement à remplir les champs

Certaines personnes utilisent un clavier parce qu’elles ne peuvent pas manipuler une souris, parce qu’elles naviguent avec une technologie d’assistance ou parce que ce mode d’interaction leur convient mieux. Le problème commence souvent avant le formulaire : un sous-menu inaccessible, une fenêtre impossible à fermer, un lien dont on ne voit jamais la sélection.

Le W3C distingue plusieurs exigences complémentaires. Le critère Clavier, WCAG 2.1.1 porte sur l’utilisation des fonctionnalités par une interface clavier, avec une exception pour certaines actions dépendant du tracé du mouvement, comme le dessin à main levée. Le critère Visibilité du focus, 2.4.7 demande que l’utilisateur puisse repérer visuellement l’élément sélectionné au clavier. Pouvoir agir et savoir sur quoi l’on agit sont deux vérifications différentes.

Le focus est simplement le point actif de la navigation : le lien, le bouton ou le champ auquel la prochaine action au clavier s’adressera. Un contour visible peut le matérialiser. Un changement de couleur uniquement au passage de la souris ne suffit pas à démontrer qu’il est visible au clavier.

Préparer un trajet que l’on pourra refaire après correction

Notez l’adresse de départ, le navigateur, le système utilisé et la largeur de la fenêtre. Si votre navigateur ou votre système limite par défaut la navigation clavier à certains contrôles, vérifiez ses réglages avant de conclure que tous les liens du site sont cassés. Le prestataire devra pouvoir reproduire vos observations dans le même environnement.

Pour ce premier passage, gardez les choix de confidentialité habituels et ne soumettez pas de demande réelle. Un formulaire peut être inspecté sans envoyer de message. Un test d’envoi relève d’une vérification distincte, avec un destinataire et des données de test convenus.

Les touches les plus utiles sont :

  • Tabulation pour avancer entre les éléments accessibles dans l’ordre de navigation ;
  • Maj + Tabulation pour revenir au précédent ;
  • Entrée pour activer notamment un lien ou un bouton ;
  • Espace pour activer les boutons natifs et certaines commandes, selon le composant ;
  • Échap pour fermer les interfaces qui prévoient cette commande, notamment de nombreuses fenêtres modales.

Les listes, groupes de choix et autres composants peuvent également utiliser les flèches. N’attendez donc pas que Tabulation traverse nécessairement chaque option d’un composant complexe. En revanche, le fonctionnement ne devrait pas reposer sur une combinaison secrète ou sur le passage préalable de la souris.

Premier passage : atteindre la bonne prestation

Depuis l’accueil, avancez sans cliquer. Voyez-vous toujours l’élément actif ? Le parcours suit-il un ordre compréhensible ? Si un lien d’accès direct au contenu apparaît au clavier, vérifiez sa destination : il doit réellement permettre d’éviter les éléments répétés.

Arrêtez-vous au menu. Si les prestations sont rangées dans un sous-menu, essayez de l’ouvrir, d’atteindre une prestation puis d’en sortir. Le fait que ce sous-menu fonctionne au survol ne répond pas à cette question. Notez aussi si le menu se referme avant que vous puissiez atteindre son contenu.

Ne transformez pas le nombre de pressions sur Tabulation en verdict automatique. Un menu fourni peut être long sans être inutilisable. Le signal préoccupant est plutôt un détour incompréhensible, une série de liens invisibles ou l’impossibilité d’atteindre la destination attendue.

Sur la page de prestation, rejoignez ensuite le lien de contact. Un bouton dessiné dans une image ou un texte qui ne réagit qu’au clic peut sembler évident à la souris tout en restant hors du parcours clavier. Demandez une correction du contrôle concerné, pas seulement l’ajout d’un autre bouton ailleurs.

Deuxième passage : repérer ce qui est sélectionné, même sous un bandeau

Un contour peut exister dans le code sans être visible à l’écran. Un en-tête fixe, un bandeau en bas de page ou une fenêtre superposée peut cacher l’élément actif lorsque la page défile.

Le critère Focus non masqué, minimum, WCAG 2.4.11 vise précisément le composant qui reçoit le focus : il ne doit pas être entièrement caché par un contenu créé par le site. Ce minimum de niveau AA n’exige pas à lui seul que tout le composant soit entièrement dégagé. Pour votre recette pratique, demandez néanmoins que le contrôle et son libellé restent faciles à repérer, plutôt que d’accepter un fragment à peine visible.

Refaites le passage avec une fenêtre plus étroite. L’affichage peut basculer vers un bouton de menu et changer l’ordre des éléments. Ce contrôle au clavier dans une fenêtre étroite complète le premier passage ; il ne remplace pas un essai sur un vrai téléphone avec ses modes d’interaction et technologies d’assistance.

Troisième passage : ouvrir une fenêtre et pouvoir en ressortir

Essayez les fenêtres présentes sur le trajet : prise de rendez-vous, choix d’une prestation ou informations complémentaires. Une fenêtre modale peut retenir volontairement la navigation à l’intérieur tant qu’elle est ouverte. Ce n’est pas, en soi, un piège : il faut pouvoir la fermer au clavier et poursuivre le parcours.

La règle Pas de piège au clavier, WCAG 2.1.2 exige de pouvoir quitter le composant au clavier. Si la méthode de sortie n’est pas standard, elle doit être indiquée. Le modèle de dialogue modal du W3C décrit notamment la fermeture par Échap et, dans le cas habituel, le retour du focus au contrôle qui a ouvert la fenêtre. Des exceptions existent lorsque la suite logique du travail appelle une autre destination.

Concrètement, vérifiez trois choses : le point actif entre dans la fenêtre à un endroit pertinent ; la commande de fermeture est utilisable ; après fermeture, vous retrouvez un point de départ cohérent. Une fenêtre qui disparaît mais vous renvoie sans explication tout en haut du site peut rendre la suite du trajet pénible.

Un exemple de signalement utile au prestataire

Voici un exemple fictif, pas le résultat d’un audit client : sur un site de services, le lien « Contact » ouvre une fenêtre. Le bouton « Fermer » fonctionne avec la souris, mais n’est jamais atteint au clavier. La personne reste dans la fenêtre sans savoir comment revenir à la prestation.

Écrire « améliorer l’accessibilité » ne permet pas de réceptionner la correction. Un signalement exploitable ressemble plutôt à ceci :

  • Départ : page de la prestation, fenêtre fermée.
  • Actions : avancer avec Tabulation jusqu’à « Contact », puis appuyer sur Entrée.
  • Observé : la fenêtre s’ouvre ; aucune commande de fermeture n’est atteignable dans le parcours essayé. Préciser aussi le résultat réel d’un essai avec Échap.
  • Attendu : une sortie clavier identifiable et un retour cohérent au parcours de départ.
  • Preuve : courte capture vidéo montrant l’élément actif, sans données personnelles, avec navigateur et date du test.
  • Recette après correction : refaire ouverture, fermeture et reprise du trajet au clavier, puis vérifier que le clic et l’affichage étroit fonctionnent toujours.

Cette fiche sépare ce que vous avez vu de la cause supposée. Elle évite d’accuser un plugin ou un thème sans diagnostic et permet de comparer l’avant et l’après sur une action précise.

Ce que ce contrôle permet de décider — et ce qu’il ne prouve pas

Corrigez en priorité les obstacles qui empêchent d’atteindre une prestation, de poursuivre vers le contact ou de quitter une fenêtre. Puis traitez les pertes de repère et les détours qui rendent le parcours difficile. Un outil automatique peut compléter le travail, mais il ne raconte pas à lui seul si une personne réussit ce trajet.

Si le parcours clavier passe, il reste d’autres sujets : noms accessibles, contrastes, structure des titres, restitution par lecteur d’écran et messages d’erreur, notamment. Notre guide sur les erreurs des formulaires de devis traite la reprise après une erreur ; ici, le contrôle porte d’abord sur la possibilité d’atteindre et d’utiliser les commandes.

Une création ou refonte de site internet peut intégrer ce trajet dans ses critères de réception, au même titre que le rendu mobile. Conservez les étapes et refaites-les après une modification du menu ou d’un composant de réservation.

Vous perdez le point actif ou restez bloqué sur votre site ? Transmettez à 1Design l’URL, les étapes exactes et le comportement observé. Un problème reproductible donne un meilleur point de départ qu’une demande générale de « rendre le site accessible ».

Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?

Recevoir 3 pistes gratuites pour améliorer votre site