Messages d'erreur accessibles : le guide complet

Le coût caché des erreurs inutiles

Vous avez sûrement déjà vu ça : un formulaire qui affiche « Entrée non valide » alors que vous venez de saisir soigneusement votre numéro de téléphone. Un processus de paiement qui surligne un champ en rouge sans donner aucune explication. Un message d'erreur qui utilise des codes énigmatiques que seul le développeur qui l'a écrit un vendredi à 23 heures est capable de comprendre.

Il ne s'agit pas là de simples désagréments en matière d'expérience utilisateur. Pour les 1,3 milliard de personnes dans le monde qui vivent avec un handicap, des messages d'erreur mal conçus peuvent rendre un produit numérique totalement inutilisable. Pour les utilisateurs de lecteurs d'écran, un message d'erreur qui ne change que de couleur est invisible. Pour les utilisateurs souffrant de troubles cognitifs, une phrase vague telle que « Une erreur s'est produite » est paralysante. Pour une personne qui dépend de la commande vocale, une erreur de formulaire qui détourne le focus de manière imprévisible perturbe tout le déroulement des tâches.

La création de messages d'erreur accessibles ne se résume pas à ajouter des attributs ARIA après coup. Elle nécessite un langage bien pensé, une structure DOM adaptée, des indications visuelles et non visuelles, ainsi qu'un profond respect pour la diversité de vos utilisateurs. Ce guide passe en revue tous les aspects nécessaires à leur bonne conception, des critères WCAG aux principes de rédaction, en passant par des exemples concrets de code.

Ce qu'exige réellement la norme

Les WCAG 2.2, publiées en octobre 2023, constituent la norme actuelle en matière d'accessibilité du Web et servent de référence à la plupart des cadres juridiques, notamment la directive européenne sur l'accessibilité du Web, la loi britannique sur l'égalité et l'ADA américaine. Plusieurs critères de conformité s'appliquent directement aux messages d'erreur. Il est essentiel d'en comprendre la lettre avant de pouvoir aller au-delà.

Qu'est-ce qui caractérise un bon message d'erreur ?

Un message d'erreur bien conçu comporte quatre éléments indispensables. Chacun d'entre eux remplit une fonction bien précise : si vous en supprimez un seul, vous détériorez l'expérience d'une partie de vos utilisateurs.

Le cadre linguistique : six règles pour la rédaction de textes d'erreurs

Les messages d'erreur relèvent de la rédaction UX. Ce ne sont pas des sorties de journal. Ce ne sont pas des notes destinées aux développeurs. Il s'agit d'une communication humaine en situation de stress, rédigée à l'intention d'une personne qui vient d'échouer et qui a besoin de réussir.

Messages d'erreur réels : avant et après

La différence entre un message d'erreur incompréhensible et un message d'erreur compréhensible se résume souvent à quelques mots et à deux attributs. Ces comparaisons montrent précisément ce qui change — et pourquoi chaque modification est importante.

Validation des champs obligatoires

Validation du format (date)

Validation du mot de passe

Erreur de serveur / système

Types d'erreurs et quand les utiliser

Différents scénarios d'erreur nécessitent différents modèles d'interaction. Le choix d'un conteneur ou d'un mécanisme d'affichage inadapté constitue l'une des défaillances d'accessibilité les plus courantes dans les formulaires.

L'approche à deux niveaux pour les formulaires à champs multiples

Pour les formulaires comportant au moins trois champs, un seul modèle ne suffit pas. Le Government Digital Service (GDS) et le guide des pratiques de rédaction ARIA recommandent tous deux un système à deux niveaux : un résumé des erreurs en haut du formulaire, ainsi que des messages d'erreur intégrés à côté de chaque champ concerné.

Modèles de code qui fonctionnent

Comprendre la théorie, c'est déjà la moitié du chemin. Vous trouverez ci-dessous des modèles prêts à l'emploi pour les scénarios les plus courants, accompagnés d'une liste des critères WCAG auxquels chaque attribut répond.

Validation des champs en ligne

<!-- The label is always present and always linked -->
<div class="field-group">
  <label for="email">
    Email address
    <span class="required-indicator" aria-label="required"> *</span>
  </label>

  <input
    type="email"
    id="email"
    name="email"
    autocomplete="email"
    aria-required="true"
    aria-invalid="true"     <!-- set when invalid -->
    aria-describedby="email-hint email-error"
  />

  <!-- Hint text always shown (WCAG 3.3.2) -->
  <p id="email-hint" class="field-hint">
    We'll send your confirmation here.
  </p>

  <!-- Error message (shown only on error) -->
  <p
    id="email-error"
    class="field-error"
    role="alert"
    aria-live="assertive"
  >
    <!-- inject error text here -->
    Enter a complete email address — for example, [email protected]
  </p>
</div>

Résumé des erreurs (formulaires à champs multiples)

<!-- Inject this above the form on submission, then focus #error-summary -->
<div
  id="error-summary"
  role="alert"
  aria-labelledby="error-summary-title"
  tabindex="-1"   <!-- allows programmatic focus -->
  class="error-summary"
>
  <h2 id="error-summary-title">
    There are 2 errors. Fix these to continue.
  </h2>
  <ul>
    <li><a href="#email">Email address: enter a complete email</a></li>
    <li><a href="#dob">Date of birth: use DD/MM/YYYY format</a></li>
  </ul>
</div>

<!-- JavaScript: move focus to summary after injection -->
<script>
  const summary = document.getElementById('error-summary');
  summary.focus(); // fires after DOM update
</script>

Erreurs dynamiques / AJAX (sans actualisation de la page)

Lorsque des erreurs sont renvoyées de manière asynchrone — par exemple, à la suite d'un appel d'API —, on ne peut pas compter sur le chargement de la page pour les signaler. Le modèle de zone active ARIA est ici indispensable.

// Set up the live region once on page load (empty, hidden)
// <div id="live-error" role="alert" aria-live="assertive" aria-atomic="true"></div>

async function submitForm(data) {
  try {
    const res = await fetch('/api/save', { method: 'POST', body: data });
    if (!res.ok) throw new Error(await res.text());
    announceStatus('Your changes have been saved.', 'polite');
  } catch (err) {
    announceStatus(
      'We couldn\'t save your changes. Try again or contact support.',
      'assertive'
    );
  }
}

function announceStatus(message, urgency = 'polite') {
  const region = document.getElementById('live-error');
  region.setAttribute('aria-live', urgency);
  // Clear first to re-trigger announcement if same message
  region.textContent = '';
  requestAnimationFrame(() => {
    region.textContent = message;
  });
}

Liste de contrôle pour l'audit de l'accessibilité

Utilisez cette liste de contrôle lors des revues de conception, des revues de code et des contrôles qualité. Elle couvre tous les critères de niveau A et AA des WCAG 2.2 relatifs aux états d'erreur.

Visuel et contenu

Programmation et technologies d'assistance

Mise au point et clavier

Comment nous en sommes arrivés là : un bref historique

Les messages d'erreur, reflet des valeurs de votre produit

Le message d'erreur est l'un des moments les plus révélateurs de toute expérience numérique. Il apparaît précisément au moment où l'utilisateur est sous pression : lorsqu'il a commis une erreur ou qu'un imprévu indépendant de sa volonté s'est produit. La manière dont vous réagissez à ce moment-là en dit long sur l'importance que vous accordez à l'inclusion.

Une bordure rouge sans texte n'est pas un message d'erreur. Une liste de codes n'est pas un message d'erreur. Une vague mention du type « une erreur s'est produite » n'est pas un message d'erreur. Un message d'erreur accessible est un message clair, bienveillant et concret, rédigé dans un langage compréhensible par tous — y compris les 26 % d'utilisateurs en situation de handicap, les 15 % qui utilisent la navigation au clavier et les 100 % d'utilisateurs qui rencontreront une erreur à un moment ou à un autre.

La bonne nouvelle, c'est que la mise en place de messages d'erreur accessibles ne demande que très peu d'efforts supplémentaires lorsqu'elle est intégrée dès le début. Les attributs ARIA sont succincts. Les consignes rédactionnelles sont claires. Les modèles sont bien établis. Ce qu'il faut, c'est de la volonté : une décision délibérée de tester avec des technologies d'assistance, d'écrire pour des humains plutôt que pour des systèmes, et de considérer chaque situation d'échec comme une occasion de gagner la confiance des utilisateurs.

Chez AIOPSGROUP, une société du groupe valantic, nous développons des produits numériques accessibles à tous. L'ingénierie de l'accessibilité est intégrée à notre système de conception, à nos revues de code et à notre processus d'assurance qualité — elle n'est pas simplement ajoutée en fin de processus. Si votre équipe a besoin d'aide pour auditer, mettre en œuvre ou créer de A à Z un système de conception accessible, nous serons ravis de vous aider.