Rédiger des erreurs accessibles pour les rendez-vous

Un message d’erreur doit expliquer ce que la personne peut faire ensuite. « Saisie invalide » aide peu à corriger un format de date et décrit mal un créneau déjà pris. Une réservation dont l’état est inconnu appelle encore une autre réponse.

Trois situations et des messages adaptés

Le service de rendez-vous suivant est fictif. Il utilise un champ texte pour la date et propose une liste des réservations existantes. La date d’exemple est le 14 décembre 2026.

Le troisième message n’annonce pas un échec : ce n’est pas encore établi. Dans l’exemple, « Ouvrir la liste des rendez-vous » mène aux réservations existantes. Si le produit réel ne propose pas cette liste, il faut un autre moyen fiable de vérifier l’état.

Relier le message au champ

Affichez le format et l’exemple avant qu’une erreur survienne. Acceptez autant que possible les modes de saisie nécessaires à votre public, sans format inutilement restrictif. Cet exemple réduit montre le champ texte après une erreur de format :

<label for="appointment-date">Date</label>
<p id="appointment-date-hint">JJ/MM/AAAA, par exemple 14/12/2026</p>
<input id="appointment-date" name="appointmentDate" type="text"
  value="14/12" aria-invalid="true"
  aria-describedby="appointment-date-hint appointment-date-error">
<p id="appointment-date-error">Saisissez la date au format JJ/MM/AAAA.</p>

Les identifiants relient libellé, aide et erreur au même champ. La couleur peut aider, mais le message doit rester compréhensible sans bordure rouge. Le tutoriel W3C WAI explique cette association par aria-describedby et les indications de correction compréhensibles.

Après correction valide, retirez le texte d’erreur, sa référence et l’état invalide ; l’aide sur le format peut rester. Ce balisage ne prouve pas, à lui seul, l’accessibilité du formulaire complet.

Tester le parcours de correction

Si l’envoi produit plusieurs erreurs, un récapitulatif avec des liens vers les champs concernés est utile. Choisissez si le focus va au récapitulatif ou au premier champ invalide, puis testez au clavier et avec les lecteurs d’écran visés. Les messages dynamiques doivent être perceptibles sans interrompre inutilement chaque frappe.

Dans l’exemple, la personne doit corriger la date sans ressaisir les autres informations valides. Vérifiez ensuite que l’ancienne erreur n’est plus annoncée. Pour un créneau occupé, conservez les autres données pendant le choix d’une autre heure. Si l’état est incertain, l’étape suivante sert d’abord à vérifier la réservation existante.

Testez aussi un message de réussite explicite indiquant le rendez-vous confirmé. Il permet à la personne de savoir que la tâche est terminée.

Sources

• W3C WAI: User Notification