Le laissez-passer A-38 — Partie 2 : Écouter la réponse

Écouter les réponses

Dans la partie précédente, tu as appris à poser les bonnes questions. Labels, types, autocomplete, regroupements. Ton formulaire sait maintenant demander les informations correctement.

Mais poser la question ne suffit pas. Il faut écouter la réponse.

Quand l'utilisateur se trompe de format, quand un champ obligatoire est vide, quand la saisie ne correspond pas à ce que tu attendais, c'est le moment critique. Soit ton formulaire guide, soit il punit. Soit il dit "ton email n'a pas le bon format, voici un exemple", soit il affiche un "Erreur" rouge sans explication et laisse l'utilisateur deviner.

Cet article couvre la deuxième moitié de la conversation : valider au bon moment, afficher des erreurs qui aident, récapituler les problèmes, et gérer les composants custom qui remplacent les éléments natifs.

Des erreurs qui aident

Un message d'erreur a une seule mission : permettre à l'utilisateur de corriger. S'il ne dit pas quoi corriger et comment, il ne sert à rien.

"Erreur" ne dit rien. "Champ invalide" ne dit presque rien. "Ce champ attend une adresse email au format nom@domaine.fr" dit tout.

La mécanique repose sur deux attributs :

<label for="email">Adresse email</label>
<input
  id="email"
  type="email"
  required
  aria-describedby="email-error"
>
<p id="email-error" class="error-message"></p>

// Basculer l'état et remplir le message au moment de la validation
function setFieldError(field, message) {
  const errorNode = document.getElementById(`${field.id}-error`);
  field.setAttribute('aria-invalid', 'true');
  errorNode.textContent = message;
}
 
function clearFieldError(field) {
  const errorNode = document.getElementById(`${field.id}-error`);
  field.removeAttribute('aria-invalid');
  errorNode.textContent = '';
}

input:user-invalid {
  border-color: var(--color-error);
}
 
.error-message {
  color: var(--color-error);
  font-size: var(--font-size-sm);
}
 
.error-message:not(:empty)::before {
  content: "⚠";
  margin-inline-end: var(--space-1);
}

Deux pièges à éviter. D'abord, aria-invalid="true" ne doit pas être écrit en dur dans le HTML : copié tel quel, le champ serait signalé invalide dès le chargement. Il est posé dynamiquement, par JavaScript, au moment de la validation. Ensuite, pas d'aria-live="polite" sur le message lui-même : le message est déjà cible d'aria-describedby, et le résumé d'erreurs porte role="alert". Cumuler les deux sur le même élément expose à une double annonce. L'annonce vient du résumé (immédiate) et de la description (lue à la prise de focus sur le champ). Si tu tiens à une annonce immédiate lors d'une validation au blur, teste avec un lecteur d'écran avant de l'affirmer.

aria-invalid="true" dit à la technologie d'assistance que le champ contient une erreur. aria-describedby lie le champ au message qui explique l'erreur. Le lecteur d'écran annonce : "Adresse email, invalide, Ce champ attend une adresse email au format nom@domaine.fr."

Le signal visuel suit le même principe que les couleurs qui ne doivent jamais être seules. Bordure, texte et icône.

Quelques règles pour les messages d'erreur :

• Dis ce qui ne va pas. "Saisissez votre numéro à 10 chiffres", pas "Ce champ est requis"
• Dis comment corriger. "Format attendu : 06 12 34 56 78", pas "Format invalide"
• Reste près du champ. Le message doit être visuellement adjacent au champ en erreur
• Ne disparais pas trop vite. Le message reste visible tant que l'erreur n'est pas corrigée

Ces messages près des champs sont indispensables, mais ils ne suffisent pas seuls pour les formulaires longs. La section suivante couvre le résumé d'erreurs, la vue d'ensemble après soumission.

Les composants custom

Le HTML natif offre <select>, <input type="date">, <input type="range">, <details>, <datalist>. Ils sont accessibles par défaut : navigables au clavier, annoncés correctement par les lecteurs d'écran, compatibles avec l'autocomplétion et la validation native.

Et pourtant, la majorité des projets les remplacent par des composants custom. Une <div> qui ressemble à un <select>. Un calendrier en JavaScript qui remplace <input type="date">. Une combobox faite maison qui réinvente <datalist>.

Pourquoi ? Parce que les composants natifs sont difficiles à styliser. Le <input type="date"> en est l'exemple le plus parlant : son popup est un widget natif du système d'exploitation, pas un élément web. En 2026, on ne peut toujours pas en changer les couleurs, la disposition ou la typographie. Son rendu varie entre Chrome, Firefox et Safari. Les pseudo-éléments WebKit ne fonctionnent pas partout. C'est une raison valable de le remplacer. Mais elle a un coût.

Un calendrier custom doit reproduire tout ce que le natif fait gratuitement :

• Navigation clavier (Tab pour entrer, flèches pour se déplacer entre les jours, Entrée pour sélectionner, Échap pour fermer)
• Annonce par le lecteur d'écran (rôle, date courante, mois affiché, jour sélectionné)
• Mise à jour en temps réel (aria-selected, aria-current="date", aria-label sur chaque jour)
• Gestion du focus (confinement dans le calendrier ouvert, retour au champ à la fermeture)

Voici la structure minimale d'un calendrier accessible, et c'est déjà conséquent :

<label for="departure">Date de départ</label>
<input
  id="departure"
  type="text"
  autocomplete="off"
  placeholder="jj/mm/aaaa"
>
<button
  aria-label="Choisir la date de départ"
  aria-haspopup="dialog"
  aria-expanded="false"
>📅</button>
 
<dialog aria-label="Choisir une date">
  <header>
    <button>Mois précédent</button>
    <h2 aria-live="polite">Avril 2026</h2>
    <button>Mois suivant</button>
  </header>
  <table role="grid" aria-label="Avril 2026">
    <thead>
      <tr>
        <th scope="col" aria-label="Lundi" title="Lundi">L</th>
        <th scope="col" aria-label="Mardi" title="Mardi">M</th>
        <th scope="col" aria-label="Mercredi" title="Mercredi">M</th>
        <th scope="col" aria-label="Jeudi" title="Jeudi">J</th>
        <th scope="col" aria-label="Vendredi" title="Vendredi">V</th>
        <th scope="col" aria-label="Samedi" title="Samedi">S</th>
        <th scope="col" aria-label="Dimanche" title="Dimanche">D</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td tabindex="-1" aria-label="1 avril 2026">1</td>
        <td tabindex="-1" aria-label="2 avril 2026">2</td>
        <!-- ... -->
        <td tabindex="0" aria-selected="true" aria-current="date" aria-label="22 avril 2026">22</td>
        <!-- ... -->
      </tr>
    </tbody>
  </table>
</dialog>

Et il manque encore tout le JavaScript : navigation au clavier entre les jours (flèches), entre les mois (Page Up/Down), entre les années (Maj + Page Up/Down), retour au champ à la sélection, fermeture à l'Échap, mise à jour de l'aria-label dynamique. Chaque comportement doit être implémenté manuellement. Le <input type="date"> natif le fait en zéro ligne de code.

Avant de construire un composant custom, pose-toi trois questions :

1. Est-ce que le natif suffit ? Un <input type="date"> avec une bonne combinaison label + min/max + validation couvre souvent le besoin. Un <datalist> combiné à un <input> donne une combobox native.
2. Est-ce que le design peut s'adapter ? Parfois, accepter les limites du natif coûte moins cher que maintenir un composant custom accessible.
3. Si je n'ai pas le choix, est-ce que je suis le pattern ARIA ? Les ARIA Authoring Practices Guide documentent chaque pattern (combobox, dialog, grid, tabs, accordion) avec le clavier, les rôles et les états attendus. Ne pas les suivre, c'est réinventer la roue en carré.

Le sujet ARIA est couvert en deux articles : le poison et le scalpel. La règle d'or : si un élément HTML natif fait le travail, utilise-le.

Sources

• W3C WAI — Form notifications
• ARIA Authoring Practices Guide
• MDN — :user-invalid
• MDN — aria-live
• MDN — aria-invalid
• MDN — aria-describedby
• MDN — dialog
• MDN — input type="date"
• W3C WAI — ARIA Authoring Practices: Date Picker