Identification des erreurs

Silktide examine les champs de formulaire obligatoires qui semblent utiliser une validation personnalisée plutôt que le contrôle intégré du navigateur, et avertit lorsqu’il n’existe aucun moyen apparent pour que le message d’erreur parvienne aux personnes utilisant des technologies d’assistance.

Pourquoi c’est important

Lorsqu’un formulaire rejette une réponse invalide, les utilisateurs voyants voient généralement un encadré rouge ou un message près du champ. Un utilisateur de ne reçoit rien de tout cela à moins que la page n’expose l’erreur dans le code : le formulaire refuse simplement d’être envoyé, sans explication sur ce qui s’est mal passé ni où. Le résultat est un formulaire qui exclut silencieusement certains visiteurs.

Les navigateurs annoncent automatiquement leurs propres messages de validation intégrés. Le risque apparaît lorsqu’une page désactive cela ou le remplace par sa propre validation, et oublie de raccorder ce remplacement aux .

Comment corriger

Donnez à chaque champ validé de façon personnalisée une voie programmatique pour son message d’erreur, en utilisant :

<!-- Problème : validation personnalisée sans canal d’erreur accessible -->
<form novalidate>
  <input type="text" required>
  <span class="error">Saisissez votre nom</span>
</form>

<!-- Correctif : le champ pointe vers son message d’erreur -->
<form novalidate>
  <input type="text" required aria-describedby="name-error">
  <span id="name-error" class="error">Saisissez votre nom</span>
</form>

N’importe laquelle de ces solutions satisfait le contrôle :

aria-errormessage sur le champ, pointant vers l’élément que vous remplissez avec le texte d’erreur (définissez aria-invalid=\"true\" lorsque l’erreur s’affiche).
aria-describedby sur le champ, pointant vers l’élément du message.
Une à l’intérieur du formulaire — un élément avec role=\"alert\", role=\"status\" ou aria-live — dans lequel votre validation écrit le texte d’erreur.

Sinon, supprimez la personnalisation et laissez la validation native du navigateur signaler les erreurs, ce qui est accessible par défaut.

Comment Silktide teste cela

Trouver les champs obligatoires visibles — zones de saisie, zones de texte et listes de sélection — marqués required ou aria-required=\"true\".
Ne conserver que les champs montrant que la validation native du navigateur est contournée ou remplacée : le formulaire a novalidate, un contrôle d’envoi a formnovalidate, le champ est marqué aria-invalid, il utilise aria-required sans l’attribut natif required, ou le champ/le formulaire comporte des indices de validation personnalisée (comme des attributs liés aux erreurs ou des conteneurs de messages d’erreur).
Pour chacun de ces champs, rechercher un canal d’erreur accessible : une référence aria-errormessage valide, une référence aria-describedby valide, ou une région en direct dans le formulaire.
Avertir pour les champs qui n’en ont pas. Il s’agit d’un avertissement plutôt que d’un échec confirmé, car le comportement de validation à l’exécution ne peut pas être entièrement observé à partir du code de la page.

Dépannage

Mes erreurs sont correctement annoncées

Ce contrôle recherche la structure qui rend les annonces possibles, pas l’annonce elle‑même. Si votre framework n’injecte une région en direct ou les références ARIA qu’au moment où une erreur survient, la page chargée ne montre aucun canal et le champ est signalé. Ajouter à l’avance l’élément de message (vide) et sa référence résout ce problème et est également plus robuste.

L’élément de message référencé n’existe pas encore

Les références doivent pointer vers des éléments qui existent dans la page. Un aria-describedby pointant vers un identifiant qui n’est créé que plus tard équivaut à l’absence de canal.