Message d'erreur de formulaire accessible : identifier, expliquer, corriger

Ce qu'exige un message d'erreur de formulaire accessible (WCAG 3.3.1)

Le critère 3.3.1 « Identification des erreurs » (Error Identification) s'applique lorsqu'une erreur de saisie est détectée automatiquement : l'élément en erreur doit être identifié et l'erreur doit être décrite à l'utilisateur sous forme de texte. L'objectif, selon le W3C, est que l'utilisateur sache qu'une erreur existe et ce qui ne va pas.

Le W3C cite notamment deux cas d'erreurs de saisie : une information exigée par la page mais omise par l'utilisateur, et une information fournie mais qui sort du format de données requis ou des valeurs autorisées. Les exemples donnés sont parlants : une abréviation d'État, de province ou de région incorrecte, un code postal inexistant, une date de naissance située deux ans dans le futur, des lettres ou des parenthèses saisies dans un champ téléphone qui n'accepte que des chiffres, ou une enchère inférieure à l'enchère précédente.

Un cas souvent oublié : si la page corrige automatiquement une valeur trop haute ou trop basse pour la ramener dans la plage autorisée, l'erreur doit tout de même être décrite à l'utilisateur. Un message qui l'informe de la valeur modifiée satisfait à la fois 3.3.1 et 3.3.3.

La couleur, une icône ou une image restent autorisées, mais seulement en complément du texte. Le critère n'impose pas non plus d'emplacement : liste des erreurs en tête de formulaire, message en ligne à côté de chaque champ, alerte ou boîte de dialogue. La seule exigence est que les erreurs soient présentées en texte ou via une alternative textuelle.

• Nommer le champ en erreur dans le message (par exemple « Adresse e-mail »).
• Décrire la nature de l'erreur : champ obligatoire vide, format incorrect, valeur hors liste.
• Ne jamais se reposer uniquement sur la couleur rouge ou une icône.
• Signaler aussi les corrections automatiques faites par la page.

Suggérer la correction : le critère 3.3.3

Le critère 3.3.3 « Suggestion après une erreur » (Error Suggestion) (niveau AA) va plus loin : si une erreur de saisie est détectée automatiquement et que des suggestions de correction sont connues, elles doivent être fournies à l'utilisateur, sauf si cela compromet la sécurité ou l'objectif du contenu. Le W3C rappelle que savoir qu'une erreur existe ne suffit pas toujours : des personnes ayant des limitations cognitives peuvent avoir du mal à comprendre comment la corriger, et un utilisateur incertain peut abandonner le formulaire.

L'exemple du W3C pour 3.3.1 et 3.3.3 est un bon modèle de rédaction. « Email is not valid » (l'e-mail n'est pas valide) satisfait 3.3.1. « Please provide a valid email address in the format [email protected] » (indiquez une adresse e-mail valide au format [email protected]) indique en plus comment corriger, et satisfait les deux critères.

Autre exemple tiré de la documentation : un champ attend un nom de mois et l'utilisateur saisit « 12 ». La correction peut prendre la forme de la liste des valeurs acceptées (« Choisissez parmi : janvier, février… décembre ») ou d'une interprétation de la saisie (« Voulez-vous dire décembre ? »). Le W3C décrit aussi le cas d'un formulaire non envoyé qui affiche l'erreur à l'endroit concerné, avec la saisie correcte attendue et une aide supplémentaire pour le champ.

• Format attendu : donnez un exemple concret ([email protected], jj/mm/aaaa).
• Liste fermée : rappelez les valeurs autorisées ou proposez la plus probable.
• Exception : ne suggérez rien qui compromettrait la sécurité ou l'objectif du contenu.

Prévenir l'erreur avec des étiquettes et instructions (3.3.2)

Le meilleur message d'erreur est celui que l'on n'affiche pas. Le critère 3.3.2 « Étiquettes ou instructions » (Labels or Instructions) (niveau A) demande que des étiquettes ou des instructions soient fournies lorsque le contenu requiert une saisie de l'utilisateur. Le mot « requiert » ne vise pas que les champs obligatoires : le critère s'applique à tous les champs, obligatoires ou facultatifs. Il ne s'applique pas aux liens ni aux autres contrôles sans lien avec une saisie de données, comme un widget déplier/replier.

Pour les boutons radio, cases à cocher et listes de choix, chaque option a besoin de sa propre étiquette. Si les étiquettes des options suffisent à indiquer le rôle du groupe, une étiquette visible pour le groupe n'est pas forcément nécessaire ; sinon, il faut fournir une étiquette, une légende ou des instructions pour l'ensemble. Les instructions peuvent préciser le format attendu, en particulier s'il est inhabituel ou soumis à des règles spécifiques de saisie. Le W3C met aussi en garde contre l'excès : trop d'informations peut être aussi nuisible que trop peu. Les instructions peuvent n'apparaître qu'au focus du champ, ou être accessibles via un lien, notamment lorsqu'elles sont longues.

Attention au périmètre : 3.3.2 n'exige pas que l'étiquette soit correctement balisée et associée au champ, ce point relève du critère 1.3.1. À l'inverse, un champ peut avoir un nom accessible via aria-label et passer le critère 4.1.2, tout en échouant à 3.3.2 si l'étiquette n'est présentée qu'aux utilisateurs de technologies d'assistance. La clarté de l'étiquette relève, elle, du critère 2.4.6.

• Un champ date avec le format attendu indiqué en texte (jj/mm/aaaa ou mm/jj/aaaa).
• Un champ identifiant accompagné des règles sur les caractères autorisés.
• Deux champs « Prénom » et « Nom de famille » plutôt qu'une seule étiquette « Nom » pour deux champs.
• Un champ de recherche dont l'icône loupe sert d'étiquette visible.

<!-- Étiquette associée (H44), champ obligatoire indiqué dans le label (H90)
     et format attendu avec exemple (G89) -->
<label for="date-naissance">Date de naissance (obligatoire)</label>
<p id="date-aide">Format attendu : jj/mm/aaaa, par exemple 14/07/1990</p>
<input type="text" id="date-naissance" name="date-naissance"
       aria-describedby="date-aide" aria-required="true">

<!-- Groupe de champs : fieldset et legend (H71),
     avec une étiquette visible pour chaque sous-champ (H44) -->
<fieldset>
  <legend>Adresse</legend>
  <label for="code-postal">Code postal</label>
  <input type="text" id="code-postal" name="code-postal">
  <label for="ville">Ville</label>
  <input type="text" id="ville" name="ville">
</fieldset>

Annoncer l'erreur au lecteur d'écran : les techniques du W3C

Le critère 3.3.1 n'exige pas d'information programmatique : un texte, ou une alternative textuelle, qui identifie le champ et décrit l'erreur suffit à le satisfaire. Le W3C indique toutefois que l'identification de l'erreur peut être combinée à des informations exploitables par les navigateurs et les technologies d'assistance, un aspect qui peut relever d'autres critères comme 4.1.2 « Nom, rôle et valeur » (Name, Role, Value). Parmi les techniques suffisantes listées pour 3.3.1, classées selon la situation, figurent ARIA21 « Utiliser aria-invalid pour indiquer un champ en erreur » pour les champs obligatoires non remplis, ainsi que ARIA19 « Utiliser role=alert ou des régions live pour identifier les erreurs », ARIA18 « Utiliser aria-alertdialog pour identifier les erreurs » et SCR32 « Validation côté client avec ajout du texte d'erreur dans le DOM » pour les saisies hors du format ou des valeurs autorisées.

Une mise en œuvre possible combine un message rattaché au champ par aria-describedby, un attribut aria-invalid sur le champ fautif et un récapitulatif dans une zone role="alert". Le W3C propose aussi, en technique conseillée, G139 « Créer un mécanisme permettant d'accéder directement aux erreurs », que vous pouvez réaliser avec des liens vers chaque champ dans le récapitulatif, ainsi que G199 « Confirmer le succès de l'envoi des données ».

<form id="inscription" novalidate>
  <div id="recap-erreurs" role="alert"></div>

  <label for="email">Adresse e-mail (obligatoire)</label>
  <input type="email" id="email" name="email" aria-describedby="email-erreur">
  <p id="email-erreur" hidden></p>

  <button type="submit">Créer mon compte</button>
</form>

<script>
  const form = document.getElementById('inscription');
  form.addEventListener('submit', (e) => {
    const champ = document.getElementById('email');
    const msg = document.getElementById('email-erreur');
    const recap = document.getElementById('recap-erreurs');
    // Remise à zéro avant chaque contrôle
    msg.textContent = '';
    msg.hidden = true;
    recap.innerHTML = '';
    champ.removeAttribute('aria-invalid');

    let erreur = '';
    if (!champ.value.trim()) {
      erreur = 'Adresse e-mail : ce champ est obligatoire.';
    } else if (!/^[^@\s]+@[^@\s]+\.[^@\s]+$/.test(champ.value)) {
      erreur = 'Adresse e-mail : format non valide. Saisissez une adresse au format [email protected].';
    }
    if (erreur) {
      e.preventDefault();
      msg.textContent = erreur;
      msg.hidden = false;
      champ.setAttribute('aria-invalid', 'true');
      recap.innerHTML = '<p>1 erreur : <a href="#email">Adresse e-mail</a></p>';
    }
  });
</script>

La validation HTML native suffit-elle ?

Avec la validation HTML native (attributs required, type="email", etc.), le navigateur bloque l'envoi d'un formulaire incomplet ou invalide et affiche un message générique. Il replace généralement le focus sur le premier champ en erreur, et dans la plupart des combinaisons courantes navigateur et lecteur d'écran, le lecteur annonce le message d'erreur et le nom programmatique du champ. Le W3C considère que cela satisfait le critère 3.3.1.

Le W3C liste néanmoins plusieurs inconvénients, et rappelle qu'il revient aux développeurs d'évaluer avec soin si la validation native est compatible avec l'accessibilité (« accessibility supported » au sens des WCAG).

• Selon le navigateur, le message peut ne pas rester affiché ou ne pas suivre le défilement de la page.
• Selon le navigateur, le message n'est pas agrandi quand l'utilisateur zoome : il reste à la taille de l'interface du navigateur et peut être trop petit.
• Les messages par défaut sont généralement génériques et ne fournissent pas forcément des suggestions suffisantes pour 3.3.3.
• Seule la première erreur est exposée : l'utilisateur peut devoir corriger et renvoyer le formulaire plusieurs fois.

Questions fréquentes

À lire aussi sur Conformly

• Corriger un champ de formulaire sans étiquette en HTML
• Critère RGAA 11.10 sur le contrôle de saisie
• Critère RGAA 11.11 sur les suggestions de correction

Sources

Article appuyé sur les sources officielles citées en fin de page.

• W3C — Comprendre 3.3.1
• W3C — Comprendre 3.3.3
• W3C — Comprendre 3.3.2