Accessibilité d’un site : premiers tests au clavier et sur mobile

Accessibilité et performance web · 6 min de lecture

Pour effectuer de premiers tests d’accessibilité de votre site au clavier et sur mobile, essayez un parcours utile sans souris, puis sur un téléphone réel. Vérifiez que chaque commande reste accessible, identifiable et utilisable, y compris avec du texte agrandi. Consignez les blocages avec les étapes permettant de les reproduire. Cette démarche prépare des corrections ciblées ; elle ne permet pas de déclarer le site conforme.

À retenir

• Testez une action complète, pas seulement l’apparence de l’accueil.
• Un bouton visible n’est pas forcément utilisable au clavier.
• Sur mobile, contrôlez aussi les formulaires, le zoom et les éléments fixes.
• Après correction, rejouez exactement le même parcours.

Préparer les tests sans perturber l’activité

Choisissez un parcours courant : trouver une prestation et remplir une demande, ou sélectionner un produit et rejoindre le panier. Ajoutez les composants partagés, comme le menu, la recherche et le bandeau de consentement. Notez l’adresse de chaque page, le navigateur et l’appareil utilisés.

Pour les envois de formulaires ou les paiements, utilisez un environnement de test autorisé. Sur le site public, arrêtez-vous avant une action qui créerait une vraie demande ou commande. Préparez une liste d’anomalies avec quatre informations : étapes, résultat observé, résultat attendu et preuve visuelle.

Tester la navigation au clavier

Suivre le focus de commande en commande

Placez-vous dans la barre d’adresse, puis utilisez Tab pour avancer et Maj + Tab pour revenir. Le focus désigne l’élément qui reçoit les commandes du clavier ; un repère visuel doit permettre de le localiser. Il doit rester visible et suivre un ordre compréhensible, selon les premiers contrôles du W3C. Si vous perdez ce repère, notez la dernière commande identifiable.

Essayez Entrée sur les liens et Entrée ou Espace sur les boutons, selon leur fonctionnement. Pour les composants qui le prévoient, utilisez aussi les flèches. Vérifiez que les mêmes actions restent disponibles sans survol de souris : ouvrir le menu, choisir une variante, retirer un article du panier.

Vérifier les ouvertures et les sorties

Ouvrez chaque panneau ou fenêtre superposée au clavier. Pouvez-vous atteindre son contenu et sa fermeture ? Après fermeture, pouvez-vous reprendre la navigation à un endroit cohérent ? Un focus contenu dans une fenêtre ouverte n’est pas forcément un problème. Le blocage apparaît si vous ne pouvez plus en sortir par une commande accessible, sans reprendre la souris.

Contrôler le site sur un téléphone

Refaites le parcours en portrait, puis regardez ce qui change en paysage. Essayez les commandes proches les unes des autres : filtre, quantité, fermeture, choix de livraison. Relevez les appuis qui déclenchent une mauvaise action. Vérifiez qu’un bandeau fixe ne masque ni le contenu utile ni le bouton pour poursuivre.

Agrandissez le texte avec les réglages disponibles. Sur ordinateur, complétez par un essai à 200 % de zoom et, si possible, par l’agrandissement du texte seul. Les libellés et messages doivent rester lisibles, sans chevauchement. Le critère de redistribution du W3C prévoit, pour le contenu à défilement vertical, une largeur équivalente à 320 pixels CSS sans défilement dans deux directions, avec des exceptions pour les parties qui nécessitent réellement une disposition en deux dimensions, comme certaines cartes ou tables de données. Ces exceptions ne s’étendent pas automatiquement au reste de la page. Un essai sur téléphone ne vérifie pas, à lui seul, ce critère.

Vérifier les formulaires pendant la saisie

Les champs conservent-ils un intitulé compréhensible une fois remplis ? Le guide W3C sur les libellés recommande des libellés associés aux champs. Ne prenez pas une indication qui disparaît pendant la saisie pour un libellé suffisant. En environnement de test, laissez un champ obligatoire vide : identifiez l’erreur, retrouvez le champ et corrigez-le. Sur téléphone, vérifiez aussi ce que masque le clavier virtuel.

Exemple illustratif : un menu impossible à quitter

Dans cet exemple fictif, une boutique de céramique affiche un menu mobile superposé. Son ouverture fonctionne au clavier, mais sa croix de fermeture n’est pas atteignable. L’anomalie est décrite ainsi : ouvrir le menu avec Entrée, parcourir ses liens avec Tab, constater l’absence de fermeture accessible. Le résultat attendu est de pouvoir fermer le menu au clavier, puis reprendre la navigation.

La correction doit rétablir le fonctionnement de la fermeture au clavier et un retour du focus cohérent ; agrandir la croix ne suffit pas. Le test suivant vérifie ces deux points, puis contrôle la fermeture au toucher. Aucun résultat commercial n’est déduit de cet exemple.

Checklist opérationnelle

• Définir le parcours et ses actions finales, avec un cadre de test sûr.
• Atteindre chaque commande au clavier et repérer le focus.
• Ouvrir et fermer menus, panneaux et fenêtres sans souris.
• Tester les choix, la saisie et les erreurs sur téléphone.
• Contrôler l’agrandissement et les éléments fixes.
• Transmettre chaque anomalie avec ses étapes et son résultat attendu.
• Rejouer les parcours concernés après correction.

Limites et erreurs fréquentes

Un outil automatique ou une capture mobile ne remplace pas ces essais. Tester uniquement l’accueil laisse de côté les étapes décisives. Confondre confort visuel et accessibilité complète est également risqué : ces tests ne couvrent pas tous les contrastes, alternatives d’images, contenus multimédias ou usages avec technologies d’assistance. Le W3C précise que ses contrôles préliminaires peuvent laisser passer des obstacles importants.

Questions fréquentes

Pourquoi tester sans souris si les visiteurs l’utilisent ?

Certains visiteurs naviguent au clavier ou utilisent des dispositifs reposant sur des commandes clavier. Le test révèle des commandes inaccessibles et des impasses que la souris peut masquer.

L’affichage mobile de l’ordinateur suffit-il ?

Il aide à examiner la mise en page, mais ne reproduit pas tout : toucher, clavier virtuel, réglages du téléphone et comportement du navigateur. Complétez-le sur un appareil réel.

Ces contrôles prouvent-ils une conformité réglementaire ?

Non. Ils repèrent une partie des obstacles. L’évaluation de conformité demande un périmètre et une méthode adaptés ; les obligations applicables à votre entreprise nécessitent une vérification distincte.

Prochaine étape

Documentez le premier blocage empêchant une action importante, puis confiez sa correction avec un critère de validation observable. Pour situer cet accompagnement dans votre projet, consultez les services 4SYSTEM. Conservez votre fiche de test pour vérifier la correction.

Sources et ressources

• W3C : premiers contrôles d’accessibilité.
• W3C : comprendre la redistribution du contenu.
• W3C : associer des libellés aux champs.