Comment un enfant de douze ans comprend-il le message « Le format du champ est invalide » ? Assez mal, en réalité : lors d’une session d’observation menée avec cinq collégiens sur une plateforme e-learning destinée aux établissements scolaires, aucun n’a su expliquer ce que ce message attendait de lui.
Ce constat a motivé une checklist de tests spécifique pour les formulaires d’inscription et de rendu de devoirs de la plateforme, avec un objectif simple : chaque message de validation doit rester compréhensible sans vocabulaire technique, sans supposer une culture numérique déjà acquise.
Reformuler chaque message d’erreur en langage simple
La première étape de la checklist consiste à relire chaque message d’erreur du formulaire et à le confronter à une grille simple : un enfant de dix à quatorze ans comprendrait-il l’action attendue sans aide d’un adulte ? Les messages génériques de la validation HTML native, comme « Veuillez renseigner ce champ », passent ce test. D’autres, plus techniques, ont dû être réécrits.
- « Le format du champ est invalide » devient « Le code doit contenir 6 chiffres, par exemple 482913 »
- « Erreur de validation » devient « Il manque quelque chose : vérifiez le champ en rouge »
- « Champ requis » devient « N’oublie pas de remplir ce champ avant de continuer »
Cette réécriture a nécessité de dupliquer certains messages proposés par défaut par le navigateur, en les remplaçant par des messages personnalisés via l’attribut setCustomValidity côté JavaScript, plutôt que de dépendre du message générique du navigateur qui varie d’un appareil à l’autre.
Vérifier le positionnement visuel du message
Un message d’erreur techniquement clair mais mal positionné reste inefficace pour un jeune public qui ne fait pas encore le lien entre un texte rouge en haut de page et un champ précis plus bas dans le formulaire. La checklist vérifie donc que chaque message apparaît directement sous le champ concerné, avec une couleur suffisamment contrastée et un lien visuel explicite (bordure rouge sur le champ lui-même).
- Soumettre le formulaire avec un champ invalide et observer où le message apparaît
- Vérifier que le focus clavier se déplace automatiquement vers le premier champ en erreur
- Confirmer que le message reste visible sans défilement supplémentaire sur mobile
Le troisième point s’est révélé le plus problématique en pratique : sur un écran de smartphone d’entrée de gamme, souvent utilisé par les familles du public visé, le clavier virtuel masquait la moitié de l’écran et donc le message d’erreur affiché juste au-dessus du champ.
Tester avec un lecteur d’écran, même pour ce public
Certains élèves du public visé utilisent des aides techniques, notamment des lecteurs d’écran pour des troubles de la lecture. La checklist inclut donc un passage avec NVDA pour vérifier que chaque message d’erreur est bien annoncé au moment de sa apparition, via un attribut aria-live="polite" sur le conteneur de message.
Impliquer de vrais utilisateurs dans la recette
Au-delà des tests automatisés classiques, cette checklist inclut une étape que peu de suites de tests logicielles prévoient : une session d’observation avec de vrais élèves volontaires, encadrée par l’enseignant référent du projet. Cinq sessions de quinze minutes suffisent généralement à repérer les messages qui posent problème, bien plus efficacement qu’une relecture entre développeurs adultes.
Un message d’erreur technique clair pour un développeur n’est jamais une garantie qu’il soit clair pour l’utilisateur final, surtout quand cet utilisateur a douze ans.
Cette étape humaine complète, sans le remplacer, le test automatisé qui vérifie que chaque message respecte bien les règles de positionnement et de contraste définies plus haut dans la checklist.
Documenter la checklist pour les prochains formulaires
Chaque nouveau formulaire ajouté à la plateforme passe désormais par cette même checklist avant sa mise en production, consignée dans un document partagé avec l’équipe pédagogique cliente. Les points suivants s’appliquent systématiquement :
- Chaque message d’erreur relu par une personne extérieure au développement
- Chaque message positionné visuellement près du champ concerné
- Chaque parcours testé avec un lecteur d’écran au moins une fois par trimestre
Notre verdict
Cette checklist ne remplace pas les questions plus larges de conformité RGPD sur les données collectées auprès d’un public mineur, qui relèvent d’un tout autre travail juridique et technique. Elle répond à un besoin plus modeste mais tout aussi concret : s’assurer qu’un enfant qui se trompe dans un formulaire comprenne comment se corriger, sans frustration ni abandon du parcours d’inscription.
