Aller au contenu

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)
  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 d'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 le panneau Data (icône d'engrenage), section Attributes, cliquez sur +
  3. Nommez l'attribut id, définissez 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 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 l'élément input
  2. Dans le panneau Data (icône d'engrenage), section Attributes, cliquez sur +
  3. Nommez l'attribut required, définissez la valeur à required
  4. 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, tel, url) et l'attribut 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
email Affiche le clavier e-mail sur mobile, valide le @
tel Affiche le pavé téléphonique sur mobile
url Affiche le clavier URL sur mobile, valide le format
number Affiche le clavier numérique, permet les boutons d'incrémentation
date Affiche le sélecteur de date natif
search Affiche le clavier spécifique à la recherche, bouton d'effacement
password Masque la saisie, déclenche le gestionnaire de mots de passe

Définissez le type de champ dans les réglages de l'élément (icône d'engrenage) quand l'élément input est sélectionné.

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.

  2. Champ nom :

  3. Faites glisser un Label. Texte : « Full name * ». Définissez For : name

  4. Faites glisser un Input. Ajoutez les attributs : id = name, required = required, autocomplete = name

  5. Champ e-mail :

  6. Faites glisser un Label. Texte : « Email address * ». Définissez For : email

  7. Faites glisser un Input. Définissez le type à email. Ajoutez les attributs : id = email, required = required, autocomplete = email

  8. Champ message :

  9. Faites glisser un Label. Texte : « Your message * ». Définissez For : message

  10. Faites glisser un Textarea. Ajoutez les attributs : id = message, required = required

  11. Bouton d'envoi :

  12. Faites glisser un Button. Texte : « Send message »

  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 :

  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

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é.

Éditer cette page sur GitLab