Formulaires

Critère 11.1Chaque champ de formulaire a-t-il une étiquette ?

Ce que ça vérifie — Chaque champ de formulaire (saisie de texte, case à cocher, bouton radio, liste, zone de texte…) doit disposer d'une étiquette qui en indique la fonction, restituée aux technologies d'assistance. Sans elle, un utilisateur de lecteur d'écran ne sait pas quelle donnée saisir.

Comment corriger — Associez une étiquette visible via <label for> pointant sur l'attribut id du champ ; à défaut utilisez aria-label ou aria-labelledby. Signalez le caractère obligatoire dans l'intitulé ou avec aria-required="true" (ou l'attribut HTML required).

<label for="email">Adresse e-mail (obligatoire)</label>
<input type="email" id="email" name="email" required aria-required="true" />

Critère 11.2Chaque étiquette associée à un champ de formulaire est-elle pertinente (hors cas particuliers) ?

Ce que ça vérifie — L'étiquette associée à un champ doit décrire précisément la donnée attendue. Une étiquette présente mais vague ou trompeuse (« Champ 1 », « Texte ») ne remplit pas son rôle.

Comment corriger — Rédigez un intitulé explicite qui correspond à l'information demandée. Vérifiez la cohérence entre l'étiquette visible et l'étiquette accessible (aria-label) si les deux existent.

<!-- À éviter -->
<label for="c1">Champ</label>
<input id="c1" name="ville" />
<!-- Recommandé -->
<label for="ville">Ville de résidence</label>
<input id="ville" name="ville" />

Critère 11.3Dans chaque formulaire, chaque étiquette associée à un champ de formulaire ayant la même fonction et répétée plusieurs fois dans une même page ou dans un ensemble de pages est-elle cohérente ?

Ce que ça vérifie — Lorsqu'un même type de champ est répété (dans un même formulaire ou sur plusieurs pages du site), son étiquette doit rester identique d'une occurrence à l'autre. Des libellés différents pour une fonction identique désorientent l'utilisateur.

Comment corriger — Harmonisez les intitulés des champs de même fonction. Employez systématiquement le même terme (par exemple « Code postal » partout, et non « CP » ici et « Code postal » ailleurs).

Critère 11.4Dans chaque formulaire, chaque étiquette de champ et son champ associé sont-ils accolés (hors cas particuliers) ?

Ce que ça vérifie — L'étiquette doit être visuellement accolée à son champ, afin que le lien entre les deux soit évident, y compris pour les personnes malvoyantes ou utilisant un zoom.

Comment corriger — Placez l'étiquette immédiatement avant ou après le champ, sans élément intercalé, en utilisant un <label> lié par for/id ou une étiquette implicite (champ imbriqué dans le <label>). Évitez de séparer étiquette et champ par de larges espaces ou d'autres contrôles.

<!-- Étiquette explicite (for/id) -->
<label for="nom">Nom</label>
<input id="nom" name="nom" />
<!-- Étiquette implicite -->
<label>Nom <input name="nom" /></label>

Critère 11.5Dans chaque formulaire, les champs de même nature sont-ils regroupés, si nécessaire ?

Ce que ça vérifie — Les champs qui concourent à une même saisie (adresse postale, choix parmi des boutons radio, date en plusieurs champs…) doivent être regroupés quand ce regroupement est nécessaire à la compréhension.

Comment corriger — Entourez les champs liés d'un élément <fieldset> pour matérialiser le groupe auprès des technologies d'assistance. Réservez le regroupement aux cas où il apporte du sens ; ne l'appliquez pas à un champ isolé.

<fieldset>
  <legend>Adresse de livraison</legend>
  <label for="rue">Rue</label>
  <input id="rue" name="rue" />
  <label for="cp">Code postal</label>
  <input id="cp" name="cp" />
</fieldset>

Critère 11.6Dans chaque formulaire, chaque regroupement de champs de même nature a-t-il une légende ?

Ce que ça vérifie — Chaque regroupement de champs réalisé avec <fieldset> doit posséder une légende qui nomme le groupe. Cette légende est restituée avec chaque champ du groupe par les lecteurs d'écran.

Comment corriger — Ajoutez un élément <legend> comme premier enfant du <fieldset>, décrivant l'objet du regroupement.

<fieldset>
  <legend>Mode de contact préféré</legend>
  <label><input type="radio" name="contact" value="tel" /> Téléphone</label>
  <label><input type="radio" name="contact" value="mail" /> E-mail</label>
</fieldset>

Critère 11.7Dans chaque formulaire, chaque légende associée à un regroupement de champs de même nature est-elle pertinente ?

Ce que ça vérifie — La légende d'un regroupement doit décrire clairement ce à quoi correspondent les champs qu'il contient. Une légende vide, générique ou hors sujet ne remplit pas son rôle.

Comment corriger — Rédigez une <legend> pertinente et concise, en rapport direct avec les champs regroupés (par exemple « Coordonnées bancaires » plutôt que « Section 3 »).

Critère 11.8Dans chaque formulaire, les items de même nature d’une liste de choix sont-ils regroupés de manière pertinente ?

Ce que ça vérifie — Dans une liste déroulante longue, les items de même nature doivent être regroupés de façon pertinente pour faciliter le repérage et la sélection. Le regroupement doit être restitué aux technologies d'assistance.

Comment corriger — Structurez les options d'un <select> avec des éléments <optgroup> dotés d'un attribut label décrivant chaque catégorie.

<select name="ville">
  <optgroup label="Île-de-France">
    <option>Paris</option>
    <option>Versailles</option>
  </optgroup>
  <optgroup label="Occitanie">
    <option>Toulouse</option>
    <option>Montpellier</option>
  </optgroup>
</select>

Critère 11.9Dans chaque formulaire, l’intitulé de chaque bouton est-il pertinent (hors cas particuliers) ?

Ce que ça vérifie — L'intitulé de chaque bouton (envoi, réinitialisation, bouton image ou personnalisé) doit indiquer clairement l'action déclenchée. « Valider » sur plusieurs boutons différents ou « OK » isolé manque de pertinence.

Comment corriger — Donnez au bouton un libellé explicite via son contenu texte, l'attribut value, ou aria-label pour les boutons icône. Pour <input type="image">, renseignez l'attribut alt.

<!-- À éviter -->
<button type="submit">OK</button>
<!-- Recommandé -->
<button type="submit">Envoyer ma demande de contact</button>

Critère 11.10Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente (hors cas particuliers) ?

Ce que ça vérifie — Quand un formulaire contrôle les données saisies (format, champ obligatoire, valeur attendue), le contrôle doit être mis en œuvre de manière pertinente : erreurs signalées de façon accessible, champs concernés identifiés, message textuel explicite.

Comment corriger — Indiquez les erreurs par un message texte associé au champ via aria-describedby, marquez le champ fautif avec aria-invalid="true", et déplacez le focus ou signalez l'erreur sans reposer uniquement sur la couleur. Précisez les champs obligatoires et les formats attendus.

<label for="tel">Téléphone</label>
<input id="tel" name="tel" type="tel" aria-invalid="true" aria-describedby="tel-err" />
<p id="tel-err">Le numéro doit comporter 10 chiffres.</p>

Critère 11.11Dans chaque formulaire, le contrôle de saisie est-il accompagné, si nécessaire, de suggestions facilitant la correction des erreurs de saisie ?

Ce que ça vérifie — Lorsqu'une erreur de saisie est détectée, l'utilisateur doit recevoir des suggestions concrètes l'aidant à la corriger, dès lors que ces suggestions sont connues et n'exposent pas la sécurité ou la finalité du champ.

Comment corriger — Complétez le message d'erreur par une aide à la correction (format attendu, exemple, valeur valide la plus proche) restituée via aria-describedby. Reliez le message au champ pour qu'il soit annoncé par les technologies d'assistance.

<label for="date">Date de naissance</label>
<input id="date" name="date" aria-invalid="true" aria-describedby="date-err" />
<p id="date-err">Format attendu : JJ/MM/AAAA (ex. 25/12/1990).</p>

Critère 11.12Pour chaque formulaire qui modifie ou supprime des données, ou qui transmet des réponses à un test ou à un examen, ou dont la validation a des conséquences financières ou juridiques, les données saisies peuvent-elles être modifiées, mises à jour ou récupérées par l’utilisateur ?

Ce que ça vérifie — Pour les actions à conséquences importantes (suppression ou modification de données, engagement financier ou juridique, tests en ligne), l'utilisateur doit pouvoir vérifier, modifier, confirmer ou annuler sa saisie avant qu'elle ne devienne définitive.

Comment corriger — Prévoyez une étape de contrôle : page de récapitulatif modifiable, confirmation explicite avant validation, possibilité de revenir en arrière ou de récupérer les données. Évitez toute validation irréversible sans confirmation.

Critère 11.13La finalité d’un champ de saisie peut-elle être déduite pour faciliter le remplissage automatique des champs avec les données de l’utilisateur ?

Ce que ça vérifie — La finalité d'un champ collectant une information sur l'utilisateur (nom, e-mail, téléphone, adresse…) doit pouvoir être déduite par programme, afin que les navigateurs et outils d'aide puissent remplir automatiquement ou adapter la saisie.

Comment corriger — Renseignez l'attribut autocomplete avec la valeur normalisée correspondant à la nature du champ (name, email, tel, postal-code, street-address…). Associez-le à un type d'input adapté.

<label for="tel">Téléphone</label>
<input id="tel" name="tel" type="tel" autocomplete="tel" />
<label for="mail">E-mail</label>
<input id="mail" name="mail" type="email" autocomplete="email" />