Clever Age vous proposait il y a quelque temps un livre blanc sur les formulaires web. Dans la même lignée, amis développeurs front, sachez que l’accessibilité web n’est pas forcément affaire de spécialistes. La plupart des questions peuvent se régler assez facilement. Améliorons à peu de frais l’accessibilité de nos formulaires!
Introduction
Quand on parle d’accessibilité des formulaires, une des règles d’or consiste à utiliser de vrais champs de formulaire.
Par exemple les listes déroulantes chartées aux petits oignons peuvent poser des problèmes importants d’accessibilité. Elles sont souvent constituées d’éléments à faible charge sémantique (des div empilées), l’un pour la zone d’affichage, l’autre pour la zone déroulante. Il faudra mettre en œuvre un nombre conséquent de palliatifs pour atteindre un niveau d’accessibilité similaire à une liste déroulante native.
Dans le cas qui nous concerne, il ne s’agit que de zones de saisie de texte, la moitié du travail est donc déjà faite pour nous : nous n’aurons à convaincre personne de la difficulté de rendre accessibles des éléments natifs HTML, très bien supportés depuis longtemps par les aides techniques.
Contrôler les couleurs, les contrastes, etc.
L’accessibilité n’est pas que pour les aveugles, contrairement à ce que pensent encore de nombreuses personnes. Avant de nous préoccuper de structure et de comportement du formulaire (mais nous y venons plus loin, n’ayez crainte), regardons déjà si les couleurs sont suffisamment utilisables.
Les WCAG (Web Content Accessibility Guidelines, règles d’accessibilité des contenus web), précisent dans les critères de succès liés aux contrastes|critères de succès, en françaisfr :
Oui évidemment dit comme ça c’est un peu aride. Heureusement nous avons des outils pour faire le travail à notre place : [Contrast Analyser|en qui comme son nom ne l’indique pas existe en version française.
Dans le design que nous devons intégrer, les textes des éléments de formulaires sont franchement trop clairs.
La démarche normale pour traiter ce problème est la suivante :
- Faire un design directement contrasté dès la créa, si possible ;
- Montrer les couleurs au client et tâcher de trouver un accord qui satisfasse autant sa charte graphique que l’exigence d’accessibilité ;
- Si le client accepte les couleurs proposées, c’est gagné ;
- Si aucun accord n’est satisfaisant pour le client et si les couleurs posent encore problème : limiter les dégâts.
Nous voici dans un cas où nous ne pouvons pas agir sur ces couleurs((Mais nous alertons notre client pour référence future, on peut ainsi espérer qu’à la prochaine refonte ou évolution il en tiendra compte.)), nous allons donc pallier tant que possible le problème : au survol du champ et quand il aura le focus((Focus : quand on arrive en tabulant dans le champ, ou quand on est en train de faire une saisie dans ce champ, on dit qu’il « a le focus ».)) nous lui donnerons une valeur beaucoup plus contrastée, conforme à nos attentes.
Utiliser les labels
Un élément de formulaire doit toujours comporter une étiquette (un label
)((Au pire, si vous ne pouvez pas du tout mettre de label
, les WCAG permettent maintenant l’usage de l’attribut title
sur l’élément de formulaire concerné. Nous resterons ici dans le cas le plus simple, notre client acceptant que nous rendions les intitulés des champs visibles.)).
Un utilisateur de lecteur d’écran((Je me permets de vous renvoyer à « ARIA », « aides techniques » : c’est quoi tout ça ? pour les définitions.)) aura l’information pertinente : par exemple ci-dessous, mettre le focus sur le champ identifiant nous permettra d’entendre « Identifiant : “toto” ; champ texte ».
Pratiquement c’est très simple à mettre en place :
L’attribut for
du label
pointe vers l’attribut id
du champ texte. Rien de bien sorcier là encore, et le tour est joué.
Valider les champs avec ARIA
Dans un premier temps, à l’aide de JavaScript on a testé si le champ était valide (dans notre exemple il est obligatoire), et, si la condition n’est pas remplie, on met un encadré rouge autour du champ, ainsi qu’un message d’alerte. En passant vous noterez une autre règle d’accessibilité ainsi respectée : l’information ne doit jamais être véhiculée par la couleur seulement. Pensez aux daltoniens, aux personnes qui ont surcontrasté leur écran, désactivant de ce fait les couleurs du site web…
C’est là que nous faisons appel à ARIA|en (Accessible Rich Internet Applications, applications internet riches accessibles) : nous allons enrichir les éléments de notre formulaire pour permettre qu’un utilisateur de lecteur d’écran ait les mêmes informations, le même feedback, que les chanceux qui ont des yeux qui fonctionnent bien.
Alerter l’utilisateur sur les champs non renseignés
Le message qui apparaît lorsque nous sortons du champ et qu’il est resté vide est une simple div
, à laquelle nous affectons un attribut role
qui va d’autorité notifier l’utilisateur que quelque chose d’important requiert son attention.
Indiquez votre identifiant
Ce simple role="alert"
suffit pour que notre utilisateur muni de son lecteur d’écran entende, au moment de la sortie du champ « Indiquez votre identifiant », avant même de lire l’intitulé et la valeur du champ suivant (« Adresse mail : texte »).
Indiquer les champs obligatoires
Quand un champ est obligatoire, il suffit de le déclarer explicitement dans votre HTML à l’aide de l’attribut aria-required
.
De cette manière, le lecteur d’écran va annoncer à votre utilisateur le caractère obligatoire du champ : « Identifiant : champ texte, vide, obligatoire ».
Indiquer un champ invalide
Si le champ est invalide, nous allons pouvoir ajouter un attribut pour le préciser : aria-invalid
qui prend une valeur booléenne (vrai/faux).
Cet attribut sera ajouté dynamiquement si l’utilisateur sort du champ sans l’avoir rempli :
Une fois que le champ comportera une valeur, nous mettrons cet attribut à false
pour dire que le champ est bien valide((Attention, c’est subtil si on n’est pas attentif : la valeur est true
si le champ est invalide et false
si le champ est valide !)) :
Conclusion
Avant tout, nous avons mis en dur aria-required="true"
pour les champs obligatoires.
Au moment où nous sommes sortis de notre champ sans le remplir, notre JavaScript a déduit qu’il n’était pas valide, il a alors :
- ajouté une bordure rouge au champ,
- ajouté une
div
d’alerte à laquelle on a adjoint un attributrole="alert"
, - et ajouté un rôle
aria-invalid
avec la valeurtrue
.
Si nous revenons dans le champ et le remplissons correctement, notre script fera la chose suivante :
- il remettra le style par défaut sur le champ ;
- il supprimera la div d’alerte (c’est bon pour les voyants comme pour les mal- et non-voyants) ;
- il fixera le rôle
aria-invalid
àfalse
((L’attribut d’invalidité est faux puisque le champ est valide, vous me suivez toujours?)).
En conclusion : peu d’efforts pour un bon résultat
Nous l’avons vu, il faut au final assez peu d’effort pour fournir une très bonne accessibilité des champs de formulaire de base :
- nous avons profité du focus et du survol sur le champ pour améliorer ses contrastes
- les développeurs front doivent déjà écrire un script de validation du champ de toute façon, il leur suffit juste d’ajouter quelques lignes supplémentaires et le tour est joué !