Accessibilité d'un site web : commencer par un parcours réel

L’accessibilité d’un site signifie que des personnes utilisant différents appareils et outils peuvent percevoir le contenu et terminer une tâche. La note d’un vérificateur automatique révèle certains défauts, mais ne démontre pas que l’achat ou la demande de devis fonctionne. Commencez par un parcours réel, puis testez-le autrement qu’à la souris.

Choisir une tâche représentative

Prenez un parcours important : trouver un service, comparer des produits, demander un devis, acheter ou retrouver une commande. Notez la page de départ, les étapes et le résultat réussi. Incluez un téléphone et au moins un cas d’erreur courant, comme un champ de formulaire invalide.

Choisissez des pages représentant les modèles utilisés dans le parcours. Si un menu partagé échoue, le défaut peut toucher tout le site. Si un seul article édité manuellement a un titre manquant, sa portée est plus locale. Conservez les URL exactes et les détails de l’appareil pour que le test soit reproductible.

La Web Accessibility Initiative du W3C propose des contrôles faciles pour commencer et précise qu’ils ne forment pas une évaluation complète. Servez-vous-en pour repérer les premiers problèmes, puis étendez le test aux composants identiques.

Naviguer au clavier

Laissez la souris de côté. Utilisez Tab et Maj+Tab pour parcourir liens, boutons et champs ; Entrée ou Espace pour activer les commandes adaptées. Voyez-vous où se trouve le focus ? Suit-il un ordre compréhensible ? Peut-on ouvrir et fermer les menus, choisir une variante, envoyer un formulaire et sortir d’une fenêtre sans rester bloqué ?

Un <div> cliquable peut fonctionner au pointeur et échouer au clavier. Un carrousel peut cacher ses boutons ou déplacer le focus hors de l’écran. Notez l’étape et le navigateur où le parcours s’arrête. Corrigez le composant, puis refaites la tâche complète.

Un contrôle clavier ne prouve pas que les lecteurs d’écran fonctionnent bien. Il révèle une classe d’obstacles. Une évaluation plus large demande des essais avec technologies d’assistance et, si possible, des retours de personnes qui les utilisent.

Lire textes, titres et images

Zoomez et réduisez la largeur. Le texte reste-t-il lisible ? La hiérarchie des titres explique-t-elle la page ? Peut-on reconnaître produit, prix et prochaine étape sans dépendre seulement de la couleur ou de la position ? Testez un écran étroit, pas seulement un ordinateur.

Pour les images informatives, l’alternative doit transmettre leur rôle. Une photo produit peut recevoir une description concise ; un graphique complexe exige aussi sa conclusion dans le texte proche. Une décoration peut porter une alternative vide. Le tutoriel W3C sur les images explique comment choisir selon l’usage.

Ne remplissez pas tous les attributs alt avec le mot clé SEO : un lecteur d’écran lirait alors du bruit répétitif. Un bouton représenté par une seule icône doit avoir un nom compréhensible pour son action, pas seulement « icône ».

Tester formulaires et erreurs

Ouvrez un formulaire et identifiez chaque champ sans dépendre uniquement d’un placeholder qui disparaît pendant la saisie. Envoyez-le vide ou avec une valeur invalide. Le message explique-t-il la correction et désigne-t-il le bon champ ? Peut-on reprendre sans tout recommencer ? La confirmation est-elle visible et compréhensible ?

Le tutoriel W3C sur les formulaires couvre libellés et instructions. Un libellé visible aide aussi les personnes utilisant la dictée vocale ou ayant besoin d’un repère cognitif. Testez les champs obligatoires et les gestionnaires de mots de passe si nécessaire.

Pour le paiement, vérifiez que les changements de prix, options de livraison et confirmations sont perceptibles. Un champ techniquement valide ne suffit pas si le client ne peut pas comprendre le total ou terminer l’achat.

Traiter les outils automatiques comme une preuve parmi d’autres

Lancez un contrôle automatique sur plusieurs modèles de page pour repérer les noms manquants ou des contrastes suspects. Relisez chaque alerte sur la page rendue. Certaines sont fausses ; certains blocages graves échappent à l’outil. Le W3C rappelle qu’une évaluation humaine reste nécessaire.

Priorisez selon la tâche empêchée, le nombre de pages touchées et la possibilité de corriger un composant partagé. Un bouton d’achat impossible à atteindre au clavier mérite une intervention immédiate. Une alternative redondante sur une illustration secondaire peut attendre.

Retester avec des personnes et entretenir le résultat

Après correction, refaites le parcours depuis le départ. Testez une autre page utilisant le même modèle. Demandez à une personne qui ne connaît pas le site d’accomplir la tâche et repérez les instructions peu claires. Ne revendiquez pas une conformité à une norme à partir de quelques vérifications : un audit formel couvre davantage de situations.

Ajoutez ces contrôles aux changements de menus, formulaires, variantes et paiement. Une mise à jour de thème ou de plugin peut réintroduire un obstacle. L’objectif pratique est que davantage de visiteurs puissent terminer ce qu’ils sont venus faire.

Exemple de fiche d’anomalie complète

Imaginez une fiche produit où le focus clavier atteint le choix de couleur mais n’arrive plus au bouton « ajouter au panier ». Notez l’URL publique, le navigateur, la largeur d’écran, le point de départ, les touches utilisées, le résultat attendu et le résultat obtenu. Une courte vidéo sans données personnelles peut aider. Vous donnez ainsi au développeur un défaut reproductible, plutôt qu’une demande vague « d’améliorer l’accessibilité ».

Après correction du sélecteur, refaites les mêmes étapes. Testez ensuite un autre produit qui utilise ce composant et terminez le paiement. Le premier défaut peut avoir disparu alors qu’un deuxième obstacle subsiste. Fermez l’anomalie quand la tâche client, pas seulement le bouton isolé, fonctionne. Gardez la procédure dans les contrôles de mise en ligne pour éviter qu’une prochaine modification réintroduise le blocage.