Trois pixels de bordure rouge autour d’un champ : c’est souvent tout ce qui distingue visuellement un champ en erreur d’un champ valide sur un formulaire mal outillé. En mode contraste élevé, activé par de nombreux utilisateurs malvoyants directement au niveau du système d’exploitation, cette bordure perd sa teinte spécifique, remplacée par les couleurs du thème système. Sans autre indicateur, le champ redevient visuellement identique à ses voisins valides, alors que l’erreur, elle, persiste.
Ce que fait exactement aria-invalid
aria-invalid est un attribut d’état qui indique qu’une valeur saisie ne correspond pas au format attendu. Il accepte les valeurs true, false, ainsi que grammar et spelling pour des cas plus spécifiques de vérification grammaticale ou orthographique, rarement utilisés en dehors d’éditeurs de texte enrichi. Sur un champ de formulaire classique, seules true et false s’appliquent en pratique. Posé à true, l’attribut fait annoncer par le lecteur d’écran un état invalide au moment où le focus atteint le champ, indépendamment de toute couleur de bordure, ce qui rend l’information disponible même en mode contraste élevé ou pour un utilisateur qui n’a jamais perçu la couleur en question.
Le couplage indispensable avec aria-describedby
aria-invalid seul indique qu’il y a un problème, mais ne dit rien de sa nature. Le message qui explique l’erreur, souvent affiché sous le champ, doit être relié par aria-describedby pour que le lecteur d’écran l’annonce à la suite de l’état invalide. Sans ce lien, l’utilisateur apprend que le champ est invalide, sans jamais savoir pourquoi ni comment corriger la saisie, ce qui laisse le problème identifié mais pas résolu du point de vue de l’expérience.
Comportement réel et cas limites
Un cas limite fréquent concerne le moment où l’attribut est posé : si aria-invalid= »true » est présent dès le chargement initial du formulaire, avant toute tentative de saisie, un lecteur d’écran annonce une erreur sur un champ que l’utilisateur n’a même pas encore rempli, ce qui est trompeur. L’attribut doit apparaître uniquement après une tentative de validation échouée, jamais par défaut. Un autre cas limite touche à la suppression de l’attribut : dès que l’utilisateur corrige le champ et que la validation repasse au vert, aria-invalid doit repasser à false (ou être retiré), sans quoi l’annonce d’erreur reste collée au champ malgré la correction effective.
Mise en œuvre avec code
<label for="code-postal">Code postal</label>
<input type="text" id="code-postal" name="code-postal"
aria-invalid="true"
aria-describedby="code-postal-erreur">
<p id="code-postal-erreur">
Le code postal doit contenir exactement cinq chiffres.
</p>
<script>
const champ = document.getElementById('code-postal');
champ.addEventListener('input', () => {
const valide = /^d{5}$/.test(champ.value);
champ.setAttribute('aria-invalid', String(!valide));
});
</script>Le message d’erreur reste dans le DOM en permanence dans cet exemple, ce qui simplifie la logique : seul l’attribut aria-invalid change selon le résultat de la validation, sans avoir à insérer et retirer le paragraphe d’erreur à chaque frappe.
Pièges fréquents
- Poser aria-invalid uniquement en CSS via un sélecteur d’attribut pour styliser la bordure, sans jamais le faire porter réellement l’information sémantique attendue côté technologies d’assistance.
- Référencer dans aria-describedby un identifiant qui ne correspond à aucun élément existant dans le DOM, ce qui rend le lien silencieusement inopérant sans erreur visible.
- Laisser aria-invalid= »true » en permanence sur des champs facultatifs jamais remplis, faussant l’expérience de tout utilisateur qui commence la navigation par tabulation.
- Confondre ce couplage avec la validation elle-même : aria-invalid signale un résultat, il ne détermine jamais la règle de validation qui produit ce résultat.
Une bordure rouge parle à qui voit et perçoit le rouge ; aria-invalid parle à tout le monde, à condition d’être posé au bon moment et retiré dès que l’erreur est résolue.
Ce que cet attribut ne remplace pas
aria-invalid ne remplace jamais la logique de validation qui détermine si un champ est effectivement conforme ou non, que cette logique s’exécute en JavaScript côté client pour un retour immédiat, ou en PHP côté serveur au moment du traitement final du formulaire. L’attribut se contente de refléter le résultat de cette validation dans l’arbre d’accessibilité, il n’en constitue jamais la source.
Conclusion
Le couplage aria-invalid et aria-describedby coûte deux attributs et une ligne de mise à jour dans un gestionnaire d’événement existant, pour un gain direct sur la fiabilité d’un formulaire dont l’indication d’erreur ne reposerait sinon que sur une couleur de bordure fragile face au contraste élevé.
