Identification des erreurs

Silktide examine les champs de formulaire obligatoires qui semblent utiliser une validation personnalisée au lieu de la vérification intégrée 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

Quand un formulaire rejette une réponse invalide, les utilisateurs voyants voient habituellement un contour rouge ou un message près du champ. Un utilisateur de ne reçoit rien de tout ça à moins que la page n’expose l’erreur dans le code : le formulaire refuse simplement l’envoi, sans explication sur ce qui a mal tourné 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 cette fonction ou la remplace par sa propre validation et oublie de raccorder correctement ce remplacement aux .

Comment corriger

Donnez à chaque champ validé de façon personnalisée une liaison programmatique vers son message d’erreur, au moyen d’ :

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

N’importe laquelle des options suivantes satisfait la vérification :

aria-errormessage sur le champ, pointant vers l’élément que vous remplissez avec le texte d’erreur (définissez aria-invalid="true" quand 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.

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

Comment Silktide teste ceci

Repérer les champs requis visibles - champs de saisie, zones de texte et listes déroulantes marqués required ou aria-required="true".
Conserver seulement les champs pour lesquels on constate que la validation native du navigateur est contournée ou remplacée : le formulaire a novalidate, un contrôle de soumission a formnovalidate, le champ est marqué aria-invalid, il utilise aria-required sans l’attribut natif required, ou le champ ou le formulaire comporte des indices de validation personnalisée (p. ex., des attributs liés aux erreurs ou des conteneurs de messages d’erreur).
Pour chacun de ces champs, rechercher tout canal d’erreur accessible : une référence aria-errormessage valide, une référence aria-describedby valide, ou une région dynamique dans le formulaire.
Avertir pour les champs qui n’en ont aucun. 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 bien annoncées

La vérification recherche la structure qui rend les annonces possibles, pas l’annonce elle-même. Si votre cadriciel injecte une région dynamique ou les références ARIA seulement au moment où une erreur se produit, la page chargée ne présente aucun canal et le champ est signalé. Ajouter d’emblée l’élément de message (vide) et sa référence règle ce problème et est aussi 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 qui pointe vers un identifiant créé seulement plus tard est considéré comme l’absence de canal.