Cartographier le parcours
Listez origine, champs obligatoires, aides, pièces jointes, consentements, soumission, erreur, succès et éventuel message de suivi.
GUIDE / PROTOCOLE
Auditer un formulaire de bout en bout
Un formulaire fonctionne lorsque la personne comprend la demande, peut corriger ses erreurs et sait ce qui a été transmis.
Réponse directe
Que vérifier au-delà du bouton d’envoi ?
Parcourez chaque état du formulaire avec clavier et mobile. Vérifiez le besoin de chaque champ, la clarté des libellés, les erreurs, la validation côté serveur, la conservation des données et la confirmation effectivement reçue.
01 / Méthode de contrôle
Méthode de contrôle
Tester les saisies
Essayez valeurs valides, vides, longues, internationales et incorrectes ; vérifiez étiquettes, exemples, ordre de tabulation et absence de perte des données.
Vérifier la réponse serveur
Contrôlez la validation côté serveur, les erreurs ciblées, les doublons, les échecs réseau, la protection contre l’envoi répété et les délais.
Contrôler la suite
Vérifiez accusé de réception, destinataire fonctionnel, délai annoncé, données conservées et possibilité de reprendre sans ressaisir inutilement.
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.
Quel contrôle effectuer en premier ?
Choisissez la situation observée. Chaque piste précise une première vérification, la preuve utile et la limite de ce contrôle.
Le parcours fonctionne à la souris, pas au clavier
- Premier contrôle
- Reprenez une tâche avec Tab, Maj+Tab, Entrée et les touches attendues du composant. Suivez le focus : où entre-t-il, quel contrôle reçoit-il et peut-on sortir d’un menu ou d’un dialogue ?
- Preuve à conserver
- Étape, touche, contrôle actif, état ouvert ou fermé et point exact où le parcours se bloque ou devient incompréhensible.
- Limite à garder en tête
- Un ordre de focus cohérent ne certifie pas toute l’accessibilité. Le nom des contrôles, les états annoncés et la lecture du contenu doivent aussi être examinés.
Un formulaire refuse la saisie sans expliquer pourquoi
- Premier contrôle
- Provoquez une erreur sur un champ puis relisez son intitulé, son format attendu et le message associé. Vérifiez qu’une correction est possible sans perdre les autres valeurs utiles.
- Preuve à conserver
- Champ concerné, valeur d’essai non sensible, message, lien entre erreur et champ, comportement du focus et résultat après correction.
- Limite à garder en tête
- Un message visible ne garantit pas qu’il soit relié au champ ou annoncé au bon moment. Vérifiez également l’envoi, l’accusé de réception et le cas d’indisponibilité.
Le texte déborde ou devient difficile à lire
- Premier contrôle
- Réduisez la largeur, agrandissez le texte et reprenez la tâche. Repérez le composant qui force toute la page à défiler horizontalement ; distinguez-le d’un tableau qui exige ses deux dimensions.
- Preuve à conserver
- Largeur de fenêtre, niveau de zoom, langue, composant, texte masqué et besoin réel de défilement dans deux directions.
- Limite à garder en tête
- Une capture mobile isolée ne couvre pas tous les zooms, langues et états. Une exception de tableau ne justifie pas le débordement de toute la page.
Pour approfondir
| 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 parcours avec Tab, Maj+Tab et Entrée, puis à 200 % de zoom. Lors du défilement, vérifiez que l’en-tête fixe ne masque pas entièrement le contrôle qui reçoit le focus. Ouvrez et fermez le menu au clavier, provoquez une erreur de formulaire et vérifiez que vous pouvez la corriger. Notez la page, l’action et l’obstacle observé ; ces essais ciblés ne constituent pas une certification WCAG.
Références documentaires
Consulté le .
Atelier de lecture
La confirmation, le stockage et la livraison sont trois preuves
Le cas fictif DEMO-F22 suit un double envoi et un rafraîchissement sans transmettre de message réel.
Données et traces fictives pour apprendre : aucun résultat présenté ici ne provient d’un service interrogé en direct.
Un contrat de reprise explicite pour K1
L’application de démonstration prévoit que deux POST de même clé K1 et même contenu renvoient le reçu R1 sans créer deux dossiers. Ce comportement doit être vérifié séparément du statut HTTP.
Premier POST
- Observation du cas
- K1 ; réponse 303 vers /recu/R1
- Ce que cela établit
- Une redirection de confirmation est observée.
- Suite à donner
- Conserver méthode, réponse et identifiant non sensible.
Lecture puis rafraîchissement
- Observation du cas
- GET /recu/R1 ; 200 ; actualisation en GET
- Ce que cela établit
- Ce rafraîchissement ne rejoue pas le POST dans la séquence.
- Suite à donner
- Tester aussi un nouvel envoi, pas seulement cette page.
Deuxième POST identique
- Observation du cas
- K1 ; même contenu ; même reçu R1
- Ce que cela établit
- Le scénario respecte le contrat de regroupement.
- Suite à donner
- Comparer le journal de traitement ; une clé seule ne suffit pas.
États internes de démonstration
- Observation du cas
- 1 dossier stocké ; livraison en attente
- Ce que cela établit
- Le stockage est corroboré, la livraison ne l’est pas.
- Suite à donner
- Afficher « enregistré, livraison en attente » ; suivre la suite séparément.
Quelle conclusion est défendable ?
Ouvrir chaque proposition pour comparer son diagnostic. Plusieurs contrôles peuvent rester nécessaires.
303 prouve que le destinataire a reçu le message.
Non : le statut ne prouve ni stockage ni livraison.
Le rafraîchissement sûr prouve que tout double clic est traité.
Non : GET répété et second POST sont deux essais différents.
Un dossier stocké, reprise identique regroupée, livraison non confirmée.
Adapté au scénario. Un contenu différent avec la même clé demande un cas distinct selon le contrat.
Suivi de la reprise et du traitement
Cas : DEMO-F22 POST 1 : K1 → 303 → /recu/R1 GET puis rafraîchissement : /recu/R1 ; 200 POST 2 : K1 ; contenu identique ; reçu R1 Journal : un dossier stocké Livraison : en attente Bilan : stockage établi dans le cas, réception non établie
Relier reçu, journal de stockage et suivi de livraison par l’identifiant de test. Ne pas conserver le contenu personnel d’un formulaire dans l’URL ou la preuve publique.
Documentation des règles, distincte des exemples fictifs
02 / Preuves à conserver
Preuves à conserver
Matrice de cas
Entrées, état attendu, message affiché et résultat observé pour chaque cas.
Capture du parcours
Libellés, aides, focus, erreurs, résumé et confirmation sur mobile et clavier.
Journal technique expurgé
Statut de réponse, horodatage et identifiant de test sans conserver de données personnelles réelles.
Décision
Obstacle, impact sur la tâche, correction, responsable et nouveau test.
Comparer avec les autres situations et exercices
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 formulaire qui transmet les données lors d’un essai interne peut rester inutilisable pour une personne au clavier, sur mobile ou après une erreur de validation.
Contrôle décisif
Tester chaque étape avec de vraies contraintes de saisie : champs requis, messages d’erreur, conservation des valeurs, confirmation, lecture au clavier et état du service d’envoi.
APRÈS LE CONTRÔLE
Décider selon le constat
L’erreur est signalée mais les champs saisis disparaissent
Traitez la perte comme un échec du parcours. Préservez les valeurs non sensibles, placez le focus sur le résumé et retestez la correction.
La confirmation apparaît sans réception vérifiable
Ne considérez pas le parcours terminé. Vérifiez la réponse serveur et le traitement effectif avec une donnée fictive, puis corrigez le message.
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
Tester une saisie valide, les erreurs, le clavier, le mobile, la conservation des champs et la confirmation. La réussite de l’interface ne prouve pas la réception du message.
Décision suivante
Corriger la première rupture du parcours, puis refaire un envoi de bout en bout avec un destinataire de test autorisé. Suivre séparément accessibilité et délivrance.
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 message de succès ne prouve pas la réception
Ce qu’il faut examiner
Distinguer l’envoi par le navigateur, l’acceptation par le serveur et la réception dans le système destinataire. Utiliser un environnement et une destination de test autorisés pour suivre chaque étape.
Décision et action
Formuler le résultat au niveau réellement observé. Si seule l’acceptation est confirmée, ne pas annoncer une livraison démontrée ; rechercher l’étape manquante et un mécanisme de reprise adapté.
Preuve à conserver
Conserver les identifiants de test non sensibles, les heures et les états observés, sans recopier de secret ni de donnée personnelle inutile.
Une erreur efface les réponses déjà saisies
Ce qu’il faut examiner
Tester une validation refusée, une interruption réseau et un retour au formulaire. Vérifier les champs conservés, les messages associés et la possibilité de corriger puis de soumettre sans recommencer.
Décision et action
Restituer un état compréhensible et conserver les valeurs utiles selon leur sensibilité. Éviter de placer le contenu du formulaire dans une URL pour compenser une perte d’état.
Preuve à conserver
Garder la séquence, les champs affectés, le message affiché et le résultat du deuxième essai avec des valeurs de test.
Le rejet efface la saisie utile
Ce qu’il faut examiner
Tester une entrée invalide et vérifier erreurs, langue et champs conservés.
Décision et action
Préserver les données non sensibles utiles à la correction sans déclencher d’envoi réel.
Preuve à conserver
Entrée d’essai, rejet attendu, focus et possibilité de reprise.
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é.
Erreur puis reprise
Dans un environnement d’essai, une saisie invalide explique-t-elle le problème sans perdre les autres champs utiles ? Vérifier aussi clavier, langue et retour après échec serveur.
Voir une décision commentée
Exemple fictif : l’état concerne uniquement le critère et le périmètre décrits.
- Observation fictive
- Après une erreur sur l’adresse d’essai, le formulaire efface aussi le sujet et le message valides.
- État déclaré
- Écart observé
- Décision et prochain contrôle
- Préserver les saisies utiles et expliquer l’erreur du champ concerné. Rejouer la reprise avec des données fictives.
Envoi non dupliqué
Une double activation ou une réponse tardive peut-elle produire deux traitements ? Distinguer message de succès affiché, réception confirmée et traitement final, sans utiliser de données personnelles réelles.
Voir une décision commentée
Exemple fictif : l’état concerne uniquement le critère et le périmètre décrits.
- Observation fictive
- Le navigateur affiche un succès après deux activations ; le nombre de traitements côté serveur n’a pas été observé.
- État déclaré
- Non vérifié
- Décision et prochain contrôle
- Garder l’unicité non vérifiée. Dans l’environnement d’essai, relier l’identifiant de demande à la réception et au traitement final.
Validation côté serveur
Dans l’environnement d’essai, une requête invalide reste-t-elle refusée sans la validation du navigateur ? Un message côté client ne garantit pas le traitement serveur.
Documentation consultée : MDN · Constraint validation ·
Voir une décision commentée
Exemple fictif : l’état concerne uniquement le critère et le périmètre décrits.
- Observation fictive
- Une requête d’essai invalide est refusée par le serveur même sans contrôle du navigateur ; aucun traitement n’est créé.
- État déclaré
- Vérifié dans ce périmètre
- Décision et prochain contrôle
- Conserver entrée fictive, réponse et observation serveur. Refaire le test si la validation ou le traitement change.
OUTILS / REGISTRES
Informations à relever
Tester succès, erreur de saisie et échec serveur avec des données de test identifiées. Vérifier que le message annoncé correspond au résultat réel et que la saisie reste récupérable.
- Date de consultation et fuseau
- URL exacte
- Tâche / étape du parcours
- Appareil / navigateur
- Résultat attendu
- Résultat observé
- Critère de validation
- Décision / prochaine action
- Responsable du contrôle
- Prochain contrôle
03 / FAQ
Questions fréquentes
La validation JavaScript suffit-elle ?
Non. Elle améliore le retour immédiat, mais la validation doit aussi être effectuée côté serveur.
Faut-il marquer les champs obligatoires ?
Oui, de façon compréhensible avant la saisie et dans le message d’erreur.
Que faire après une erreur ?
Expliquer quoi corriger, associer le message au champ et conserver autant que possible les autres valeurs.
Comment tester sans données sensibles ?
Employez des cas fictifs et vérifiez les journaux avec des informations minimisées.
Comment tester sans envoyer de vraies demandes ?
Prévoir un environnement ou un canal de test approprié et des données fictives. La méthode doit néanmoins permettre de vérifier les étapes réelles qui conditionnent la réception et le traitement.
04 / Références officielles
Références officielles
Présenter un contexte
REPÈRES DOCUMENTÉS
Autoremplissage : lire les jetons dans leur ordre
Deux adresses d’un même formulaire peuvent attendre des valeurs différentes malgré des champs portant le même nom. autocomplete décrit une finalité et un groupe de champs ; il ne remplace ni le libellé visible ni la validation. Les exemples ci-dessous sont des cas de lecture de la grammaire HTML, pas des identités ou des coordonnées collectées.
| Repère | Valeur ou forme | Ce que cela désigne |
|---|---|---|
| section-* | 1 | Le préfixe section- vient en premier. Sa valeur distingue un groupe ; le navigateur ne doit pas lui attribuer une relation familiale ou une signification métier. |
| shipping | billing | 2 | shipping ou billing précise la destination des coordonnées. Ces deux jetons ne se cumulent pas dans la même liste. |
| home | work | mobile | fax | pager | 3 | home, work, mobile, fax ou pager peut précéder un champ de contact, par exemple email ou tel-national. work postal-code ne suit pas cette grammaire. |
| name | postal-code | email | … | 4 | Un jeton de finalité est nécessaire dans une liste détaillée. address-line1 address-line2 ne décrit pas deux champs : il en fournit deux là où un seul est attendu. |
| webauthn | 5 | webauthn, placé à la fin, peut signaler des identifiants à clé publique avec médiation conditionnelle. L’attribut seul ne met pas en place une authentification. |
| on | off | single token | on et off, employés seuls sur un champ visible concerné, sont des modes généraux ; ils ne précisent pas sa finalité. Ils ne sont pas autorisés comme tels sur input type=hidden. |
Lire 16 exemples de jetons
Ces exemples concernent des champs visibles de type indiqué. Ils isolent la grammaire : ni remplissage automatique ni authentification ne sont exécutés.
<input type="text" autocomplete="section-primary shipping work email">
Liste détaillée ordonnée · Groupe, destination, contact puis finalité : ordre de l’exemple ACT publié.
| Attribut autocomplete | Type du champ | Lecture | Interprétation |
|---|---|---|---|
| section-primary shipping work email | text | Liste détaillée ordonnée | Groupe, destination, contact puis finalité : ordre de l’exemple ACT publié. |
| section-blue shipping postal-code | text | Liste détaillée ordonnée | Deux groupes nommés peuvent séparer deux adresses de livraison sans changer la finalité postal-code. |
| section-red shipping postal-code | text | Liste détaillée ordonnée | Deux groupes nommés peuvent séparer deux adresses de livraison sans changer la finalité postal-code. |
| billing postal-code | text | Liste détaillée ordonnée | Une destination et une finalité, sans groupe de section obligatoire. |
| mobile tel-national | tel | Liste détaillée ordonnée | Le modificateur de contact précède une finalité téléphonique. |
| current-password webauthn | password | Liste détaillée ordonnée | Exemple ACT : finalité de mot de passe, puis jeton de justificatif à clé publique. |
| given-name | text | Liste détaillée ordonnée | Une finalité suffit ; les préfixes sont facultatifs. |
| on | text | Mode général | Mode général sans finalité détaillée ; la règle ACT 73f2c2 exclut ce cas de son champ. |
| off | text | Mode général | Mode général sans finalité détaillée ; la règle ACT 73f2c2 exclut ce cas de son champ. |
| work shipping email | Liste incorrecte | Le modificateur de contact est placé avant la destination : ordre incorrect. | |
| work,email | Liste incorrecte | Une virgule ne sépare pas les jetons HTML de cette liste. | |
| address-line1 address-line2 | text | Liste incorrecte | Deux finalités distinctes occupent la place d’une seule. |
| shipping | text | Liste incorrecte | La destination seule ne fournit aucune finalité. |
| work photo | text | Liste incorrecte | work ne peut pas modifier photo : ce n’est pas un champ de contact. |
| email invalid | Liste incorrecte | Le jeton supplémentaire invalid n’est pas autorisé après la liste. | |
| current-password webauthn invalid | password | Liste incorrecte | Le jeton supplémentaire invalid n’est pas autorisé après la liste. |
À retenir pour le dossier
Une liste correctement ordonnée ne prouve pas que la finalité correspond au champ, que le remplissage aura lieu ou que le formulaire satisfait WCAG 1.3.5. Ce critère vise certaines informations sur l’utilisateur et dépend des technologies employées. Les exemples n’évaluent pas un formulaire externe.
Documentation primaire
Documentation consultée le .
Vérifications complémentaires
APPROFONDISSEMENT / PRATIQUE
Tester les formulaires avec des cas réalistes
Un formulaire s’affiche normalement mais refuse une saisie légitime ou confirme un envoi qui n’aboutit pas. La recette distingue qualité de saisie, validation et traitement final.
Mis à jour le .
Vérifications prioritaires
Tester champs obligatoires, formats, longueur, erreurs, consentement et double soumission. Utiliser des données de test et contrôler le résultat réel sans transmettre de contenu confidentiel.
Pièges d’interprétation
Un bouton actif ou un message de succès ne suffit pas à démontrer l’achèvement du traitement. Les cas d’expiration de session et d’indisponibilité doivent aussi rester compréhensibles.
Document de travail à conserver
Le cahier de recette conserve données de test non sensibles, étape, résultat attendu et résultat observé. Chaque correction est accompagnée d’un contrôle du parcours complet.