Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente (hors cas particuliers) ?
Un utilisateur aveugle remplit votre formulaire de contact. Il saisit tous les champs, valide, et rien ne se passe : son lecteur d’écran n’a jamais mentionné qu’un champ était obligatoire ni quel format était attendu. L’erreur existe, mais elle lui est invisible. C’est exactement ce que ce critère cherche à prévenir.
Le critère couvre deux situations. D’abord les champs obligatoires : chaque champ requis doit être signalé avant la soumission, soit par une indication visible identifiant ce champ (astérisque avec légende, mention « obligatoire »), soit par l’attribut required ou aria-required="true". Si vous utilisez l’attribut, l’indication visible doit aussi figurer dans l’étiquette ou le passage de texte associé. Les deux mécanismes se complètent.
Ensuite les messages d’erreur : quand un champ est mal renseigné ou vide, le message d’erreur doit soit identifier nommément le champ concerné, soit s’accompagner d’un aria-invalid="true" sur le champ. Dans ce second cas, le message d’erreur doit être placé dans l’étiquette ou le passage de texte associé — via aria-describedby le plus souvent.
Les instructions de format (format de date, nombre de caractères, pattern autorisé) doivent être visibles avant la validation — pas uniquement après une erreur. Ce point s’applique à tous les champs imposant un format précis, qu’ils soient obligatoires ou non.
7 tests pour s'assurer que les erreurs de saisie sont signalées
Indication visible ou attribut required sur les champs obligatoires
- Repérez tous les champs obligatoires du formulaire.
- Pour chaque champ, vérifiez qu’avant toute soumission, au moins une de ces conditions est remplie :
- Une indication visible (astérisque avec légende, mention « obligatoire », etc.) identifie clairement ce champ spécifique.
- Le champ porte l’attribut
requiredouaria-required="true".
- ✅ Validé si chaque champ obligatoire respecte au moins une de ces conditions avant la validation du formulaire.
Indication visible du caractère obligatoire dans l'étiquette
Ce test s’applique uniquement aux champs portant required ou aria-required="true".
- Repérez ces champs dans le formulaire.
- Pour chacun, vérifiez qu’une indication visible du caractère obligatoire est présente avant la soumission :
- soit dans le
<label>associé au champ, - soit dans un passage de texte lié via
aria-describedbyouaria-labelledby.
- soit dans le
- ✅ Validé si tous les champs avec
requiredouaria-required="true"ont une indication visible dans leur étiquette ou passage de texte associé.
Identification du champ en erreur ou attribut aria-invalid
- Soumettez le formulaire avec des champs obligatoires vides pour déclencher les messages d’erreur.
- Pour chaque message signalant un champ obligatoire non renseigné, vérifiez qu’au moins une de ces conditions est remplie :
- Le message est visible ET nomme explicitement le champ en erreur (ex. : « Le champ Email est obligatoire »).
- Le champ associé porte l’attribut
aria-invalid="true".
- ✅ Validé si chaque message d’erreur de champ obligatoire vide respecte au moins une de ces conditions.
Message d'erreur visible dans l'étiquette ou passage associé
Ce test s’applique uniquement aux champs portant aria-invalid="true".
- Repérez ces champs après soumission du formulaire.
- Pour chacun, vérifiez que le message d’erreur est visible et se trouve :
- soit dans le
<label>associé au champ, - soit dans un passage de texte lié via
aria-describedbyouaria-labelledby.
- soit dans le
- ✅ Validé si tous les champs avec
aria-invalid="true"ont leur message d’erreur dans l’étiquette ou le passage de texte associé.
Instruction de format visible avant validation
- Repérez tous les champs ayant un format ou type de données imposé (date, numéro de téléphone, code postal, mot de passe avec contraintes de longueur, etc.).
- Pour chacun, vérifiez que l’instruction de format est visible avant la soumission du formulaire :
- soit elle identifie nommément le champ (ex. : « Date de naissance : format JJ/MM/AAAA »),
- soit elle figure dans le
<label>ou dans un passage de texte lié viaaria-describedby.
- ✅ Validé si chaque champ avec format imposé expose une instruction visible avant validation.
Identification du champ ou aria-invalid pour les erreurs de format
- Soumettez le formulaire avec des données de format incorrect pour déclencher les messages d’erreur de format.
- Pour chaque message précisant le type de données ou le format attendu, vérifiez qu’au moins une de ces conditions est remplie :
- Le message est visible ET nomme explicitement le champ en erreur.
- Le champ associé porte l’attribut
aria-invalid="true".
- ✅ Validé si chaque message d’erreur de format respecte au moins une de ces conditions.
Instruction de format dans l'étiquette associée au champ aria-invalid
Ce test s’applique uniquement aux champs portant aria-invalid="true".
- Repérez ces champs après soumission avec des données invalides.
- Pour chacun, vérifiez qu’une instruction ou indication de format est visible et se trouve :
- soit dans le
<label>associé au champ, - soit dans un passage de texte lié via
aria-describedbyouaria-labelledby.
- soit dans le
- ✅ Validé si tous les champs avec
aria-invalid="true"exposent l’instruction de format dans leur étiquette ou passage de texte associé.
Exemples
❌ Non conforme : Champ obligatoire sans indication accessible
<label for="email">Email</label>
<input type="email" id="email" placeholder="Champ obligatoire">Deux problèmes cumulés. Le placeholder disparaît dès la première frappe : l’utilisateur ne peut plus relire l’indication en cours de saisie. Aucun required ni aria-required n’est présent, donc le lecteur d’écran ne signale rien de particulier. Un utilisateur de NVDA navigant au clavier entend uniquement « Email, champ de saisie » — sans la moindre indication d’obligation.
✅ Conforme : Champ obligatoire correctement signalé avec gestion d’erreur
<!-- Légende générale en haut du formulaire -->
<p>Les champs marqués d’un <span aria-hidden="true">*</span> sont obligatoires.</p>
<!-- État valide -->
<label for="email">Email <span aria-hidden="true">*</span></label>
<input type="email" id="email"
required
aria-required="true">
<!-- État invalide après soumission -->
<label for="email">Email <span aria-hidden="true">*</span></label>
<input type="email" id="email"
required
aria-required="true"
aria-invalid="true"
aria-describedby="email-erreur">
<p id="email-erreur" class="erreur">Le champ Email est obligatoire.</p>L’astérisque porte aria-hidden="true" pour éviter la redondance avec aria-required="true" déjà restitué par le lecteur d’écran. Après validation, aria-invalid="true" signale l’état invalide, et aria-describedby associe le message au champ. NVDA annonce : « Email, champ de saisie, invalide, obligatoire. Le champ Email est obligatoire. » — l’utilisateur sait exactement quoi corriger.
❌ Non conforme : Instruction de format absente avant validation
<label for="tel">Téléphone <span aria-hidden="true">*</span></label>
<input type="tel" id="tel" required aria-required="true">Aucune indication du format attendu. L’utilisateur ne sait pas s’il doit saisir 10 chiffres, inclure des espaces, ou ajouter l’indicatif pays. Il le découvrira uniquement après avoir soumis le formulaire et déclenché une erreur. C’est trop tard.
✅ Conforme : Instruction de format visible avant saisie et liée programmatiquement
<label for="tel">Téléphone <span aria-hidden="true">*</span></label>
<p id="tel-format">Format : 10 chiffres sans espaces (ex. : 0612345678)</p>
<input type="tel" id="tel"
required
aria-required="true"
aria-describedby="tel-format"
pattern="[0-9]{10}">L’instruction de format est visible avant toute frappe et liée programmatiquement via aria-describedby. Le lecteur d’écran la restitue au focus du champ. Aucun aller-retour erreur-correction n’est nécessaire pour comprendre ce qu’on attend — l’utilisateur part avec toutes les informations.
Astuces et pièges
⚠️ Le placeholder n’est pas une indication de format valide
C’est l’erreur la plus fréquente en audit. Le placeholder disparaît à la saisie, n’est pas restitué de manière fiable par tous les lecteurs d’écran, et n’est pas associé programmatiquement au champ comme une instruction. Une indication de format doit figurer dans le <label> ou dans un passage de texte lié via aria-describedby — pas dans le placeholder.
⚠️ aria-invalid="true" sans message d’erreur associé : moitié du travail
Ajouter aria-invalid="true" sur un champ en erreur est nécessaire, mais insuffisant. Le test 11.10.4 exige que le message d’erreur soit visible ET associé au champ via aria-describedby pointant vers l’élément contenant ce message. Sans cette association, l’utilisateur de lecteur d’écran sait que le champ est invalide, mais ne sait pas pourquoi.
💡 Astérisque et aria-required : les deux servent à des publics différents
L’astérisque avec légende s’adresse aux utilisateurs voyants. L’attribut required/aria-required="true" s’adresse aux technologies d’assistance. Pour éviter que le lecteur d’écran annonce « astérisque » en plus de « obligatoire », ajoutez aria-hidden="true" sur le <span> contenant le symbole. Les tests 11.10.1 et 11.10.2 vérifient les deux mécanismes séparément.
⚠️ Les instructions de format concernent aussi les champs facultatifs
Le critère 11.10 ne se limite pas aux champs obligatoires pour les questions de format. Si un champ optionnel impose un format précis (IBAN, code promotionnel à 8 caractères alphanumériques, numéro de sécurité sociale), l’instruction de format est requise avant validation. Dès qu’un format est imposé, l’utilisateur doit le connaître avant de soumettre.
⚠️ « Hors cas particuliers » : ce que ça couvre réellement
La mention « hors cas particuliers » dans l’intitulé du critère 11.10 vise les formulaires pour lesquels la validation côté client est délibérément absente — par exemple, un formulaire de test de validation strictement côté serveur. Si vous désactivez novalidate pour reprendre le contrôle de la validation native HTML5 et créer une validation JavaScript accessible, vous n’êtes pas dans ce cas d’exception.
💡 Désactiver la validation HTML5 native pour maîtriser l’expérience
Les bulles d’erreur natives des navigateurs (required, pattern, type="email") ont un rendu très variable et peuvent poser des problèmes d’accessibilité. Ajoutez novalidate sur le <form> et gérez la validation en JavaScript : vous gardez un contrôle total sur le placement, le style et l’association programmatique des messages d’erreur via aria-describedby.
Questions fréquentes
Quelle différence entre required et aria-required="true" pour l'accessibilité d'un formulaire RGAA ?
Non, les deux ensemble ne sont pas exigés par le RGAA — l’un ou l’autre suffit pour valider le test 11.10.1. En pratique, required (HTML5 natif) déclenche la validation native du navigateur et expose l’état obligatoire à l’accessibilité. aria-required="true" est utile sur des composants personnalisés qui ne supportent pas required. Sur un <input> standard, required seul est suffisant. Certaines équipes ajoutent les deux par habitude défensive — ce n’est pas une erreur, juste de la redondance bénigne.
Pourquoi le placeholder ne suffit pas à indiquer le format attendu dans un formulaire RGAA ?
Non, pas seul. Le placeholder disparaît dès que l’utilisateur commence à saisir, ce qui le rend inutile pour les personnes qui ont besoin de le consulter en cours de frappe. Il n’est pas restitué par tous les lecteurs d’écran de manière fiable. Le RGAA exige que l’instruction soit visible avant la validation : un placeholder n’est pas une indication visible persistante. Utilisez un élément <p> ou intégrez le format dans le <label>.
Comment auditer le test 11.10.4 du RGAA pour le contrôle de saisie en pratique ?
Soumettez le formulaire avec une valeur invalide dans un champ. Inspectez le DOM pour vérifier que ce champ a reçu aria-invalid="true". Cherchez ensuite le message d’erreur correspondant — il doit se trouver soit dans la balise <label> du champ (rare mais valide), soit dans un élément lié via aria-describedby. Si le message d’erreur est affiché dans un <div> sans lien programmatique avec le champ, le test échoue même si le message est visuellement proche.
Comment indiquer l'obligation de saisie quand tous les champs d'un formulaire RGAA sont requis ?
Oui. L’exception pour formulaire à champ unique ou champs optionnels explicitement marqués ne s’applique pas ici. Dès que tous les champs sont obligatoires, les tests 11.10.1 et 11.10.2 restent applicables. Chaque champ doit porter aria-required="true" ou required, et une indication visible doit figurer dans son étiquette ou dans un passage de texte associé.
Pourquoi la validation HTML5 native ne satisfait pas le critère RGAA 11.10 ?
Partiellement. La validation native via required, type="email", pattern, etc. couvre les tests 11.10.1 et 11.10.3 car elle expose l’état obligatoire et invalide aux technologies d’assistance. Mais les messages d’erreur natifs du navigateur ne sont pas sous votre contrôle : leur formulation, leur placement et leur accessibilité varient selon le navigateur. Si la présentation native pose problème ou si vous souhaitez personnaliser les messages, désactivez la validation native avec novalidate sur le <form> et implémentez votre propre système avec aria-invalid et aria-describedby.