Formulaires et gestion des erreurs

De nombreux sites et applications Web contiennent des formulaires permettant aux utilisateurs de se connecter, s'inscrire, de commander des produits, ou laisser des commentaires. Ces formulaires proposent souvent une gestion d'erreurs.

A quoi ressemblent un message d'erreur ?

Le formulaire de contact qui suit montre un message d'erreur généré lorsqu'il y a une erreur à la soumission du formulaire. Le lecteur d'écran NVDA est activé pour montrer la manière dont les utilisateurs non-voyants accèdent à ces informations.

Quelles sont les difficultés rencontrées par les utilisateurs face aux formulaires ?

Les formulaires posent de nombreuses difficultés aux utilisateurs en situation de handicap.

Les utilisateurs mal-voyants ont plus de difficultés pour localiser les formulaires, ou ensuite pour comprendre quelles informations sont demandées lorsque les étiquettes sont coupées ou le taux de contraste insuffisant.

Les utilisateurs de lecteurs d'écran se trouvent souvent face à des champs sans étiquette. La gestion des erreurs peut être particulièrement problématique pour ces utilisateurs car l'erreur n'est pas toujours signalée, ou localisée sur le formulaire. Sur de nombreux sites ces messages ou indications sont purement visuels et ne sont pas accessibles aux utilisateurs non-voyants qui ne peuvent pas savoir ou deviner ce qu'il s'est passé.

Quand les étiquettes ne sont pas faciles à comprendre, les utilisateurs avec un handicap cognitif peuvent avoir du mal à renseigner les formulaires. L'utilisation de jargon technique ou l'absence d'éléments d'aide posent également problème, tout comme la manque d'indications sur le format de saisie attendu.

Les erreurs de saisie sont très courantes. Une bonne gestion des erreurs est donc très importante. Quelques exemples de situations nécessitant un message d'erreur:

• L'utilisateur ne renseigne pas l'ensemble des champs obligatoires.
• L'utilisateur ne souhaite pas renseigner l'ensemble des champs et laissent volontairement quelques champs vide.
• L'utilisateur introduit une erreur de saisie dans un champ avec un contrôle de saisie (adresse email invalide, mot de passe qui ne correspond pas)
• L'utilisateur utilise un format de saisie qui n'est pas reconnu par le formulaire (par exemple un champ "date de naissance" ou l'utilisateur tape 27.10.1995 au lieu de 27/10/1995)

Dans cet exemple, un utilisateur de logiciel d'agrandissement essaie de localiser le champ de recherche en haut à droit de l'écran, et pense l'avoir trouvé jusqu’à ce qu'il se rende compte, en zoomant, qu'il s'est trompé.

Dans cet exemple, un utilisateur de logiciel d'agrandissement essaie de localiser le champ de recherche. L'étiquette se limite à un placeholder tronqué avec un taux de contraste insuffisant.

Souvent, le texte du placeholder a un taux de contraste insuffisant. Sur un écran portable, le placeholder fait souvent office d'étiquette.

Dans cet exemple, un formulaire permettant de signaler des fautes techniques de feux a des étiquettes en jargon technique qui sont difficiles à comprendre.

Dans cet exemple, il y a une indication visuelle à côté du champ relatif au mot de passe, qui précise que le mot de passe doit être composé d'au moins 8 caractères dont un chiffre et un caractère spéciale. Cette information n'est pas donnée aux utilisateurs naviguant au lecteur d'écran.

Comment créer des formulaires et des messages d'erreurs accessibles ?

• Faire en sorte que les champs de saisie ont des étiquettes claires. Indiquer le format attendu à côté du champ de saisie (exemple : pour un champ date DD.MM.AAAA).
• Placer l'étiquette en haut ou à gauche du champ de saisie (ou à droit pour les cases à cocher et les boutons radio).
• Vérifier que les étiquettes sont correctement reliées aux champs de saisie, en utilisant, par exemple l'élément label qui est a un id unique qui est référencé au champ via l'attribut for.
• N'utiliser pas le placholder comme étiquette. L'attribut placehoder disparait lorsque l'utilisateur renseigne le champ. S'il faut gagner de la place, il faut utiliser des étiquettes flottantes accessibles (voir la partie Ressources).
• Utiliser les attributs fieldset et legend pour donner du contexte aux champs si besoin - par exemple pour distinguer entre l'adresse de facturation et le destinataire, ou pour donner du contexte aux groupes de boutons radio qui ne sont pas pour lesquels les étiquettes ne sont pas suffisantes à elles seules.
• Utiliser l'attribut HTML type pour les champs ou les utilisateurs doivent respecter un format de données, comme un numéro de téléphone, une adresse mail ou un mot de passe.
• Ne compter pas uniquement sur la gestion automatique des messages d'erreur HTML5 via l'attribut required - ces messages sont génériques et disparaissent après peu de temps.
• N'utiliser pas que la couleur pour indiquer les champs qui contient une erreur (par exemple en passant les étiquettes des champs concernés en rouge).
• Vérifier que les messages d'erreur ont un taux de contraste correcte. Utiliser de la couleur et des icônes pour faire en sorte que les messages d'erreur soient bien visibles.
• Si des messages d'erreur sont générés à proximité du champ de saisie, vérifier qu'ils soient correctement reliés (mettre à jour l'élément label ou l'intitulé de lien via aria-describedby) pour que l'information soit communiquée par le lecteur d'écran à la prise de focus.
• Si les messages apparaissent après la validation du formulaire, le focus doit se trouver sur le premier champ qui contient une erreur s'il n'y a pas de liste d'erreurs proposée en début de formulaire.
• Si une liste d'erreurs est proposée après soumission, faire en sorte qu'elle figure en début de formulaire, et que le focus se positionne sur le premier élément de la liste, avec une lien entre chaque message d'erreur et le champ correspondant.

Nouveaux critères d'accessibilité relatifs aux formulaires dans les WCAG 2.1

Dans la dernière version des Web Content Accessibility Guidelines, WCAG 2.1, il y a deux nouveaux critères concernant les formulaires.

Fonction des contrôles

Le nouveau critère 1.3.5 Identify Input Purpose nécessite que la fonction des champs relatifs aux informations concernant l'utilisateur (par exemple nom, adresse, numéro de téléphone, etc.) doit être correctement indiquée. Cela permettra de mieux informer les utilisateurs de technologies d'assistance. Une étiquette textuelle, par exemple, peut être complétée par une image qui permettrait aux utilisateurs en situation de handicap cognitif de mieux comprendre l'information demandée.

Actuellement, la meilleur manière d'identifier la fonction est via l'attribut HTML5 autocomplete. Le critère Understanding text for 1.3.5 Identify Input Purpose donne plus d'informations. Les techniques de ce critère sont en cours d'élaboration.

Messages relatifs au statut du formulaire

Certains formulaires se mettent à jour dynamiquement au fur et à mesure que l'utilisateur renseigne les champs. Dans ces cas, des indications visuelles du statut de la page sont en général données. Exemple de message : "Merci, votre formulaire a été validé".

Même chose pour une mise à jour automatique du formulaire suite à la sélection de critères de recherche ou de cases à cocher.

Le nouveau critère 4.1.3 Status Messages stipule que ces messages visuels doivent être correctement codés pour que les utilisateurs de technologies d'assistance se rendent compte de ces modifications. L'attribut aria-live permet de restituer ces messages. Pour plus d'informations, voir Understanding Text for 4.1.3 Status Messages.

Pour aller plus loin (ressources en anglais)

• Forms Concepts (WAI Web Accessibility Tutorials, 2018)
• Usable and Accessible Form Validation and Error Recovery (Webaim, 2013)
• Simple inline error message pattern (Steve Faulkner, Paciello Group, 2016)
• How to Provide Accessible Error Identification (Jonathan Avila, LevelAccess, 2014)
• Accessible floating labels (Matt Smith, 2016) - attention : les étiquettes des exemples ont un taux de contraste insuffisant.
• Float label pattern (Brad Frost, 2013) - attention : les étiquettes des exemples ont un taux de contraste insuffisant.
• Native form validation 1: UI and CSS (Peter Paul Koch, quirksmode, 2017). Un article détaillé en trois parties sur les différentes manières de gérer les erreurs nativement via HTML, CSS, et JavaScript, et les conflits qui en résultent.
• Native form validation 2: HTML and JavaScript (Peter Paul Koch, quirksmode, 2017).
• Native form validation 3: Error messages and recommendations (Peter Paul Koch, quirksmode, 2017).
• HTML 5 specification: Autofilling form controls: the autocomplete attribute