Choisir les parcours
Incluez entrée depuis une page, navigation, formulaire, confirmation et état d’erreur. Testez aussi une page sur mobile et à fort zoom.
GUIDE / PROTOCOLE
Auditer l’accessibilité d’un parcours web
L’accessibilité se juge dans une tâche complète : trouver, comprendre, agir et récupérer après une erreur.
Réponse directe
Comment mener un audit d’accessibilité utile ?
Choisissez des parcours représentatifs et leurs états critiques. Combinez inspection du code, navigation au clavier et essais avec technologies d’assistance. Rattachez chaque défaut à une tâche bloquée, une exigence WCAG, une preuve et un nouvel essai.
01 / Méthode de contrôle
Méthode de contrôle
Parcourir au clavier
Vérifiez ordre de focus, visibilité du focus, accès à chaque commande, menus, modales et sortie des composants. Aucun piège clavier ne doit rester.
Vérifier sens et restitution
Contrôlez titres, noms accessibles, étiquettes, alternatives d’images, structure, contraste et annonces d’erreur avec un lecteur d’écran.
Prioriser puis rejouer
Classez les blocages par tâche et gravité, corrigez le composant partagé, puis rejouez le parcours et les pages qui le réutilisent.
02 / Preuves à conserver
Preuves à conserver
Scénario et environnement
URL, appareil, navigateur, technologie d’assistance, zoom et action tentée.
Reproduction
Étapes exactes, capture ou extrait DOM, résultat observé et résultat attendu.
Référence et impact
Critère WCAG concerné, personnes ou tâches affectées et sévérité motivée.
Contre-épreuve
Correctif, version, date et résultat du nouveau test clavier et lecteur d’écran.
APRÈS LE CONTRÔLE
Décider selon le constat
Le menu est visible mais inaccessible au clavier
Bloquez la validation du parcours, corrigez le composant partagé puis vérifiez ouverture, navigation et fermeture sur toutes ses pages.
Le contrôle automatique est vert mais la consigne reste incompréhensible
Conservez le résultat de l’outil, documentez l’échec de tâche et reformulez la consigne avant un essai avec les modes d’accès concernés.
03 / FAQ
Questions fréquentes
Un outil automatique suffit-il ?
Non. Il détecte certaines erreurs de code, mais ne juge pas toujours l’ordre logique, la compréhension ou la réussite d’une tâche.
Que tester en premier ?
Les composants partagés et les parcours essentiels : navigation, recherche, demande, paiement ou contact selon le site.
Faut-il tester chaque langue ?
Oui pour les écrans clés : langue déclarée, libellés, messages d’erreur et ordre de lecture peuvent changer.
Quand fermer une anomalie ?
Quand le scénario initial réussit avec les modes d’accès concernés et que la correction ne casse pas les autres états.
04 / Références officielles