Aria-invalid : messages d'erreur accessibles et RGAA 11.10

Votre formulaire rejette la saisie, le champ passe au rouge, et le lecteur d'écran n'annonce rien. Pour la personne qui ne voit pas ce rouge, l'erreur n'existe pas : elle soumet, échoue, recommence, abandonne. L'attribut aria-invalid est la première pièce de la solution. Une pièce seulement.

Ce guide couvre la chaîne complète d'un message d'erreur accessible : signaler l'état, relier le message au champ, le rédiger utilement, gérer le focus et le style, puis vérifier le tout au regard des critères RGAA 11.10 et 11.11.

Aria-invalid, c'est quoi exactement ?

L'attribut aria-invalid indique aux technologies d'assistance que la valeur saisie dans un champ de formulaire n'a pas passé la validation. Posé sur un input, un select ou un textarea, il déclenche l'annonce « non valide » par les lecteurs d'écran lorsque l'utilisateur atteint le champ.

Il accepte quatre valeurs, documentées par MDN :

Toute autre valeur est traitée comme true. En pratique, true couvre la quasi-totalité des cas de formulaire ; grammar et spelling concernent les zones de rédaction avec correcteur intégré.

Ce que le RGAA exige : critères 11.10 et 11.11

Le RGAA 4.1.2 (avril 2023) consacre deux critères au contrôle de saisie. Le critère RGAA 11.10 demande si « le contrôle de saisie est utilisé de manière pertinente » ; le critère RGAA 11.11 demande si ce contrôle est « accompagné, si nécessaire, de suggestions facilitant la correction des erreurs de saisie ». Ils correspondent aux critères WCAG 3.3.1 et 3.3.2 (niveau A) et au critère WCAG 3.3.3 (niveau AA).

Derrière ces deux questions, une chaîne d'obligations :

Deux points passent souvent inaperçus. D'abord, le message d'erreur doit être visible et identifier nommément le champ concerné : une couleur, une icône ou un « Erreur » générique ne satisfont aucun test (le rouge seul ne compte pas). Ensuite, quand un champ porte aria-invalid="true", le test 11.10.4 exige que le message soit situé dans l'étiquette ou dans un passage de texte relié au champ par aria-labelledby ou aria-describedby. Poser l'attribut crée donc une obligation de liaison : un aria-invalid orphelin, sans message relié, constitue une anomalie en audit.

La prévention en amont relève des critères voisins : étiquettes explicites (nous l'avons détaillé dans le guide des labels de champs de formulaire) et structure globale du formulaire (voir le guide complet des formulaires accessibles). Ideance a d'ailleurs recensé en juillet six mauvaises façons d'utiliser la balise label, du for/id rompu au label masqué en display:none.

Aria-describedby ou aria-errormessage : lequel relier au message ?

Deux attributs peuvent relier un message d'erreur à son champ, et la page 1 de Google ne les compare nulle part.

aria-errormessage est l'attribut sémantiquement dédié : il désigne explicitement un message d'erreur, et MDN le met en avant dans ses exemples. Il ne fonctionne que combiné à aria-invalid="true" : sans lui, les technologies d'assistance doivent l'ignorer.

aria-describedby est l'attribut généraliste de description, restitué de façon fiable par l'ensemble des combinaisons navigateur et lecteur d'écran. C'est aussi celui que cite la technique WCAG ARIA21 et que mentionnent les tests RGAA 11.10.4 et 11.10.7.

Notre recommandation de terrain : aria-describedby + aria-invalid reste la valeur sûre. La restitution d'aria-errormessage par les lecteurs d'écran demeure inégale selon les combinaisons, alors qu'aria-describedby est restitué partout et correspond mot pour mot à ce que le RGAA attend. Rien n'interdit de poser les deux, en gardant aria-describedby comme filet. Pour les subtilités de cet attribut (ordre de lecture, cumul d'identifiants), voir notre guide aria-describedby.

<label for="email">Adresse e-mail (obligatoire)</label>
<input type="email" id="email" name="email" required
       autocomplete="email"
       aria-invalid="true"
       aria-describedby="email-err">
<p id="email-err">
  Le champ Adresse e-mail doit contenir une adresse valide.
  Exemple : prenom.nom@exemple.fr
</p>

Ce bloc satisfait la chaîne complète : état signalé (aria-invalid), message visible qui nomme le champ (test 11.10.3), liaison programmatique (test 11.10.4), format et exemple de valeur (tests 11.11.1 et 11.11.2).

Voilà pour le câblage. Reste à écrire le message.

Écrire un message d'erreur utile : exemples avant et après

Le câblage ne sauve pas un message vide de sens. Nat Tarnoff le résume bien dans sa série sur l'identification des erreurs : la confusion nourrit la frustration, la frustration l'abandon. Un bon message répond à trois questions : quel champ, quel problème, quelle correction.

• Avant : « Erreur ». Après : « Le champ Adresse e-mail est obligatoire. »
• Avant : « Format invalide ». Après : « La date de naissance doit être au format JJ/MM/AAAA. Exemple : 03/07/1988. »
• Avant : « Saisie incorrecte ». Après : « Le numéro de téléphone doit comporter 10 chiffres, sans espaces ni points. Exemple : 0612345678. »

Trois règles de rédaction se dégagent :

• Nommer le champ dans le message, avec le même intitulé que son étiquette. « Le champ Code postal » et non « ce champ ».
• Donner le format et un exemple de valeur : c'est mot pour mot ce que demandent les tests 11.11.1 et 11.11.2.
• Rester honnête quand la suggestion est impossible. Un paiement refusé ou un identifiant inconnu ne se « suggèrent » pas sans créer un risque de sécurité : WCAG 3.3.3 prévoit explicitement cette exception. Dites ce que vous pouvez (« Vérifiez vos identifiants »), sans inventer une fausse précision.

Un mot sur la validation HTML5 native. Un input type="email" affiche de lui-même « Veuillez saisir une adresse e-mail valide », et la note technique du critère 11.11 confirme que ces messages, personnalisables via l'API Constraint Validation ou l'attribut pattern accompagné de title, valident le critère. Leur limite est ailleurs : la bulle native disparaît vite et sa restitution varie d'un navigateur à l'autre. Pour un formulaire à enjeu, un message inséré dans le DOM et relié au champ reste plus robuste.

Focus, annonce et style : gérer l'erreur de bout en bout

Où mettre le focus après la soumission ?

Avez-vous déjà cherché le champ fautif dans un formulaire de vingt champs ? Deux stratégies épargnent cette chasse à l'utilisateur. Pour un formulaire court, déplacez le focus vers le premier champ en erreur : l'utilisateur atterrit là où il doit agir, et la liaison aria-describedby fait annoncer le message. Pour un long formulaire, insérez en haut un résumé des erreurs (une liste de liens vers chaque champ concerné) et donnez-lui le focus.

Annoncer l'erreur sans en abuser

Un message inséré dynamiquement peut passer inaperçu. Un conteneur role="alert" (ou aria-live="assertive") force son annonce immédiate ; réservez-le au résumé global ou à l'erreur bloquante, sous peine de noyer l'utilisateur sous les annonces. Le fonctionnement précis est détaillé dans nos guides sur role="alert" et les messages de statut avec aria-live.

Styler aria-invalid en CSS : user-invalid plutôt que invalid

Deux sélecteurs fiables. [aria-invalid="true"] style exactement ce que les technologies d'assistance perçoivent : un seul état, une seule source de vérité. Et la pseudo-classe :user-invalid, largement disponible depuis novembre 2023, ne s'applique qu'après interaction de l'utilisateur, là où :invalid marque en rouge des champs encore intacts au chargement. Dans tous les cas, la couleur ne porte jamais l'information seule : le message texte reste obligatoire.

input[aria-invalid="true"],
input:user-invalid {
  border: 2px solid var(--couleur-erreur);
}

Ce qu'un scan automatique voit, et ce qu'il ne verra jamais

La chaîne du message d'erreur illustre bien la frontière de l'automatisation. Un scan comme celui de RGAA Checker détecte le câblage défaillant : un aria-invalid="true" sans aria-describedby, une liaison qui pointe vers un identifiant inexistant, un champ obligatoire sans indication visible ni required, une absence d'indication de format là où un motif l'exige.

Ce qu'aucun outil ne tranche seul, c'est la substance. « Erreur de saisie » bien relié à son champ passe tous les contrôles techniques et reste inutilisable. Dire si le message nomme le champ, décrit le problème et suggère une correction pertinente relève de la revue humaine : les tests 11.11.1 et 11.11.2 sont, par nature, une affaire de jugement. Le scan défriche et fiabilise le câblage ; l'audit humain tranche la formulation.

Conclusion

Un message d'erreur accessible tient en une chaîne courte : prévenir avant la saisie, signaler l'état avec aria-invalid, relier un message visible qui nomme le champ, suggérer la correction avec format et exemple. Chaque maillon correspond à un test précis des critères RGAA 11.10 et 11.11, et chaque maillon manquant se paie en abandons de formulaire.

Pour situer vos formulaires, lancez une analyse de votre page : elle repère les défauts de câblage (liaisons absentes ou rompues, indications manquantes) et vous laisse concentrer la revue humaine là où elle est irremplaçable, sur la formulation des messages. Et pour implémenter les autres composants ARIA sans faux pas, notre bibliothèque de patterns ARIA rassemble les implémentations de référence.