300 millisecondes : c’est à peu près le délai qu’il faut laisser passer avant d’annoncer à un lecteur d’écran qu’un champ de formulaire vient d’être validé, sous peine de déclencher une rafale d’annonces contradictoires pendant que l’utilisateur corrige encore sa saisie. Ce réglage fin devient nécessaire dès qu’on active la validation en temps réel de Gravity Forms, activable champ par champ dans les réglages du formulaire, sans attendre la soumission complète : un champ de saisie peut afficher un message d’erreur dès que l’utilisateur quitte le champ, sans jamais passer par un rechargement ni un appel AJAX visible. Utile pour un utilisateur voyant, qui voit l’erreur apparaître immédiatement sous le champ concerné. Silencieux pour un utilisateur de lecteur d’écran, qui poursuit sa saisie sans être informé du problème tant qu’il ne revient pas explicitement sur le champ.
Ce défaut diffère de celui, plus connu, des messages d’erreur affichés uniquement à la soumission finale : ici, l’erreur existe bien plus tôt dans le parcours, ce qui devrait en théorie être un gain d’accessibilité, puisqu’elle est détectée avant que l’utilisateur n’ait avancé plus loin dans le formulaire. Sans annonce vocale, ce gain potentiel se transforme en angle mort supplémentaire.
Diagnostic : un message inséré sans région live
Gravity Forms insère le message de validation instantanée dans un élément portant la classe gfield_validation_message, généré dynamiquement en JavaScript au moment où le champ perd le focus. Comme pour de nombreux plugins de formulaire, ce conteneur ne porte par défaut aucun attribut aria-live ni role="alert", ce qui explique le silence complet côté lecteur d’écran malgré une mise à jour bien réelle du DOM.
Le cas de la validation en temps réel est plus délicat à corriger que celui d’un résumé global affiché après soumission, car il faut associer l’annonce spécifiquement au champ en cours de traitement, sans déclencher une annonce parasite sur des champs voisins qui ne sont pas concernés par la mise à jour.
Le correctif : une région live par champ, avec anti-rebond
La solution retenue sur nos projets consiste à observer les insertions du DOM avec un MutationObserver ciblé sur chaque conteneur de champ, plutôt que de modifier le plugin lui-même :
document.querySelectorAll('.gfield').forEach(function (champ) {
var conteneurMessage = champ.querySelector('.gfield_validation_message');
if (!conteneurMessage) return;
conteneurMessage.setAttribute('aria-live', 'polite');
conteneurMessage.setAttribute('role', 'status');
var minuteur;
var observateur = new MutationObserver(function () {
clearTimeout(minuteur);
minuteur = setTimeout(function () {
conteneurMessage.setAttribute('aria-live', 'off');
conteneurMessage.offsetHeight; // relance l'annonce
conteneurMessage.setAttribute('aria-live', 'polite');
}, 300);
});
observateur.observe(conteneurMessage, {
childList: true,
characterData: true,
subtree: true,
});
});Le délai de 300 millisecondes évite qu’une frappe rapide au clavier ne déclenche une rafale d’annonces contradictoires pendant que l’utilisateur corrige encore sa saisie ; l’annonce ne part qu’une fois la mise à jour du message stabilisée.
Pourquoi aria-live= »polite » plutôt qu’assertive ici
Contrairement à un message d’erreur bloquant affiché après soumission complète, la validation en temps réel intervient pendant que l’utilisateur est encore en train d’interagir avec le formulaire. Une annonce assertive interromprait potentiellement une lecture en cours de façon intrusive à chaque champ quitté, y compris pour des erreurs mineures. Le choix de polite respecte le flux de travail de l’utilisateur tout en garantissant que l’information finira par être annoncée dès que le lecteur d’écran atteint une pause naturelle.
Vérifier le comportement avant déploiement
- Tester avec NVDA sur un champ obligatoire laissé vide, en quittant le champ au clavier avec la touche Tabulation
- Vérifier qu’aucune annonce en double ne se produit si l’utilisateur revient plusieurs fois sur le même champ
- Confirmer que la correction n’interfère pas avec le message de succès affiché une fois le champ validé, qui doit lui aussi être annoncé
Ce que ce correctif ne traite pas
La validation côté serveur, déclenchée uniquement à la soumission finale du formulaire, reste un sujet distinct avec son propre mécanisme d’affichage chez Gravity Forms, généralement mieux couvert par défaut grâce au résumé d’erreurs global. Ce correctif se concentre uniquement sur l’angle mort spécifique de la validation instantanée au moment de la saisie, qui reste, sur les formulaires que nous auditons, le défaut le plus fréquemment ignoré.
