Identification des erreurs

Ce que le critère demande

Si une saisie de formulaire est invalide (mauvais format, valeur obligatoire manquante, valeur hors plage) et que le système le détecte automatiquement, l’erreur doit être identifiée à l’utilisateur par une description textuelle. Le texte doit indiquer quel champ est erroné et en quoi il l’est — pas seulement qu’« un problème » s’est produit.

Le critère n’exige pas que le système détecte toutes les erreurs possibles ; il exige que les erreurs détectées soient communiquées à l’utilisateur sous forme de texte.

Comment satisfaire ce critère

• Associer chaque champ de formulaire à un message d’erreur visible décrivant le problème, placé à côté ou en dessous du champ.
• Nommer le champ défaillant : « L’adresse e-mail doit contenir un symbole @ ».
• Relier l’erreur à la saisie avec aria-describedby afin que les lecteurs d’écran l’annoncent lors de la mise au focus.
• Utiliser aria-invalid="true" sur la saisie défaillante.
• Pour la validation côté serveur, afficher une liste récapitulative en haut du formulaire, chaque élément pointant vers le champ défaillant.
• Annoncer les messages de validation dynamiques via une région live (aria-live="polite" ou role="alert") pour que les lecteurs d’écran entendent l’erreur sans que l’utilisateur ait à la chercher.

Erreurs courantes

• Bordures rouges autour des champs invalides sans explication textuelle.
• Une bannière générique indiquant « Formulaire invalide » sans identifier les champs concernés.
• Messages d’erreur uniquement sous forme d’infobulle disparaissant lors de la perte de focus.
• Validation native du navigateur (required, pattern) utilisée seule — la bulle du navigateur n’est pas fiable pour les lecteurs d’écran et disparaît trop rapidement.
• Indicateurs d’erreur composés uniquement d’icônes (point d’exclamation rouge) sans nom accessible.

Pourquoi c’est important

Il s’agit de l’erreur d’assistance à la saisie la plus fréquemment citée dans les audits. Pour un utilisateur voyant, une bordure rouge est au moins un indice ; pour un utilisateur de lecteur d’écran, elle pourrait tout aussi bien ne pas exister. Pour les utilisateurs daltoniens, une bordure rouge seule ne transmet aucune information. Lorsqu’un utilisateur a rempli un long formulaire et que l’envoi échoue sans indication, il est probable qu’il abandonne — et l’accessibilité est la raison pour laquelle l’échec lui est spécifique.

Associer 3.3.1 avec 3.3.3 (Suggestion d’erreur) et 4.1.3 (Messages de statut) — ensemble, ils forment le modèle moderne de gestion des erreurs de formulaire.