Contrôle de saisie
Le contrôle de saisie regroupe les mécanismes qui aident l'utilisateur à remplir un formulaire sans erreur : signalement des champs obligatoires, indication du format attendu et messages d'erreur explicites quand la saisie échoue. Sans ces indications, un utilisateur de lecteur d'écran ne sait ni quoi remplir, ni ce qui a échoué.
Un utilisateur soumet un formulaire de contact. La page se recharge, une bordure rouge entoure le champ courriel. Aucun texte. Un utilisateur voyant devine le problème. Peut-être. Un utilisateur de lecteur d'écran ne perçoit rien du tout.
#Avant, pendant, après
Le contrôle de saisie ne se résume pas aux messages d'erreur. Le RGAA (critères 11.10 et 11.11) distingue trois moments :
Avant la saisie : signaler les champs obligatoires et le format attendu. Un astérisque seul ne suffit pas. Le texte « obligatoire » ou l'attribut aria-required="true" doit accompagner chaque champ concerné.
Pendant la saisie : si une validation en temps réel existe, elle doit être annoncée aux technologies d'assistance via aria-live ou un role="status".
Après la soumission : chaque champ en erreur est identifié et l'erreur décrite en texte. C'est l'exigence du critère WCAG 3.3.1 (niveau A). Le critère 3.3.3 (niveau AA) ajoute une obligation : si une suggestion de correction existe, elle doit être proposée. « L'adresse courriel doit contenir un @ » satisfait les deux critères. « Champ invalide » ne satisfait que le premier.
#Le trio technique
Trois attributs suffisent : aria-invalid, aria-describedby et un message texte visible.
<!-- ✅ Erreur identifiée et décrite -->
<label for="email">Courriel (obligatoire)</label>
<input id="email" type="email"
aria-invalid="true"
aria-describedby="email-erreur">
<p id="email-erreur" class="erreur">
L'adresse courriel doit contenir un @
</p>
<!-- ❌ Erreur invisible pour les lecteurs d'écran -->
<input type="email" style="border-color: red">Le lecteur d'écran annonce pour le premier champ : « Courriel, obligatoire, invalid entry, L'adresse courriel doit contenir un @ ». Le second ? Silence total.
Pourquoi aria-describedby plutôt que aria-errormessage ? Adrian Roselli a comparé les deux en détail : aria-describedby fonctionne dans toutes les combinaisons navigateur et lecteur d'écran testées. aria-errormessage reste mal supporté. La documentation MDN confirme cette prudence.
#La couleur ne suffit jamais
La bordure rouge est un indice visuel utile. Un daltonien ne la distingue pas de la bordure par défaut. Un utilisateur de lecteur d'écran ne la perçoit pas du tout. Le W3C l'exige : l'erreur doit être décrite en texte, pas seulement signalée par un changement visuel.
#En résumé
Signalez les champs obligatoires et le format attendu avant la saisie. Décrivez chaque erreur en texte, reliée au champ via aria-describedby. Ne comptez jamais sur la couleur seule.