Site web de PME : tester le parcours client au clavier
Votre site présente bien vos services. Les boutons répondent à la souris, le menu s’ouvre et le formulaire transmet les demandes. Pour compléter cette vérification, posez la souris et essayez le même parcours au clavier. Pouvez-vous choisir une offre, ouvrir ses détails, revenir à la page et demander un devis ?
Certaines personnes utilisent le clavier ou des dispositifs qui reposent sur ses commandes pour naviguer. Un menu inaccessible peut donc interrompre leur visite avant même la prise de contact. Le W3C propose un premier contrôle fondé sur l’accès aux commandes, leur activation et la possibilité de poursuivre son chemin. Premiers contrôles d’accessibilité, W3C WAI.
Pour une PME, ce test fournit des observations concrètes à discuter avec le prestataire web. Voici comment l’organiser autour d’une tâche utile à vos visiteurs.
Choisir un trajet précis et préparer l’essai
Prenons une entreprise fictive de maintenance de bâtiments. Son site permet de consulter les prestations, de vérifier la zone d’intervention dans une fenêtre et de demander un devis. L’entreprise, son site et les anomalies décrites ici sont entièrement inventés.
Écrivez le scénario avant de commencer : « Depuis l’accueil, trouver l’entretien des équipements, consulter la zone couverte, puis préparer une demande. » Précisez le point de départ et le résultat attendu. Vous pourrez rejouer exactement le même trajet après correction.
Notez le navigateur, sa version, le système et la taille de la fenêtre. Vérifiez que la navigation au clavier vers tous les contrôles est activée dans votre environnement, notamment sur Mac. Si vous hésitez, demandez au prestataire de préparer ce réglage avec vous.
Utilisez des coordonnées de test et un message clairement identifié. Convenez de l’essai avec la personne qui reçoit les formulaires ; sur une préproduction, vérifiez où partent les envois. Le contrôle doit pouvoir atteindre la confirmation sans créer de fausse demande commerciale.
Avancer en sachant toujours où l’on se trouve
La touche Tabulation permet généralement de passer au prochain élément interactif ; Maj + Tabulation revient en arrière. Entrée active un lien ; un bouton peut s’actionner avec Entrée ou Espace. Certains contrôles, comme les listes de choix, utilisent aussi les flèches. Ces commandes constituent le point de départ du test, pas une obligation de tout parcourir avec une seule touche. Guide de contrôle au clavier, W3C WAI.
Observez le repère qui indique l’élément actif : on l’appelle le focus. Il peut prendre la forme d’un contour autour d’un bouton. Vous devez pouvoir identifier la commande que vous allez activer. Le critère « Focus visible » du W3C porte sur cette indication ; sa disparition au bout de quelques secondes pose également problème. Comprendre le focus visible, W3C.
Dans notre exemple fictif, le bouton du menu reçoit bien le focus, mais aucun contour ne le signale. La personne teste alors au hasard. Consignez cette observation même si le menu finit par s’ouvrir : l’accès à une commande et la perception de sa position sont deux vérifications distinctes.
Regardez aussi l’ordre du parcours. Le W3C demande qu’il préserve le sens et le fonctionnement de la page ; il n’impose pas de reproduire mécaniquement chaque position visuelle. Un saut inexpliqué vers le pied de page mérite néanmoins une investigation. Ordre du focus, W3C.
Ouvrir les menus et pouvoir en sortir
Activez les éléments qui changent la page : menu, accordéon, fenêtre de détails, réservation intégrée. Pour chacun, vérifiez l’entrée, l’utilisation et la sortie. Un composant qui fonctionne isolément peut encore empêcher de rejoindre la suite du parcours.
Dans notre entreprise fictive, la zone d’intervention s’affiche dans une fenêtre modale : elle bloque temporairement l’interaction avec la page située derrière. Le modèle de dialogue du W3C prévoit que le focus entre dans cette fenêtre, que Tabulation y circule et qu’Échap permette de la fermer. À la fermeture, le focus revient normalement au bouton d’origine, sauf si la suite de la tâche justifie une autre destination. Modèle de dialogue modal, W3C APG.
Rester dans une fenêtre modale ouverte n’est donc pas, à lui seul, un défaut. Le problème apparaît lorsqu’on ne peut plus la quitter au clavier. Le critère « Aucun piège au clavier » traite précisément cette possibilité de sortie. Comprendre les pièges au clavier, W3C.
Vérifiez enfin les éléments fixes : bandeau, en-tête ou module de discussion. Un bouton actif peut se retrouver entièrement caché derrière eux. Le W3C identifie ce cas dans le critère « Focus non masqué ». Visibilité de l’élément actif, W3C.
Aller jusqu’à la correction d’une erreur
Une fois arrivé au formulaire, remplissez les champs avec les données prévues. Laissez volontairement un champ obligatoire vide, puis essayez d’envoyer. Repérez le message obtenu et revenez au champ concerné sans reprendre la souris.
Le W3C recommande des messages d’erreur compréhensibles, reliés aux champs concernés et accompagnés d’une indication pour corriger la saisie. Il recommande aussi de confirmer la réussite de l’opération. Notifications de formulaire, W3C WAI.
Dans notre scénario, vérifiez que la description de la demande reste présente après l’erreur. Corrigez le champ, envoyez, puis cherchez la confirmation. Notez toute étape où vous perdez votre position ou ne comprenez plus ce qui est attendu.
Ce contrôle complète notre article sur les formulaires qui facilitent les demandes des prospects. Le choix des informations demandées et la possibilité de les saisir méritent chacun une vérification.
Transformer le blocage en correction vérifiable
« Le menu fonctionne mal » laisse beaucoup de place à l’interprétation. Décrivez plutôt la page, les touches utilisées, ce que vous attendiez et ce qui s’est produit. Ajoutez une capture ou une courte vidéo si elle aide à retrouver l’état concerné.
Voici une fiche de contrôle pour notre exemple fictif. Elle illustre la façon de documenter un problème ; elle ne rapporte aucun test réel.
Observation fictive | Résultat à vérifier après correction |
|---|---|
Le bouton du menu reçoit le focus sans repère visible. | Sa position reste identifiable avant l’activation. |
La fenêtre des zones d’intervention ne se ferme qu’à la souris. | Elle se ferme au clavier et le parcours reprend à un endroit logique. |
Le bandeau fixe cache entièrement le bouton actif. | Le bouton reste repérable pendant la navigation. |
Après une erreur, la description de la demande disparaît. | Le visiteur corrige le champ concerné sans réécrire son message. |
Attribuez chaque correction à une personne et fixez une date de vérification. Traitez d’abord les obstacles qui empêchent de poursuivre ou de terminer la tâche. Demandez au prestataire de rechercher le même défaut dans les composants réutilisés ailleurs : un menu commun peut concerner plusieurs pages.
Rejouez ensuite le scénario complet, depuis son point de départ. Corriger la fermeture d’une fenêtre ne suffit pas si le visiteur perd sa position juste après. Conservez le résultat daté et la version du site testée.
Inscrire ce contrôle dans les mises à jour
Gardez cette fiche pour les prochaines modifications du menu, des fenêtres et des formulaires. Ajoutez progressivement d’autres trajets importants : téléchargement d’un document, inscription ou prise de rendez-vous. Cette approche s’intègre à une démarche d’optimisation du site sans refonte.
Un parcours réussi au clavier reste un contrôle partiel. Le W3C précise que les outils automatiques ne peuvent pas évaluer tous les aspects de l’accessibilité et nécessitent un jugement humain. Faites compléter ce premier travail par une évaluation plus large, notamment avec les technologies d’assistance et les personnes concernées. Choisir des outils d’évaluation, W3C WAI.
Chez Studio UNIQ, nous pouvons vous aider à définir les parcours prioritaires et à organiser des corrections dont le résultat se vérifie. Parlons des usages de votre site.