Quand vos messages d'erreur excluent vos utilisateurs

Le moment où le formulaire se brise

Imaginez la scène : un utilisateur aveugle remplit un formulaire de paiement, le soumet, et n’entend rien d’utile de la part de son lecteur d’écran. Aucune annonce. Aucune explication. La page a signalé visuellement cinq erreurs de validation en rouge, mais l’utilisateur n’en sait rien. Il soumet à nouveau. Et encore. Il finit par abandonner.

Ce n’est pas un scénario marginal. La gestion inaccessible des erreurs est l’un des obstacles les plus fréquents que nous rencontrons lors de véritables audits, et c’est un obstacle qui frustre les utilisateurs au pire moment possible — lorsqu’ils essaient de finaliser une transaction ou de soumettre quelque chose d’important.

La bonne nouvelle, c’est que le corriger revient en grande partie à savoir à quoi ressemble « bien ». Les échecs se réduisent presque toujours aux mêmes quelques schémas.

Pourquoi les messages d’erreur sont difficiles pour les utilisateurs de technologies d’assistance

Les utilisateurs voyants qui se servent d’une souris remarquent généralement les erreurs de validation immédiatement — la bordure rouge, l’icône d’avertissement, le texte qui apparaît sous le champ. Mais les utilisateurs qui dépendent d’un lecteur d’écran, de la navigation au clavier ou de la commande vocale vivent une expérience fondamentalement différente.

Lorsqu’un formulaire est soumis et que des erreurs apparaissent :

Les utilisateurs de lecteurs d’écran peuvent ne rien entendre, à moins que le focus ne se déplace vers l’erreur ou qu’une région live ne l’annonce
Les utilisateurs au clavier doivent pouvoir atteindre chaque message d’erreur au clavier et comprendre à quel champ il se rapporte
Les utilisateurs de commande vocale doivent pouvoir désigner les champs par une étiquette visible et exacte — si l’étiquette est erronée ou absente, ils sont bloqués

Rien de tout cela ne se produit automatiquement. Il faut le construire.

Les critères WCAG applicables

Quatre critères de succès des WCAG 2.2 couvrent directement la gestion des erreurs :

3.3.1 Identification des erreurs (niveau A) — Si une erreur est détectée automatiquement, l’élément en erreur est identifié et décrit à l’utilisateur sous forme de texte. Vous ne pouvez pas signaler les erreurs par la couleur seule.

3.3.2 Étiquettes ou instructions (niveau A) — Les champs qui exigent un format particulier doivent rendre cette exigence claire avant ou pendant la saisie, et pas seulement après l’échec de la soumission.

3.3.3 Suggestion après une erreur (niveau AA) — Si une erreur est détectée et que des suggestions de correction sont connues, fournissez-les. « Date invalide » ne suffit pas. « Saisissez la date au format JJ/MM/AAAA » convient.

3.3.4 Prévention des erreurs (niveau AA) — Pour les soumissions à fort enjeu (transactions financières, engagements juridiques), donnez aux utilisateurs la possibilité de vérifier, corriger et confirmer avant que l’action ne soit définitive.

Il existe aussi le critère 4.1.3 Messages d’état (niveau AA), qui couvre les messages injectés dynamiquement sans recevoir le focus — ils doivent être annoncés par les technologies d’assistance à l’aide de role="status" ou role="alert".

Ce dont un message d’erreur accessible a réellement besoin

Réussir ses messages d’erreur exige de soigner quatre couches distinctes :

1. La liaison programmatique

Chaque message d’erreur doit être relié à son champ via aria-describedby. Cela indique aux lecteurs d’écran d’annoncer le texte de l’erreur lorsque le champ reçoit le focus.

<!-- Before: error text exists visually but is invisible to screen readers -->
<label for="email">Email</label>
<input type="email" id="email" class="error">
<p class="error-text">Enter a valid email address.</p>

<!-- After: programmatic association via aria-describedby -->
<label for="email">Email address</label>
<input
  type="email"
  id="email"
  aria-describedby="email-err"
  aria-invalid="true"
>
<p id="email-err" class="error-text">Enter a valid email address.</p>

L’attribut aria-invalid="true" signale que le champ est actuellement invalide, ce que la plupart des lecteurs d’écran annoncent lorsque le focus s’y pose.

2. La gestion du focus après la soumission

Lorsqu’un formulaire est soumis et que des erreurs sont présentes, le focus doit se déplacer vers un endroit utile. Les deux modèles les plus courants :

Déplacer le focus vers un récapitulatif des erreurs en haut du formulaire, qui liste toutes les erreurs avec des liens vers les champs concernés
Déplacer le focus vers le premier champ en erreur

Si le focus reste sur le bouton de soumission ou nulle part, les utilisateurs de lecteurs d’écran doivent découvrir les erreurs par eux-mêmes en parcourant le formulaire — à supposer qu’ils sachent même que des erreurs existent.

// After validation fails, move focus to the error summary
const summary = document.getElementById('error-summary');
summary.setAttribute('tabindex', '-1');
summary.focus();

3. Les annonces par région live pour les erreurs dynamiques

Pour les erreurs qui apparaissent pendant la saisie (validation en temps réel), utilisez les régions live ARIA afin que le message soit annoncé sans déplacer le focus.

<p role="alert" aria-live="assertive" id="password-err">
  Password must be at least 8 characters.
</p>

Utilisez role="alert" / aria-live="assertive" pour les erreurs qui exigent une attention immédiate. Utilisez role="status" / aria-live="polite" pour les retours moins urgents qui peuvent attendre une pause de l’utilisateur.

4. Le message d’erreur lui-même

La formulation compte. Les messages d’erreur accessibles sont :

Précis : ils disent ce qui ne va pas, pas seulement que quelque chose ne va pas
Actionnables : ils indiquent à l’utilisateur exactement quoi faire pour corriger
Courtois : ils évitent les formulations culpabilisantes comme « vous avez saisi une valeur invalide »

Inaccessible	Accessible
« Saisie invalide »	« L’adresse e-mail doit contenir un symbole @, p. ex. nom@exemple.com »
« Erreur »	« La date doit être au format JJ/MM/AAAA »
« Champ obligatoire »	« Le nom complet est obligatoire »
« Mot de passe invalide »	« Le mot de passe doit comporter au moins 8 caractères et inclure un chiffre »

Des modèles pour différents scénarios d’erreur

Erreurs en ligne sous le champ

Le modèle le plus courant. Un message d’erreur apparaît directement sous le champ auquel il est associé. Il convient bien aux formulaires simples. Il exige aria-describedby et aria-invalid pour être annoncé correctement.

Bannières récapitulatives d’erreurs

Pour les formulaires longs comportant plusieurs erreurs, placez en haut un récapitulatif listant tous les problèmes sous forme de liens qui mènent au champ concerné. Déplacez-y le focus après une soumission échouée. C’est le modèle utilisé par GOV.UK et largement recommandé pour les formulaires complexes.

Notifications toast

Les messages éphémères qui apparaissent au bord de l’écran comptent parmi les modèles les plus inaccessibles couramment utilisés. Ils disparaissent avant que les utilisateurs de lecteurs d’écran puissent les atteindre, ils ne sont souvent pas annoncés du tout, et ils n’offrent aucun moyen de récupération. Évitez les toasts pour les erreurs. Si vous les utilisez malgré tout, associez-les à un état d’erreur persistant sur le formulaire lui-même.

Erreurs système

Lorsque quelque chose tourne mal côté serveur, expliquez à l’utilisateur en langage clair ce qui s’est passé et ce qu’il peut faire ensuite. « Une erreur s’est produite » sans autre indication laisse les utilisateurs démunis.

<div role="alert" aria-live="assertive">
  <p>We couldn't save your changes due to a network error.
  Please check your connection and try again.</p>
</div>

La liste de contrôle des tests

Après avoir implémenté la gestion des erreurs, vérifiez ces points manuellement — les outils automatisés n’en détecteront pas la plupart :

La soumission d’un formulaire obligatoire vide déplace le focus vers un récapitulatif des erreurs ou vers le premier champ en erreur
Chaque message d’erreur est relié à son champ via aria-describedby
Les champs en erreur portent aria-invalid="true"
Les messages d’erreur sont annoncés lorsque le focus se pose sur le champ concerné
La validation en temps réel utilise des régions live
Les messages d’erreur utilisent une formulation précise et actionnable — pas seulement « invalide »
La couleur n’est pas le seul moyen de signaler les erreurs (icône ou libellé textuel en plus du rouge)
L’erreur est atteignable par tabulation au clavier
L’ordre de focus après la soumission est logique et ne saute pas de manière imprévisible
Les messages toast sont associés à un état d’erreur persistant

Pourquoi les outils automatisés passent à côté de l’essentiel

Un scanner automatisé peut vérifier que aria-describedby pointe vers un élément existant et que aria-invalid est présent. Il ne peut pas vérifier que le focus se déplace correctement après la soumission, que le texte de l’erreur est exact, ni qu’une notification toast disparaît avant d’avoir pu être lue. Nos audits manuels d’accessibilité incluent des tests spécifiques aux formulaires avec de véritables technologies d’assistance — le seul moyen fiable de vérifier que la gestion des erreurs fonctionne réellement de bout en bout.

Si vous ne savez pas où en sont vos formulaires, lancez un scan gratuit pour faire remonter d’abord les problèmes automatisables, puis avancez à partir de là.