Accueil > Veille > Notre blog de veille > Améliorer l’accessibilité d’un formulaire

Améliorer l’accessibilité d’un formulaire

Stéphane Deschamps 7 mars 2013
9 commentaires

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 :

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

Un champ par défaut : les contrastes sont insuffisants

La démarche normale pour traiter ce problème est la suivante :

  1. Faire un design directement contrasté dès la créa, si possible ;
  2. Montrer les couleurs au client et tâcher de trouver un accord qui satisfasse autant sa charte graphique que l’exigence d’accessibilité ;
  3. Si le client accepte les couleurs proposées, c’est gagné ;
  4. 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 [1], nous allons donc pallier tant que possible le problème : au survol du champ et quand il aura le focus [2] nous lui donnerons une valeur beaucoup plus contrastée, conforme à nos attentes.

Un champ qui a le focus : contrastes suffisants

Utiliser les labels

Un élément de formulaire doit toujours comporter une étiquette (un label) [3].

Un utilisateur de lecteur d’écran [4] 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 :

  1. <label for="login">Identifiant</label>
  2. <input type="text" name="login" id="login" 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 (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.

  1. role="alert"
  2. class="info-required">Indiquez votre identifiant</div>

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.

  1. <input type="text"
  2. aria-required="true"
  3. value="" id="login" name="login">

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 :

  1. <input type="text"
  2. aria-required="true"
  3. value="" id="login" name="login"
  4. aria-invalid="true">

Une fois que le champ comportera une valeur, nous mettrons cet attribut à false pour dire que le champ est bien valide [5] :

  1. <input type="text"
  2. aria-required="true"
  3. value="" id="login" name="login"
  4. aria-invalid="false">

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 :

  1. ajouté une bordure rouge au champ,
  2. ajouté une div d’alerte à laquelle on a adjoint un attribut role="alert",
  3. 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 :

  1. il remettra le style par défaut sur le champ ;
  2. il supprimera la div d’alerte (c’est bon pour les voyants comme pour les mal- et non-voyants) ;
  3. il fixera le rôle aria-invalid à false [6]. 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é !

[1] 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.

[2] 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 ».

[3] 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.

[4] Je me permets de vous renvoyer à « ARIA », « aides techniques » : c’est quoi tout ça ? pour les définitions.

[5] 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 !

[6] L’attribut d’invalidité est faux puisque le champ est valide, vous me suivez toujours ?

Accessibilité, HTML, Clever Garden, ARIA, WCAG

Par Stéphane Deschamps

 

9 commentaires

  • Thomas Geisen
    7/03/2013 - 10:17

    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.

  • lionelB
    7/03/2013 - 10:27

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

  • Stéphane Deschamps
    7/03/2013 - 10:52

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

  • lionelB
    7/03/2013 - 11:03

    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

  • Stéphane Deschamps
    7/03/2013 - 11:08

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

  • Nico Catherin
    7/03/2013 - 11:24

    @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 »).

  • eviouchka
    10/09/2013 - 15:16

    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.

  • Olivier Keul
    10/09/2013 - 16:39

    @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 :

    _
    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é)

  • eviouchka
    11/09/2013 - 10:41

    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