Vous cliquez sur « Envoyer », mais le formulaire reste affiché. Une bordure rouge entoure le champ e-mail. L’adresse manque-t-elle, son format est-il incorrect ou le serveur a-t-il refusé la demande ? Pour le développeur, la validation se résume parfois à une valeur booléenne. Pour le visiteur, c’est toute sa démarche qui s’arrête.
Un message accessible ne se contente pas de signaler une erreur. Il précise le problème, indique le champ concerné et aide à le corriger. Cela demande une formulation claire, mais aussi une structure HTML adaptée et une gestion réfléchie du focus.
Commencer par les mots, pas par JavaScript
« Saisie incorrecte » renseigne peu. Si le champ est vide, demandez de saisir l’adresse ; si le format est incorrect, donnez un exemple. Les critères WCAG 2.2 3.3.1 et 3.3.3 traitent de l’identification textuelle des erreurs et des suggestions de correction lorsque cela convient. Une couleur seule ne suffit pas. Cet exemple ne constitue pas une déclaration de conformité globale.
Associer le message au champ concerné
Utilisons un libellé visible, des contraintes HTML natives et un élément d’erreur lié au champ par aria-describedby. Un seul champ suffit pour observer ce mécanisme.
<form id="contact" novalidate>
<label for="email">Adresse e-mail (obligatoire)</label>
<input id="email" name="email" type="email"
required aria-describedby="email-error">
<p id="email-error"></p>
<button type="submit">Envoyer</button>
</form>L’attribut required indique que le champ est obligatoire et type=email active la validation native du format. novalidate désactive les messages interactifs du navigateur à l’envoi : il faut donc prévoir une alternative accessible.
Exploiter ce que le navigateur sait déjà
L’API Constraint Validation permet de distinguer un champ obligatoire vide (valueMissing) d’une adresse mal formée (typeMismatch), sans inventer une expression régulière pour chaque cas.
const form = document.querySelector('#contact');
const email = document.querySelector('#email');
const error = document.querySelector('#email-error');
function validateEmail() {
const message = email.validity.valueMissing
? 'Saisissez votre adresse e-mail.'
: email.validity.typeMismatch
? 'Saisissez une adresse e-mail valide, par exemple nom@entreprise.fr.'
: '';
error.textContent = message;
if (message) email.setAttribute('aria-invalid', 'true');
else email.removeAttribute('aria-invalid');
return message === '';
}
form.addEventListener('submit', (event) => {
event.preventDefault();
if (!validateEmail()) {
email.focus();
return;
}
// Example ends here: implement server-side processing.
});
email.addEventListener('input', () => {
if (email.getAttribute('aria-invalid') === 'true') validateEmail();
});Ce code illustre la validation, mais ne transmet aucune donnée. Son utilisation des API a été comparée à la documentation ; aucune validation complète dans différents navigateurs ou lecteurs d’écran n’a été réalisée. Une saisie valide côté client ne prouve pas que le serveur a reçu la demande.
Quand afficher l’erreur ?
Signaler une erreur à chaque frappe peut gêner une personne qui commence tout juste à écrire. Ici, l’erreur apparaît à l’envoi et se met à jour pendant la correction d’un champ déjà signalé. Ce choix doit être testé avec les utilisateurs. Sur un formulaire long, un récapitulatif avec des liens vers les champs et une annonce adaptée aux technologies d’assistance peuvent être nécessaires.
Le navigateur ne protège pas le serveur
Les contrôles côté client peuvent être contournés. Validez également les données côté serveur. Si le traitement échoue, conservez les autres saisies valides et expliquez comment reprendre. N’affichez un succès qu’après acceptation par le serveur. Le W3C distingue les messages associés aux champs du retour global après l’envoi.
Vérifier que l’utilisateur peut reprendre sa démarche
Envoyez le formulaire vide, puis saisissez une adresse incorrecte et corrigez-la. Vérifiez la disparition du message et le comportement du focus. Recommencez au clavier, avec un zoom, sur écran étroit et avec un lecteur d’écran. Simulez aussi une erreur serveur et consignez les conditions de test. Une analyse automatique ne démontre pas à elle seule l’accessibilité du parcours.
Pour l’ensemble du parcours, consultez nos sept contrôles pour un formulaire accessible. Notre sponsor présente BlazeForce Forms et le traitement des envois (en anglais) ; ces principes restent valables pour toute extension.
Une erreur utile permet de terminer la tâche
Pour le logiciel, valider signifie appliquer une règle. Pour le visiteur, cela signifie comprendre le problème et pouvoir terminer sa demande. Faites de cette possibilité de correction un critère de livraison, plutôt que de considérer la bordure rouge comme une solution.
Sources
- W3C WAI — Validating Input
- W3C WAI — User Notifications
- WCAG 2.2 — Error Identification
- WCAG 2.2 — Error Suggestion
- MDN — Constraint Validation API
Contactez-nous
Dites-nous comment nous pouvons vous aider ; nous répondons sous deux jours ouvrés.
