Chapitre 9.5 — Atelier : un formulaire de A à Z

⏱️ TL;DR — On applique tout. On reprend le formulaire d’inscription d’A11yLearn dans sa version d’origine — inaccessible : placeholders en guise de labels, radios sans groupe, erreurs en rouge sans texte, e-mail à ressaisir — et on le reconstruit entièrement accessible : labels visibles et liés, <fieldset> + <legend>, erreurs identifiées en texte, liées et annoncées, autocomplete partout. Code complet et commenté, puis une checklist réutilisable sur n’importe quel formulaire.

🎯 Objectifs

• Diagnostiquer un formulaire réel et lister ses défauts d’accessibilité.
• Reconstruire un formulaire complet en appliquant les chapitres 9.1 à 9.4.
• Disposer d’une checklist de contrôle réutilisable.

Le point de départ : la version AVANT

Voici le formulaire d’inscription d’A11yLearn tel qu’il existait. Il « marche » à la souris pour un utilisateur voyant sans trouble de la couleur. Pour tous les autres, il est cassé.

<!-- ❌ VERSION AVANT — cumul de fautes d'accessibilité -->
<form>
  <h1>Inscription</h1>
 
  <!-- Placeholder en guise de label : nom accessible fragile, indice qui disparaît -->
  <input type="text" placeholder="Nom complet" />
  <input type="text" placeholder="E-mail" />
  <input type="text" placeholder="Confirmez l'e-mail" /> <!-- saisie redondante -->
  <input type="password" placeholder="Mot de passe" />
 
  <!-- Radios sans fieldset/legend : la question « rôle ? » n'est jamais annoncée -->
  <p>Je m'inscris comme</p>
  <label><input type="radio" name="role" value="app" /> Apprenant</label>
  <label><input type="radio" name="role" value="form" /> Formateur</label>
 
  <!-- Case sans association fiable, astérisque coloré seul pour le requis -->
  <label><input type="checkbox" /> J'accepte les conditions <span style="color:red">*</span></label>
 
  <div>S'inscrire</div> <!-- un bouton fait en div : ni focusable, ni annoncé -->
</form>

Les défauts, un par un :

• Aucun label associé : quatre champs annoncés « zone de saisie, vide » (chap. 9.1).
• Saisie redondante : un champ « Confirmez l’e-mail » inutile (chap. 9.4, critère 3.3.7).
• Radios sans groupe : la question « rôle » n’est pas annoncée (chap. 9.2).
• Requis en couleur seule : l’astérisque rouge ne transmet rien à qui ne le voit pas (chap. 9.2, critère 1.4.1).
• Faux bouton : une <div> ni focalisable, ni annoncée « bouton », ni activable au clavier.
• Aucun type, aucun autocomplete, aucune gestion d’erreur.

La version APRÈS

On reconstruit tout. Chaque correctif renvoie au chapitre qui l’explique.

<!-- ✅ VERSION APRÈS — accessible -->
<form novalidate>
  <h1>Inscription</h1>
 
  <!-- Résumé d'erreurs : focalisable, annoncé, injecté au submit (chap. 9.3) -->
  <div id="resume-erreurs" role="alert" tabindex="-1" hidden></div>
 
  <!-- Labels visibles et associés + autocomplete + type (chap. 9.1 et 9.4) -->
  <p><label for="nom">Nom complet (obligatoire)</label></p>
  <input id="nom" name="nom" type="text" autocomplete="name" required />
 
  <p><label for="email">Adresse e-mail (obligatoire)</label></p>
  <input
    id="email"
    name="email"
    type="email"
    autocomplete="email"
    aria-describedby="email-aide"
    required
  />
  <p id="email-aide">On t'enverra un lien de confirmation à cette adresse.</p>
  <!-- Plus de champ « confirmez l'e-mail » : saisie redondante supprimée (chap. 9.4) -->
 
  <p><label for="pwd">Mot de passe (obligatoire)</label></p>
  <input
    id="pwd"
    name="pwd"
    type="password"
    autocomplete="new-password"
    aria-describedby="pwd-aide"
    required
  />
  <p id="pwd-aide">12 caractères minimum, avec au moins un chiffre.</p>
 
  <!-- Groupe de radios structuré (chap. 9.2) -->
  <fieldset>
    <legend>Je m'inscris comme</legend>
    <label><input type="radio" name="role" value="app" required /> Apprenant</label>
    <label><input type="radio" name="role" value="form" /> Formateur</label>
  </fieldset>
 
  <!-- Requis signalé par le texte, pas par la couleur seule (chap. 9.2) -->
  <p>
    <label>
      <input type="checkbox" name="cgu" required />
      J'accepte les conditions d'utilisation (obligatoire)
    </label>
  </p>
 
  <!-- Vrai bouton : focusable, annoncé « bouton », activable au clavier -->
  <button type="submit">S'inscrire</button>
</form>

Et le champ e-mail en état d’erreur, après une validation au submit (chap. 9.3) :

<p><label for="email">Adresse e-mail (obligatoire)</label></p>
<input
  id="email"
  name="email"
  type="email"
  autocomplete="email"
  aria-invalid="true"
  aria-describedby="email-aide email-erreur"
  required
/>
<p id="email-aide">On t'enverra un lien de confirmation à cette adresse.</p>
<p id="email-erreur" class="erreur">
  <span aria-hidden="true">⚠️ </span>
  Entre une adresse e-mail valide, par exemple prenom@exemple.fr.
</p>

Note que aria-describedby liste deux id (email-aide email-erreur) : le lecteur d’écran annonce l’aide puis l’erreur. On garde l’aide et on ajoute l’erreur, sans écraser l’une par l’autre.

Côté logique de soumission, en JavaScript, on remplit le résumé d’erreurs et on lui donne le focus :

// Au submit : construire la liste, l'afficher, déplacer le focus (chap. 9.3)
const resume = document.getElementById("resume-erreurs");
resume.hidden = false;
resume.innerHTML = `
  <h2>Il y a 1 erreur</h2>
  <ul><li><a href="#email">Adresse e-mail : format invalide</a></li></ul>
`;
resume.focus(); // tabindex="-1" le rend focalisable par script

♿ Côté utilisateur — La version APRÈS, à l’oreille : « Inscription, titre niveau 1 », puis « Nom complet, obligatoire, zone de saisie », « Adresse e-mail, obligatoire, zone de saisie, on t’enverra un lien de confirmation », etc. Le groupe annonce « Je m’inscris comme, Apprenant, bouton radio, 1 sur 2 ». Le bouton est « S’inscrire, bouton ». En cas d’erreur, le focus saute sur « Il y a 1 erreur : Adresse e-mail, format invalide », d’où un lien mène droit au champ. Le même formulaire, entièrement navigable sans voir l’écran.

La checklist formulaire

Passe chaque formulaire à cette grille avant de le livrer.

🧭 Sur A11yLearn — Cet atelier est le tournant d’A11yLearn côté formulaires. On est passé d’un formulaire d’inscription que 100 % des testeurs au lecteur d’écran abandonnaient à un formulaire franchissable de bout en bout : un utilisateur de NVDA a créé son compte sans aide, du premier « Nom complet, zone de saisie » jusqu’au « S’inscrire, bouton », en corrigeant une erreur d’e-mail grâce au résumé focalisé. La leçon transversale : aucune de ces corrections n’a demandé de framework ni de bibliothèque — juste du HTML correct et une poignée d’attributs ARIA bien placés. C’est le cœur du métier.

✏️ Exercices

Exercice 1 — Audit express. Reprends la version AVANT et écris, en une ligne chacun, les cinq défauts les plus graves avec leur correctif.

Exercice 2 — Étends la checklist. A11yLearn ajoute un champ « Date de naissance » et un champ « Pays ». Quels attributs d’aide à la saisie mets-tu, et quel piège évites-tu sur le champ pays ?

🧠 Quiz de révision

Partie suivante : Tester l’accessibilité — maintenant que tu sais construire un formulaire accessible, apprends à le vérifier : outils automatiques, navigation clavier, lecteur d’écran.