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.
Illustration générée par IA · Clavier et afficheur braille. Scène illustrative.
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.
EN PRATIQUE
Vérifier un parcours, pas seulement une capture
Un écran lisible peut encore bloquer une action. Testez un objectif complet : trouver la bonne section, utiliser le contrôle, comprendre le résultat et revenir en arrière. Consignez le premier obstacle et son effet concret.
| Situation | À éviter | Correction utile |
|---|---|---|
| Navigation | Tester uniquement à la souris. | Parcourir au clavier et conserver un focus visible. |
| Formulaire | S’appuyer sur un texte provisoire dans le champ. | Garder un libellé visible et relier l’erreur au champ concerné. |
| Résultat dynamique | Changer un chiffre sans expliquer son contexte. | Présenter le résultat, son unité et ce qui vient de changer. |
Repérer
Le titre décrit-il la bonne tâche ?
Agir
Le contrôle est-il accessible et compréhensible ?
Comprendre
Le résultat et la prochaine action sont-ils explicites ?
Contrôle final
Rejouez le même parcours au clavier, sur mobile et avec JavaScript désactivé lorsque la page prévoit ce mode. Un contrôle réussi sur ce parcours ne vaut pas audit exhaustif.
Références documentaires
Consulté le .
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.
POINT DE CONTRÔLE
Avant de conclure
Une erreur de lecture fréquente et la vérification qui permet de l’éviter.
Conclusion trop rapide
Un score automatique élevé ne garantit pas que le parcours soit utilisable ; des obstacles de compréhension, de focus ou d’annonce d’erreur exigent une vérification humaine.
Contrôle décisif
Parcourir les tâches clés au clavier et avec une technologie d’assistance, noter l’étape bloquante et rattacher chaque correction à un critère vérifiable.
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.
Arbitrage et trace de décision
Arbitrage et trace de décision
Ce que le contrôle doit permettre de décider, et la preuve à conserver pour réexaminer ce choix.
Preuve suffisante
Parcourir au clavier les actions essentielles, les erreurs et les états dynamiques ; noter URL, élément, technologie d’assistance et résultat attendu. Un score automatique ne suffit pas.
Décision suivante
Classer d’abord les blocages de parcours. Corriger le composant commun, puis retester la tâche complète et les variantes mobile et linguistiques touchées.
Cas de contrôle approfondis
Situations types pour préparer un contrôle. Elles ne décrivent pas des missions ou observations réalisées.
Un tableau lisible à l’écran perd ses en-têtes
Ce qu’il faut examiner
Vérifier les associations entre cellules et en-têtes, la lecture linéaire et le déplacement au clavier. Une présentation visuelle correcte ne démontre pas que chaque valeur reste compréhensible avec une autre modalité de lecture.
Décision et action
Corriger la structure et les intitulés, puis reprendre une tâche précise de consultation. Distinguer le résultat d’un analyseur automatique de celui du parcours réellement effectué.
Preuve à conserver
Conserver le tableau testé, les cellules concernées, la modalité de lecture et la séquence qui permet de retrouver une valeur.
Le focus disparaît sous un bandeau fixe
Ce qu’il faut examiner
Parcourir les liens, ouvrir puis fermer les menus et changer de taille de fenêtre. Observer où se trouve le focus, si sa cible reste visible et si la fermeture rend la main au déclencheur.
Décision et action
Ajuster le positionnement, le défilement ou la restitution du focus. Rejouer le parcours complet, y compris après une erreur de formulaire, sans limiter le contrôle à la première tabulation.
Preuve à conserver
Noter la taille de fenêtre, les touches utilisées, le composant et les positions du focus avant et après la correction.
Le focus se perd après une interaction
Ce qu’il faut examiner
Parcourir filtre, menu et formulaire au clavier puis observer le focus après changement d’état.
Décision et action
Rendre la suite de la tâche atteignable et son résultat compréhensible.
Preuve à conserver
Séquence clavier, état, position du focus et correction.
Relecture avant décision
Ces questions complètent la méthode. Elles aident à vérifier ce qui est réellement établi, sans effacer les réserves du relevé.
Tâche au clavier
La tâche peut-elle être terminée au clavier, sans piège, avec focus visible et sans contrôle masqué par une zone fixe ? Conserver le chemin testé et le navigateur.
Erreurs compréhensibles
Les champs possèdent-ils des noms explicites et les erreurs indiquent-elles comment reprendre ? Compléter les tests automatiques par zoom et lecteur d’écran sur les parcours retenus.
OUTILS / REGISTRES
Informations à relever
Reproduire la tâche au clavier et avec une technologie d’assistance. Noter l’élément précis, le critère concerné et l’obstacle ; un outil automatisé seul ne conclut pas à la conformité.
- Date de consultation et fuseau
- URL exacte
- Tâche / étape du parcours
- Appareil / navigateur
- Critère de validation
- Résultat observé
- Décision / prochaine action
- Responsable du contrôle
- Prochain contrôle
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
Références officielles
Présenter un contexte
Passer du besoin à une prestation cadrée
Quelques interventions adaptées à ce sujet. Chaque montant correspond au périmètre de référence indiqué ; le devis confirme les priorités et les éventuels recouvrements.
Diagnostic d’accessibilité
Clavier, formulaires, contrastes et lisibilité ; plan de correction.
Gabarits : 3 · 6 h
À partir de 480 € HT / 576 € TTC
Préparation et critères de livraison
- À préparer
- Fournir les parcours prioritaires, les appareils visés et les erreurs réellement rencontrées.
- Déroulement proposé
- Définir des tâches, observer leurs obstacles puis refaire les mêmes contrôles après modification.
- Livraison à convenir
- Convenir d’un relevé des obstacles, de leur contexte et des corrections effectivement vérifiées.
- Contrôle de cette prestation
- Rejouer les contrôles convenus au clavier et documenter les éléments, critères et limites examinés.
- Limites du périmètre
- Un échantillon de pages ou de tâches ne permet pas de conclure sur tous les usages du site.
Base de travail indicative, à confirmer dans le devis.
Corrections mobile & responsive
Débordements, composants et interactions tactiles.
Gabarits : 3 · 4 h
À partir de 320 € HT / 384 € TTC
Préparation et critères de livraison
- À préparer
- Fournir les parcours prioritaires, les appareils visés et les erreurs réellement rencontrées.
- Déroulement proposé
- Définir des tâches, observer leurs obstacles puis refaire les mêmes contrôles après modification.
- Livraison à convenir
- Convenir d’un relevé des obstacles, de leur contexte et des corrections effectivement vérifiées.
- Contrôle de cette prestation
- Contrôler les largeurs retenues, les textes longs et l’absence de débordement sur les pages convenues.
- Limites du périmètre
- Un échantillon de pages ou de tâches ne permet pas de conclure sur tous les usages du site.
Base de travail indicative, à confirmer dans le devis.
CTA & conversion des formulaires
Promesse, libellés, erreurs et confirmation.
Parcours : 1 · 4 h
À partir de 320 € HT / 384 € TTC
Préparation et critères de livraison
- À préparer
- Fournir les parcours prioritaires, les appareils visés et les erreurs réellement rencontrées.
- Déroulement proposé
- Définir des tâches, observer leurs obstacles puis refaire les mêmes contrôles après modification.
- Livraison à convenir
- Convenir d’un relevé des obstacles, de leur contexte et des corrections effectivement vérifiées.
- Contrôle de cette prestation
- Tester une demande valide et une erreur, puis vérifier les consignes et la confirmation affichées.
- Limites du périmètre
- Un échantillon de pages ou de tâches ne permet pas de conclure sur tous les usages du site.
Base de travail indicative, à confirmer dans le devis.
Préparer et valider une prestation
Ces repères servent à cadrer la demande et à relire la livraison. Le devis fixe les éléments retenus, les volumes et le calendrier.
SXO, UX, accessibilité & performance
Illustration générée par IA
Réduire les obstacles rencontrés sur un parcours utile, notamment sur mobile et au clavier.
- À préparer
- Fournir les parcours prioritaires, les appareils visés et les erreurs réellement rencontrées.
- Déroulement proposé
- Définir des tâches, observer leurs obstacles puis refaire les mêmes contrôles après modification.
- Livraison à convenir
- Convenir d’un relevé des obstacles, de leur contexte et des corrections effectivement vérifiées.
- Limites du périmètre
- Un échantillon de pages ou de tâches ne permet pas de conclure sur tous les usages du site.
APPROFONDISSEMENT / PRATIQUE
Examiner les obstacles rencontrés dans un parcours
La qualité d’un dispositif web se vérifie sur des pages et des interactions réelles. Un contrôle doit expliquer le défaut, son effet pour le lecteur et la manière de reconnaître une correction satisfaisante.
Complément éditorial ajouté le .
Situation de départ
Un utilisateur peut lire une page mais ne pas atteindre son action principale. L’examen doit porter sur navigation, compréhension et interaction, dans plusieurs conditions d’usage.
Vérifications prioritaires
Parcourir les éléments au clavier, vérifier les intitulés et observer les messages de validation. Contrôler la visibilité du focus, l’ordre de lecture et l’accès aux informations indispensables.
Pièges d’interprétation
Un contrôle automatique ne couvre pas toute l’expérience. Une interface visuellement claire peut rester difficile à utiliser avec un clavier ou une technologie d’assistance.
Document de travail à conserver
Un relevé d’obstacles associe parcours, condition d’usage, étape bloquée et preuve. La correction doit être retestée dans la condition qui a permis d’identifier le problème.
Évaluer un parcours complet au clavier
Choisir une tâche réelle : trouver une information, ouvrir le menu, remplir un formulaire et comprendre sa confirmation. Parcourir toutes les étapes au clavier, vérifier la visibilité du focus et identifier les endroits où l’utilisateur ne peut plus avancer.
Les WCAG 2.2 proposent des critères vérifiables. Un contrôle automatique aide à repérer certains défauts, mais doit être complété par une vérification humaine du sens des intitulés, de l’ordre de lecture et des messages d’erreur.
CAS PRATIQUE / EXEMPLE PÉDAGOGIQUE
Une action existe mais reste inaccessible au clavier
L’exemple est une situation pédagogique de contrôle web. Il relie le défaut à un parcours concret et décrit une manière de vérifier la correction, plutôt que considérer la seule publication du changement comme une preuve de résolution.
Contexte de l’exemple
Une fenêtre permet de choisir une option avec la souris. Au clavier, le focus reste derrière le panneau et l’utilisateur ne peut pas atteindre la confirmation ou revenir au contenu.
Démarche proposée
Reproduire ouverture, navigation et fermeture au clavier. Examiner l’ordre de focus, les intitulés et les informations indispensables. Vérifier les parcours qui utilisent le même composant.
Conclusion et prochaine étape
Le défaut est décrit comme un obstacle à l’action. La recette confirme la possibilité d’entrer, de comprendre les options et de sortir du panneau sans perdre le parcours.
Liste de contrôle pour appliquer cet exemple
- Décrire le parcours et le résultat attendu avant la modification.
- Reproduire le défaut avec des conditions et contenus identifiables.
- Examiner les composants partagés et les pages qui en dépendent.
- Refaire le cas corrigé et conserver les limites de la recette.
Questions pour approfondir la pratique
Une interface sans erreur automatique peut-elle rester bloquante ?
Oui. Les contrôles automatiques détectent certains défauts, mais l’exécution des interactions reste nécessaire pour observer les obstacles de navigation, de compréhension ou de validation.
Comment choisir les pages à retester après une correction ?
Partir du composant ou de la règle modifiée, puis identifier les pages qui l’utilisent. Retester le cas initial et quelques variantes réellement différentes : contenu long, interaction, langue ou largeur. Le relevé indique les situations observées et celles qui restent hors du contrôle pour éviter de présenter une recette partielle comme une validation exhaustive.
Que conserver pour permettre à une autre personne de reproduire le défaut ?
Noter URL, étape, conditions utiles, résultat attendu et résultat obtenu. Un exemple de saisie non sensible ou une capture peut compléter le relevé. Préciser l’état du dispositif et les éventuelles étapes préparatoires facilite la reprise, surtout lorsque l’anomalie dépend d’un cache, d’une session ou d’une variante de contenu.
ATELIER DÉTAILLÉ / MISE EN APPLICATION
Reconstituer un parcours complet au clavier
Cet atelier propose une séquence en cinq étapes pour appliquer les repères de la page. Les entrées, les observations et la conclusion sont conservées ensemble afin de faciliter la vérification et la reprise du travail.
01 / Préparer les informations utiles
Choisir une interaction importante et définir son résultat attendu. Préparer les étapes d’ouverture, navigation, validation et retour au contenu, ainsi que les informations indispensables.
02 / Exécuter la démarche
Exécuter le parcours au clavier et relever les obstacles. Observer intitulés, ordre de focus et visibilité de l’élément actif. Vérifier les messages et la possibilité de corriger une erreur.
03 / Examiner une situation alternative
Si le parcours fonctionne seulement avec un détour non annoncé, conserver ce fait. Un contournement peut réduire l’impact sans remplacer une interaction compréhensible et directement utilisable.
04 / Décider de la suite
Le contrôle est satisfaisant lorsque l’action peut être réalisée et comprise dans la condition testée. Les autres modes d’usage restent un périmètre distinct à examiner.
05 / Transmettre les éléments de contrôle
Transmettre les étapes, commandes utilisées et résultats. Une correction est retestée depuis le début de l’interaction pour éviter de valider uniquement son élément final.
LIVRABLE COMMENTÉ / GRILLE DE LECTURE
Un relevé d’obstacles documenté par mode d’usage
Le relevé relie parcours, condition d’usage, étape et effet. Les preuves décrivent la possibilité de comprendre, naviguer, corriger et terminer l’interaction examinée.
Sur petit écran, faites défiler la grille pour lire les trois colonnes.
| Élément observé | Interprétation permise | Suite à prévoir |
|---|---|---|
| Le parcours clavier est réalisable et compréhensible. | L’usage est validé dans cette condition et sur les cas observés. | Examiner les autres composants et variantes importants du parcours. |
| Un contournement non annoncé permet l’action. | L’impact peut être réduit mais la difficulté de compréhension demeure. | Corriger le chemin principal et vérifier l’accès direct à la commande. |
| Le focus reste derrière un panneau ouvert. | L’utilisateur ne peut pas suivre normalement l’interaction au clavier. | Revoir ouverture, ordre de focus et sortie puis refaire le parcours. |
Relecture du livrable
La relecture évite de confondre réussite d’un outil automatique et qualité d’usage. Les étapes et commandes doivent permettre à une autre personne de reproduire l’obstacle et sa correction.
RESTITUTION / EXEMPLE DE FORMULATION
Restitution : Examiner les obstacles rencontrés dans un parcours
Point à clarifier
La réussite d’une interaction doit rester rattachée au mode d’usage testé.
Avant de transmettre
Conserver étapes, obstacles et contournements sans présenter un contrôle partiel comme exhaustif.
Exemple de conclusion qualifiée
Le parcours a été exécuté dans la condition décrite et permet l’action attendue. Les autres modes et variantes nécessitent leurs propres vérifications.