Formulaires accessibles

Les formulaires sont l'endroit où l'accessibilité compte le plus. Un formulaire de contact, un champ de recherche, une inscription à la newsletter -- si un utilisateur ne peut pas comprendre ce qu'attend un champ, ne peut pas identifier les erreurs, ou ne peut pas soumettre le formulaire au clavier, le formulaire est cassé pour lui.

Deux principes directeurs :

1. Chaque champ a besoin d'un label visible. Les placeholders ne sont pas des labels. Les lecteurs d'écran peuvent ne pas annoncer les placeholders, et ceux-ci disparaissent dès que l'utilisateur commence à saisir.
2. Les erreurs doivent être claires et précises. « Une erreur s'est produite » est inutile. « L'adresse e-mail doit contenir un symbole @ » est exploitable.

Étiqueter les champs de formulaire

Chaque <input>, <textarea> et <select> a besoin d'un <label> associé. Le label indique aux lecteurs d'écran à quoi sert le champ. Sans lui, un lecteur d'écran peut annoncer « edit text, blank » -- l'utilisateur n'a aucune idée de ce qu'il doit saisir.

Comment créer un label dans Silex

1. Faites glisser un bloc Label depuis le panneau Blocks (ou faites glisser un bloc Text et changez son Tag Name en LABEL dans les réglages de l'élément, icône engrenage en haut du panneau de droite)
2. Saisissez le texte du label (par exemple, « Email address »)
3. Sélectionnez l'élément label
4. Dans les réglages de l'élément (icône engrenage), un champ For apparaît lorsque la balise est LABEL
5. Saisissez l'id du champ dans le champ For

Pour définir un id sur le champ :

1. Sélectionnez l'élément input
2. Dans les réglages de l'élément (icône engrenage), remplissez le champ ID avec une valeur descriptive (par exemple, email)

Le label et le champ sont désormais liés par programmation. Cliquer sur le label place le focus sur le champ, et les lecteurs d'écran annoncent le texte du label quand le champ reçoit le focus. Le HTML publié contient <label for="email"> et <input id="email">.

Le placeholder n'est pas un label

Le texte du placeholder disparaît quand l'utilisateur saisit. Cela signifie que :

• Les utilisateurs ne peuvent pas revérifier ce qu'attend le champ après avoir commencé à saisir
• Le texte du placeholder a souvent un contraste insuffisant (gris clair)
• Certains lecteurs d'écran n'annoncent pas le texte du placeholder
• Les utilisateurs avec des troubles cognitifs peuvent croire que le champ est déjà rempli

Utilisez les placeholders pour des exemples (« ex. : nom@exemple.com »), pas pour le nom du champ. Ayez toujours un <label> visible.

Regrouper les champs liés

Quand des champs sont liés -- comme prénom et nom, ou un ensemble de boutons radio -- regroupez-les pour que la relation soit claire.

En HTML standard, <fieldset> et <legend> créent des groupes étiquetés. Silex n'a pas de bloc fieldset dédié, mais vous pouvez obtenir le même effet :

1. Entourez les champs liés dans un conteneur
2. Changez le Tag Name du conteneur en SECTION
3. Ajoutez un titre (h2, h3, etc.) comme premier enfant pour décrire le groupe
4. Les lecteurs d'écran annonceront la section et son titre, fournissant du contexte

Pour les boutons radio et les cases à cocher qui forment un groupe (par exemple, « Moyen de contact préféré : E-mail / Téléphone / SMS »), ce regroupement est essentiel -- sans lui, l'utilisateur entend chaque option isolément.

Champs requis

Pour marquer un champ comme requis :

1. Sélectionnez le champ (Input, Textarea, Select, Checkbox ou Radio)
2. Dans les réglages de l'élément (icône engrenage), cochez Required
3. Ajoutez un indicateur visuel à côté du label : un astérisque (*) avec une explication en haut du formulaire (« Les champs marqués d'un * sont requis »)

Ne vous fiez pas à la couleur seule (par exemple, une bordure rouge) pour indiquer les champs requis. Voir Texte, contraste et lisibilité pour comprendre pourquoi.

Autocomplete

L'attribut autocomplete aide les navigateurs et les gestionnaires de mots de passe à remplir automatiquement les champs courants. C'est particulièrement important pour les utilisateurs avec des troubles moteurs ou cognitifs -- moins de frappes signifie moins d'erreurs.

Ajoutez autocomplete via la section Attributes :

Champ	Valeur autocomplete
Nom complet	name
E-mail	email
Téléphone	tel
Adresse (rue)	street-address
Ville	address-level2
Code postal	postal-code
Pays	country
Numéro de carte bancaire	cc-number
Nom d'utilisateur	username
Mot de passe actuel	current-password
Nouveau mot de passe	new-password

Pour l'ajouter :

1. Sélectionnez le champ input
2. Dans la section Attributes, cliquez sur +
3. Nommez l'attribut autocomplete
4. Définissez la valeur (par exemple, email)

Messages d'erreur

Quand la validation d'un formulaire échoue, les messages d'erreur doivent être :

• Visibles -- pas seulement un changement de couleur, pas cachés dans une info-bulle
• Précis -- « L'adresse e-mail doit contenir un symbole @ » et non « Saisie invalide »
• Associés au champ -- placés près du champ, idéalement juste en dessous

Pour la validation côté client, les navigateurs modernes gèrent la validation de base automatiquement quand vous utilisez les bons types de champ (email, number) et cochez Required. Le navigateur affiche des messages d'erreur natifs qui sont déjà accessibles.

Pour une validation personnalisée en JavaScript (via Code personnalisé), associez les messages d'erreur aux champs avec aria-describedby :

1. Ajoutez un élément texte sous le champ pour le message d'erreur
2. Donnez à l'élément d'erreur un id (via la section Attributes) : par exemple, email-error
3. Sur le champ, ajoutez un attribut aria-describedby (via la section Attributes) avec l'id de l'élément d'erreur : email-error
4. Les lecteurs d'écran annonceront le texte d'erreur quand le champ est ciblé

Types de champ

Utiliser le bon type de champ améliore l'accessibilité et l'utilisabilité :

Type	Effet
text	N'importe quel texte (par défaut)
email	Affiche le clavier e-mail sur mobile, valide le @
number	Affiche le clavier numérique, permet les boutons d'incrémentation
password	Masque la saisie, déclenche le gestionnaire de mots de passe

Définissez le type de champ dans le menu Type des réglages de l'élément (icône engrenage) quand l'élément input est sélectionné. Le menu ne propose que ces quatre types.

Exemple pratique : formulaire de contact accessible

Vous construisez un formulaire de contact avec nom, e-mail, message et bouton d'envoi.

1. Conteneur du formulaire : faites glisser un bloc Form. L'élément <form> est déjà correct. Il arrive avec des champs d'exemple (Name, Email, cases Gender, Message et un bouton Send) : réutilisez-les et supprimez la ligne Gender.

2. Champ nom :

3. Label : double-cliquez dessus et tapez « Full name * ». Dans les réglages de l'élément, définissez For : name

4. Input : réglez ID sur name et cochez Required dans les réglages de l'élément. Dans Attributes, cliquez sur +, nommez-le autocomplete et donnez-lui la valeur name

5. Champ e-mail :

6. Label : « Email address * », For : email

7. Input : son Type est déjà email. Réglez ID sur email, cochez Required et ajoutez l'attribut autocomplete = email

8. Champ message :

9. Label : « Your message * », For : message

10. Textarea : réglez ID sur message et cochez Required

11. Bouton d'envoi :

12. Sélectionnez le bouton. Dans les réglages de l'élément, réglez Text sur « Send message » et Type sur submit : le bouton du bloc Form est de type button, qui n'envoie pas le formulaire et ne déclenche pas la validation

13. L'élément <button> est déjà accessible au clavier

14. Mention des champs requis :

15. Ajoutez un élément Text au-dessus du premier champ : « Les champs marqués d'un * sont requis »

16. Test (sur la page publiée : dans l'éditeur, même en aperçu, Tab ne déplace pas le focus entre les champs) :

17. Tabulez à travers le formulaire : chaque champ doit recevoir le focus dans l'ordre
18. Le lecteur d'écran doit annoncer : « Full name, required, edit text » pour le premier champ
19. Soumettez avec des champs vides : le navigateur doit afficher les messages de validation

Erreurs courantes

• Aucun label sur les champs. L'échec d'accessibilité de formulaire le plus courant. Chaque champ a besoin d'un <label> avec un attribut for correspondant.
• Le placeholder comme unique label. Le texte du placeholder disparaît à la saisie, a un contraste faible et peut ne pas être annoncé par les lecteurs d'écran.
• Champs requis indiqués uniquement par la couleur. Ajoutez du texte (« required » ou « * » avec explication) en plus de tout indicateur de couleur.
• Messages d'erreur génériques. « Erreur » ou « Saisie invalide » n'aide pas l'utilisateur à corriger le problème. Soyez précis.
• Pas d'autocomplete. Les utilisateurs avec des troubles moteurs profitent grandement de l'autocomplete. Ajoutez l'attribut aux champs standard.
• Types de champ incorrects. Utiliser type="text" pour un e-mail signifie pas de clavier e-mail sur mobile et pas de validation par le navigateur. Utilisez le bon type.

Pour aller plus loin

• MDN : Accessibilité des formulaires web -- structurer les formulaires de façon accessible
• MDN : L'élément label -- référence du label
• MDN : L'attribut autocomplete -- toutes les valeurs autocomplete
• WebAIM : Creating Accessible Forms -- guide complet
• Formulaires -- les bases des formulaires dans Silex
• HTML sémantique -- la balise LABEL et l'attribut For

---

Référence : résumé des exigences WCAG sur les formulaires

Critère	Niveau	Exigence
1.3.1 Info et relations	A	Les labels, instructions et regroupements sont associés par programmation
1.3.5 Identifier la finalité de la saisie	AA	La finalité de la saisie est déterminable par programmation (autocomplete)
2.4.6 En-têtes et labels	AA	Les labels décrivent le sujet ou la finalité
3.3.1 Identification des erreurs	A	Les erreurs sont identifiées et décrites en texte
3.3.2 Labels ou instructions	A	Des labels ou instructions sont fournis pour la saisie
3.3.3 Suggestion après une erreur	AA	Des suggestions de correction des erreurs sont fournies

---

Quiz

Q1 : Un champ de formulaire a un placeholder « Enter your email » mais pas d'élément <label>. Un utilisateur de lecteur d'écran place le focus sur le champ. Qu'entend-il ?

• A) « Enter your email, edit text »
• B) « Edit text, blank » (le placeholder peut ne pas être annoncé)
• C) « Email, required, edit text »

Réponse

B) « Edit text, blank » -- certains lecteurs d'écran n'annoncent pas le texte du placeholder. Sans <label>, l'utilisateur n'a aucun moyen de savoir ce qu'attend le champ. Utilisez toujours un label visible.

Q2 : Vous voulez marquer un champ comme requis. Quelle approche est la plus accessible ?

• A) Bordure rouge uniquement
• B) Bordure rouge + astérisque (*) dans le label + « Les champs marqués d'un * sont requis » en haut + attribut required
• C) Texte de placeholder indiquant « Requis »

Réponse

B) Bordure rouge + astérisque + explication + attribut required -- cela couvre tous les utilisateurs : visuel (bordure rouge + astérisque), textuel (explication) et programmatique (l'attribut required informe les navigateurs et les lecteurs d'écran).

Q3 : Un formulaire de contact a des champs pour le nom, l'e-mail et le téléphone, mais aucun attribut autocomplete. Qui est le plus affecté ?

• A) Les utilisateurs voyants avec une souris
• B) Les utilisateurs avec des troubles moteurs qui peinent à saisir
• C) Les utilisateurs de lecteur d'écran

Réponse

B) Les utilisateurs avec des troubles moteurs -- autocomplete réduit le nombre de frappes nécessaires. Pour les utilisateurs qui trouvent la saisie physiquement difficile, c'est une amélioration significative de l'utilisabilité.