Améliorer l’accessibilité d’un formulaire

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 :

SC 1.4.3 Contraste (minimum) : la présentation visuelle du texte et du texte sous forme d’image a un rapport de contraste d’au moins 4,5:1, sauf dans les cas suivants : (Niveau AA) Texte agrandi : le texte agrandi et le texte agrandi sous forme d’image ont un rapport de contraste d’au moins 3:1…].

SC 1.4.6 Contraste (amélioré) : la présentation visuelle du texte et du texte sous forme d’image a un rapport de contraste d’au moins 7:1, sauf dans les cas suivants : (Niveau AAA) Texte agrandi : le texte agrandi et le texte agrandi sous forme d’image ont un rapport de contraste d’au moins 4,5:1 […].

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 :


<label for="login">Identifiant</label>
<input id="login" name="login" type="text" value="" />

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.


<input id="login" name="login" type="text" value="" />

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 :

<input id="login" name="login" type="text" value="" />

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 !)) :


<input id="login" name="login" type="text" value="" />

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 attribut role="alert",
  • et ajouté un rôle aria-invalid avec la valeur true.

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

9 commentaires

  1. Thomas Geisen

    7 mars 2013

    Excellent article concis, mêlant théorie et pratique ! Je tâcherai de faire de même pour ma prochaine intégration de formulaire, surtout pour les attributs ARIA, sur lesquels je n’étais absolument pas à jour.

    Ces temps-ci, j’ai l’impression que les articles sur ARIA et l’accessibilité web se multiplient. On donc peut espérer que l’accessibilité des sites produits en France s’améliore un peu, et je vais essayer d’y contribuer !

    Aussi, je n’avais jamais vu votre livre blanc sur les formulaires web, ça va me faire un peu de lecture utile.

  2. lionelB

    7 mars 2013

    Bonjour,
    Est ce qu’on peut aussi utiliser le role= »alert » pour signifier que l’action du formulaire s’est bien déroulé ?
    Merci.

  3. Stéphane Deschamps

    7 mars 2013

    @lionelB : non, ce n’est pas forcément conseillé.

    Après tout, si le formulaire a été bien rempli, l’expérience utilisateur attendue c’est justement qu’on ne me dise rien : je n’ai plus qu’à soumettre le formulaire et à passer à l’étape suivante.

  4. lionelB

    7 mars 2013

    Merci pour ta réponse. En fait, je pensais à la petite phrase (souvent en vert) qui conclue l’action du formulaire et qui est ajoutée de la même manière que lorsqu’il y a une erreur de validation. C’est souvent le cas dans un formulaire avec de l’ajax.

    Est ce qu’il y a un rôle qui serait plus à propos à ajouter pour ce genre de phrase de confirmation ?

    Lionel

  5. Stéphane Deschamps

    7 mars 2013

    @lionelB : ça demande réflexion, le plus simple peut être de mettre le focus sur cette phrase pour être sûr que l’utilisateur la lise.

  6. Nico Catherin

    7 mars 2013

    @LionelB

    Pour qu’une confirmation soit visible, on recommande plutôt d’afficher une page spécifique dont le titre majeur signifie cette réussite.

    Un role= »alert » affichera ton formulaire et va, pour les lecteurs d’écran, interrompre la lecture de utilisateur pour imposer cette phrase.
    Intrusive pour certain, potentiellement peu visible pour d’autres, elle risque d’occasionner de la frustration que l’on peut facilement éviter.

    Je pense que « role » n’est pas approprié, à moins qu’un role= »confirm » ne voit le jour ;-)

    Tu pourrais également profiter de la page de confirmation pour proposer du contenu alternatif ou complémentaire, et inviter ton utilisateur à poursuivre son expérience sur ton produit (pour éviter le « cul-de-sac »).

  7. eviouchka

    10 septembre 2013

    très très bon article, utile et simplement expliqué, merci beaucoup!
    j’ai cependant une question : quel niveau d’accessibilité a t-on si on rempli toutes les conditions citées ici ? Argent (AA)? Or (AAA)?

    merci d’avance si vous pouvez m’éclairer.

  8. Olivier Keul

    10 septembre 2013

    @eviouchka

    Afin d’éviter toute confusion, il est important de préciser que les formulaires représentent une seule thématique. Un niveau Or (Accessiweb) ou AAA (RGAA/WCAG) sur la thématique des formulaires n’indique en rien le niveau général d’accessibilité.

    Pour revenir à l’article de Stéphane il parle un peu de tout, sans forcément s’appuyer sur des critères précis. Il donne des astuces qui permettront d’améliorer rapidement l’accessibilité. Ce n’est pas exhaustif, c’est plus à considérer comme une première étape dans la prise en compte de l’accessibilité. Par exemple il ne mentionne pas le critère 11.4 Accessiweb de niveau Bronze « Dans chaque formulaire, chaque étiquette de champ et son champ associé sont-ils accolés ? » (équivalent au critère de succès 3.3.2 de WCAG 2.0).

    En d’autres termes, en suivant cet article vous pourrez améliorer l’accessibilité de vos formulaires mais vous ne pourrez pas forcément prétendre à tel ou tel niveau. Si c’est votre objectif je vous invite à consulter ses 2 ressources :

    – Le référentiel Accessiweb 2.2
    – Le Référentiel général d’accessibilité pour les administrations (RGAA 2.2.1)

    Dans le premier lien par exemple vous trouverez la thématique formulaire avec l’ensemble des critères de succès ainsi que les niveaux.

    ps : ces 2 référentiels français (Accessiweb et RGAA) sont une traduction et une interprétation des WCAG 2.0 (recommandations internationales d’accessibilité)

  9. eviouchka

    11 septembre 2013

    Merci beaucoup pour la réponse et les liens fournis, c’est exactement ce dont j’avais besoin !
    Faire de l’accessiweb est à mon sens autant une réflexion sur la conception web que sur l’utilité d’exercer cette profession pour ouvrir une fenêtre sur le monde au plus grand nombre.
    Mon objectif n’est donc pas d’avoir tel ou tel niveau (par contre c’est celui de mes clients ;) ) histoire de pouvoir brillamment l’afficher sur mon site mais plutôt de savoir si une personne ayant déjà des difficultés personnelles dans sa vie verra ses attentes satisfaites ou simplifiées par un travail fait correctement.
    Et dans cette perspective, merci à Stéphane car ses explications sont très claires et simples pour mettre en œuvre concrètement ce qui touche à l’accessibilité d’un formulaire.

    Bonne continuation a tous

Les commentaires sont désormais fermés.