Un formulaire accessible doit permettre de comprendre la demande, de renseigner les champs, de corriger une erreur et de savoir si l’envoi a réussi. Pour repérer ce qui empêche vos visiteurs d’aller au bout, examinez toute cette séquence, avec ses états d’erreur et de confirmation.
Une baisse des demandes ou des inscriptions peut justifier cette investigation. Elle ne permet pas, à elle seule, d’en identifier la cause. Les contrôles d’accessibilité et l’observation des usages apportent des informations complémentaires, comme l’explique notre dossier accessibilité, expérience utilisateur et conversions.
Préparer un essai que votre équipe pourra reproduire
Choisissez une tâche précise : demander un devis, créer un compte ou terminer une inscription. Notez la page de départ, les étapes, le navigateur et l’appareil. Préparez un jeu de données fictives dans un environnement de test, pour éviter de créer de véritables commandes ou demandes.
Prévoyez trois passages : une saisie correcte, une saisie volontairement incomplète, puis une correction après erreur. Pour un formulaire en plusieurs étapes, ajoutez un retour à l’étape précédente. Ces scénarios rendent visibles des difficultés absentes de l’écran initial.
Les cinq vérifications à effectuer
1. Des champs dont on comprend toujours la fonction
Chaque champ doit avoir un nom explicite, relié correctement au composant. Un texte indicatif qui disparaît pendant la saisie ne remplace pas une étiquette. Vérifiez aussi les cases à cocher, les listes et les boutons : « Continuer vers le paiement » donne une information plus précise que « OK ».
À tester : commencez une saisie, puis revenez sur le champ. Son rôle reste-t-il compréhensible ? Avec un lecteur d’écran, son nom est-il annoncé ? Le tutoriel WAI sur les étiquettes décrit les associations à mettre en œuvre.
2. Un parcours utilisable au clavier
Parcourez le formulaire avec Tab et Maj+Tab. L’élément actif doit rester visible et l’ordre de déplacement doit permettre de comprendre et d’effectuer la tâche. Vérifiez que les listes, calendriers et fenêtres d’aide sont utilisables au clavier, puis qu’il est possible d’en sortir.
À tester : rejoignez le bouton d’envoi sans souris. Déclenchez ensuite une erreur ou affichez un nouveau champ. Le déplacement du focus reste-t-il cohérent après ce changement ? Les repères RGAA utiles comprennent notamment la visibilité du focus, critère 10.7, et l’ordre de tabulation, critère 12.8.
3. Des consignes données avant l’erreur et une aide pour la corriger
Signalez les champs obligatoires et les formats attendus avant la validation. Après une erreur, indiquez le champ concerné et la correction attendue. Une bordure rouge seule laisse l’utilisateur deviner ce qui ne va pas.
À tester : omettez un champ obligatoire et saisissez un format incorrect. Peut-on retrouver le problème, comprendre le message et modifier la bonne information ? Vérifiez que le message est accessible au lecteur d’écran et qu’il ne repose pas uniquement sur sa position visuelle.
Les recommandations WAI détaillent les consignes de saisie et les notifications d’erreur.
4. Une saisie que l’on peut reprendre
Une erreur sur un champ ne devrait pas obliger à remplir de nouveau toutes les informations ordinaires déjà saisies. Vérifiez la conservation prévue des données après validation incorrecte, changement d’étape et retour arrière. Certains champs sensibles suivent des règles particulières : leur comportement doit rester compréhensible.
À tester : remplissez plusieurs champs, provoquez une erreur sur le dernier, puis revenez en arrière. Notez les informations perdues et le travail à refaire. Cette vérification d’usage complète les tests du référentiel.
5. Une confirmation sans ambiguïté
Après traitement, l’utilisateur doit savoir si sa démarche a abouti et ce qui va suivre. Un changement de couleur du bouton ou un chargement interminable laisse un doute. Prévoir un message accessible de réussite et un retour compréhensible en cas d’échec facilite la fin du parcours.
À tester : vérifiez le message final, son annonce et la possibilité de le retrouver. Rapprochez cette confirmation de la réception effective par votre application : le clic sur « Envoyer » et l’enregistrement réussi sont deux événements distincts.
Quels indicateurs suivre pour localiser une difficulté ?
Les indicateurs ci-dessous constituent un plan de mesure à configurer et à vérifier. Leur disponibilité dépend de l’instrumentation du formulaire. Utilisez des événements de parcours et des catégories d’erreur, sans enregistrer le contenu des champs.
| Indicateur | Définition à retenir | Question à examiner |
|---|---|---|
| Démarrage | Première interaction pertinente avec le formulaire, définie dans le plan de mesure. | Les visiteurs qui accèdent à la page commencent-ils la démarche ? |
| Erreur de validation | Parcours ayant rencontré une erreur, par catégorie et par étape. | Une consigne ou un contrôle de saisie pose-t-il problème ? |
| Aboutissement | Enregistrement confirmé par l’application pour un parcours donné. | La démarche commencée a-t-elle réellement abouti ? |
| Taux d’aboutissement | Parcours aboutis divisés par parcours démarrés, selon une fenêtre d’observation définie. | Quelles étapes ou configurations méritent une investigation ? |
Gardez les mêmes définitions et évitez de compter plusieurs tentatives comme plusieurs personnes. Un écart peut venir de l’interface, de la performance, d’une règle métier ou de la qualité de la mesure. Ces données ne révèlent pas le handicap d’un visiteur.
Transformer le constat en correction vérifiable
Pour chaque problème, rédigez une fiche courte : tâche empêchée, étapes pour reproduire, état du formulaire, comportement observé, comportement attendu et test de validation. Ajoutez le critère RGAA concerné lorsqu’il est établi.
Exemple pédagogique : une date au format incorrect déclenche un message générique et efface les autres champs. La fiche demandera une consigne de format, un message associé à la date et la conservation des autres saisies. Le test final reprendra exactement cette erreur, puis la correction et l’envoi.
appYaccess aide à structurer les résultats des contrôles RGAA et à renouveler les vérifications sur les pages concernées. Les validations humaines complètent les tests qui le nécessitent. appYuser apporte le contexte des usages et de l’expérience réelle ; les événements métier du tableau doivent être définis et leur collecte vérifiée.
Après correction, rejouez les scénarios, puis observez des périodes et des contextes comparables. Une amélioration des indicateurs doit être interprétée avec les autres changements du site. Pour organiser plusieurs correctifs, utilisez notre méthode pour prioriser les corrections selon leur gravité et les usages réels.
Sources et repères techniques
- DINUM : critères et tests du RGAA, notamment formulaires et navigation.
- W3C WAI : concevoir des formulaires accessibles.
- W3C WAI : associer les étiquettes aux champs.
- W3C WAI : rendre les consignes de saisie accessibles.
- W3C WAI : notifier les erreurs et la réussite.
- W3C : comprendre l’ordre du focus.
- W3C WAI : organiser les formulaires en plusieurs étapes.
