Rédiger des erreurs de formulaire qui aident à corriger

Décrire la correction attendue

Associez chaque message au champ concerné et dites quelle donnée est attendue. « Adresse électronique incomplète » aide davantage qu’un code technique. N’attribuez pas à l’utilisateur une panne de serveur ou un service indisponible.

Écrivez les règles avant la saisie lorsque c’est possible : format, longueur, pièces admises ou informations facultatives. Le guide du formulaire de contact aide à limiter les champs et clarifier les attentes.

Le moment du contrôle fait partie du message. Un champ obligatoire encore vide à l’ouverture ne doit pas être annoncé comme fautif avant toute tentative d’envoi. Pendant la saisie d’une adresse, une valeur provisoire comme alex@ ne justifie pas nécessairement une alerte à chaque frappe. Selon le besoin, contrôlez à la sortie du champ ou après soumission ; un retour instantané peut rester utile pour une disponibilité vérifiée à distance.

aria-invalid indique qu’une valeur a échoué à une validation ; cet attribut ne définit pas les règles et ne bloque pas lui-même l’envoi. Associez l’état au message qui explique la correction, puis réévaluez-le après correction. Ne présentez pas un simple format d’adresse accepté comme une preuve de joignabilité. Une attente de vérification ou une panne du service doit garder son propre message.

• Champ et problème identifiables.
• Action de correction explicite.
• Contraintes annoncées assez tôt.

Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

Rendre le retour perceptible

Après soumission, affichez un résumé près du début du formulaire et un message auprès de chaque champ fautif. Placez le focus de manière prévisible et reliez chaque champ à son erreur pour les technologies d’assistance. La couleur seule ne suffit pas.

Le tutoriel W3C sur les notifications donne des exemples de messages locaux et globaux. Testez clavier, lecteur d’écran, zoom et petit écran.

Exemple fictif : un formulaire comporte les champs nom, adresse électronique et message. Le nom manque et l’adresse est incomplète ; le message est déjà valide. Le premier contrôle doit donc signaler 2 erreurs, pas 3. Après correction du seul nom, il reste 1 erreur ; après correction de l’adresse, il n’en reste aucune. À chaque étape, comparez les erreurs du résumé, les messages locaux et les valeurs conservées, sans obliger à retaper le message.

Dans ce contrat de test, chaque lien du résumé mène au champ concerné ; aria-describedby relie l’explication au contrôle et aria-invalid indique son état invalide. Après correction, retirez l’association à l’erreur devenue obsolète tout en conservant les aides encore utiles. Une panne du service après validation ne crée pas une nouvelle erreur de saisie et ne prouve aucun enregistrement. Le tableau distingue donc les 0 erreurs de champ d’une réussite réellement confirmée.

• Résumé et messages proches des champs.
• Association accessible des erreurs.
• Focus et contraste testés.

Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

• W3C WAI : User Notification

  W3C WAI, consulté le 22 octobre 2026 : notifications de formulaire. Les champs et étapes constituent un cas pédagogique fictif.

Préserver la saisie et l’intention

Conservez les valeurs déjà saisies après une erreur, sauf donnée sensible qui ne doit pas être réaffichée. Un formulaire long doit permettre de reprendre au bon endroit. Une pièce refusée exige une explication de format ou de taille.

Distinguez erreur de validation, délai réseau et double envoi. Évitez que des clics répétés créent plusieurs demandes ou commandes. La confirmation doit dire clairement si l’action a réellement été enregistrée.

• Champs valides conservés.
• Échecs réseau traités sans ambiguïté.
• Double soumission contrôlée.

Tester des cas réels

Essayez champ vide, caractère accentué, adresse mal saisie, fichier trop lourd, session expirée et serveur indisponible. Demandez à une personne extérieure de corriger le formulaire sans aide et observez les hésitations.

Après correction, contrôlez l’email ou l’étape suivante, pas seulement le message à l’écran. Les contenus de confirmation et d’erreur doivent aussi être revus dans chaque langue publiée.

• Cas d’erreur représentatifs couverts.
• Parcours complet vérifié.
• Messages traduits et relus.

Préserver la saisie après erreur

Cas proposé : une date invalide provoque l’effacement des autres champs. Le message précise le défaut mais oblige la personne à recommencer toute sa demande.

Déclenchez les erreurs attendues avec des valeurs fictives. Vérifiez conservation, association du message au champ et reprise ; la correction doit pouvoir se faire sans deviner une règle cachée.

• Déclencher une erreur attendue
• Vérifier les données conservées
• Terminer le parcours corrigé

• Vérifier la demande reçue

  Concevoir un formulaire de contact qui aide vraiment

Distinguer une correction d’un recommencement complet

Le rejet d’un champ ne doit pas effacer inutilement les réponses valides ailleurs dans le processus. Testez la réponse réelle du serveur puis revenez à l’étape précédente : conserver la saisie uniquement dans le navigateur ne suffit pas si une erreur serveur renvoie un formulaire vide.

Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

• W3C WAI · WCAG 3.3.7

  Lire la portée et les exceptions du critère ; ce scénario est une application pratique, pas un certificat de conformité.