Concevoir des formulaires ergonomiques et accessibles

Dans cet article nous allons voir quelques points qui pourront nous aider à concevoir des formulaires ergonomiques et accessibles. La première partie concerne la phase de conception graphique, la seconde nécessite une connaissance du HTML car elle est technique.

Aperçu de l'application Ecoquartier

Premières questions du formulaire de candidature à l'appel à projets Ecoquartier

Dans un précédent article sur l’accessibilité des sites Web nous avons vu qu’il était facile de créer un site accessible s’il est assez simple. Cela nécessite un tout petit peu de réflexion pendant la phase de création et une syntaxe HTML impeccable, ce qui n’est pas insurmontable.

Cependant, les choses se compliquent pour les formulaires – surtout lorsqu’ils sont complexes – ainsi que pour les applications riches.

Pour ces types d’interfaces, plusieurs problèmes d’accessibilité se posent :

  • La syntaxe HTML est trop limitée pour décrire certains éléments d’interfaces et leurs comportements
  • Il n’est pas toujours évident de choisir la bonne syntaxe HTML pour les éléments complexes,
  • Les technologies d’assistance sont nombreuses et leurs fonctionnalités varient. De plus, il existe de nombreuses combinaisons possibles de versions de navigateurs et de ces technologies,
  • Ces technologies d’assistance ne sont pas souvent en mesure de signaler le changement d’état d’un élément de l’application utilisant AJAX.

Comment pallier à ces problèmes ? Le sujet étant vaste, nous nous concentrerons ici sur les formulaires en général. Mais d’abord un petit rappel… Qu’est-ce que l’accessibilité et pourquoi est-ce important d’y penser ?

Pourquoi rendre son site ou application accessible ?

La raison noble

La raison la plus noble est exprimée par Tim Berners Lee, inventeur du World Wide Web :

Le pouvoir du Web est son Universalité. Qu’il soit accessible par n’importe qui quel que soit son handicap est un de ses aspects essentiels

Si l’on adhère à cette idée que le web est un lieu de partage et de mise en commun des connaissances, il paraît essentiel de permettre à tous d’y accéder, sans discrimination (si ce n’est qu’il faut tout de même posséder un ordinateur et une connexion à Internet).

La raison chiffrée

Si cet argument ne vous suffit pas, sachez que 10 à 15% de la population européenne est considérée comme handicapée selon l’Assemblée Parlementaire du Conseil de l’Europe.
Cela représente une part non négligeable de vos clients potentiels. Ces personnes sont probablement encore plus susceptibles que les autres d’utiliser l’Internet pour s’informer, communiquer et consommer puisqu’elles peuvent le faire avec leurs outils, dans le confort de leur foyer ou de leur bureau.

Le rôle majeur des formulaires

aperçu d'un formulaire de Facebook

Dans son livre Web Form Design, Filling the blanks, Luke Wroblewski met en évidence l’importance des formulaires sur le web : afin de faire un achat sur un site de ecommerce, il faut passer par un formulaire ; pour pouvoir interagir avec ses amis sur un réseau social, à nouveau des formulaires ; dans des applications web de collaboration professionnelle, les formulaires sont encore une fois incontournables.

Ayant débuté ma carrière dans le ecommerce, je sais combien les choix ergonomiques sont difficiles lorsque l’on veut faciliter la tâche à un utilisateur pour une transaction tout en « capturant » certaines données et en lui donnant envie de revenir sur le site par la suite.

Cependant, c’est surtout en tant qu’internaute qu’on se rend compte de l’importance des formulaires. Qui n’a pas abandonné une transaction par exaspération ? Qui n’a pas pensé « oh non… un formulaire » et mentalement croisé les doigts pour que tout se passe vite et bien ?

Wroblewski confirme que personne n’aime les formulaires, et c’est pour cette raison qu’il faut les rendre les plus simples et explicites possibles.

Homme stressé

Un internaute qui s’arrache les cheveux face à votre formulaire est un internaute stressé, pour qui l’image de votre marque sera altérée à jamais. Il est possible qu’il ne revienne pas sur votre site à cause d’une mauvaise expérience utilisateur.

Un travail sur l’ergonomie des formulaires sera bénéfique à tous les utilisateurs et rendra service à votre marque. Le livre de Wroblewski présente quelques cas pratiques où parfois un simple changement d’intitulé ou de couleur d’un bouton ont permis une augmentation fulgurante du chiffre d’affaire de l’entreprise.

Quelques astuces pour une meilleure ergonomie de vos formulaires

Entrons dans le vif du sujet avec quelques astuces pratiques pour le positionnement et les styles des éléments de formulaire.

  • Positionnement du label

    A une époque j’étais persuadée, après avoir lu quelques articles sur le sujet, qu’il fallait que le label se situe à gauche du champ et qu’il soit aligné à droite. Ce n’était pas toujours très pratique.Site de Campaign MonitorEn fait, tous les spécialistes s’accordent pour dire que le choix du positionnement du label associé à un élément de formulaire dépend du contexte. Les trois options valables sont :

    • label à gauche, texte aligné à gauche,
    • label à gauche, texte aligné à droite
    • label au dessus (aligné à gauche)

    Ces trois options constituent des choix ergonomiques totalement acceptables, cependant en termes d’accessibilité, il semblerait que la troisième option soit la meilleure dans la majorité des cas.

    En effet, il sera beaucoup plus confortable pour un utilisateur de loupe d’écran de voir le label et son élément de formulaire associé alignés à gauche. De cette manière ils n’auront pas besoin d’aller voir ce qui se passe plus à droite.

  • Une seule colonne

    Pour la même raison, il est préférable que le formulaire se déroule sur une seule colonne car s’il y en a plusieurs, certains utilisateurs seraient susceptibles de passer à côté de certaines d’entre elles.Il en va de même pour les messages d’erreur qu’il faut éviter de positionner à droite du formulaire.

  • Signaler les erreurs de plusieurs manières

    Message d'erreur du site FoxycartPour signaler une erreur, on utilise souvent la couleur rouge. C’est une convention que l’on peut appliquer sans problème, à condition de ne pas tout miser dessus : pensons aux utilisateurs qui ont des troubles de la vision des couleurs et ajoutons une icône par exemple. On choisira de préférence un fond rouge pale avec du texte foncé plutôt que du texte rouge vif en petits caractères, afin d’optimiser la lisibilité.

    Note sur les erreurs : bien penser ses messages d’erreurs est essentiel, mais les éviter est encore une bien meilleure option. Faites tout pour que votre formulaire soit indulgent, en éliminant les espaces et les caractères indésirables côté serveur pour un numéro de téléphone par exemple, ou encore en acceptant plusieurs formats de date.

Accessibilité des formulaires : quel code ?

Nous avons parcouru quelques règles d’ergonomie qui seront bénéfique à tous les utilisateurs voyants ou mal-voyants. Cependant, l’expérience utilisateur des personnes faisant usage de lecteurs d’écrans sera en grande partie dépendante du code de la page web. Comment rendre ses formulaires accessibles ?

  • Toujours utiliser un label

    Chaque élément de formulaire (champ texte, case à cocher, menu déroulant…) doit avoir un label associé. Parfois on ne souhaite pas afficher de label car il créerait une redondance. Dans ce cas, on utilise quand même un label mais on le masque avec CSS.

    Attention ! Ne pas utiliser display: none car cela masquerait l’élément des lecteurs d’écran aussi.J’utilise les définitions suivantes (tirées de HTML5 Boilerplatepar Paul Irish) :

      .visuallyhidden {
       position: absolute !important;
       clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
       clip: rect(1px, 1px, 1px, 1px); }

    Si on ne peut vraiment pas utiliser de <label>, alors il faut ajouter un attribut title à l’élément de formulaire car c’est ce que la plupart des lecteurs d’écrans chercheront en second.

  • Fieldset & Legend

    Avant de regarder la conférence vidéo In Top Form: Designing and Building Accessible Forms de Derek Featherstone, j’étais persuadée que l’utilisation de <fieldset> et <legend> était le top du top des meilleures pratiques. De plus, j’avais lu quelque part qu’on était dans l’obligation d’utiliser <fieldset> et <legend> ensemble à tous les coups.

    La vérité est en fait plus nuancée. Comme pour beaucoup de choses en matière d’ergonomie, d’accessibilité et de code, nos choix doivent dépendre du contexte.Le problème du tag <legend> est que certains lecteurs d’écran vont le lire avant chaque <label> du <fieldset>.Considérons ce petit formulaire :

    <fieldset>
      <legend>Caractéristiques de votre projet</legend>
    
      <label for="nomDuProjet">Nom de votre projet</label>
      <input type="text" id="nomDuProjet" name="nomDuProjet" />
    
      <span>Type de projet</span>
    
      <input type="radio" id="typeWeb" name="projectType" />
      <label for="typeWeb">Web</label>
    
      <input type="radio" id="typePrint" name="projectType" />
      <label for="typePrint">Print</label>
    
      <input type="radio" id="typeVideo" name="projectType" />
      <label for="typeVideo">Vidéo</label>
      …
    </fieldset>

    Le problème de ce formulaire c’est qu’il crée trop d’accessibilité car certains lecteurs d’écrans répéteront le contenu du <legend> avant chacun des <label> comme ceci : « Caractéristiques de votre projet, Nom de votre projet, champ texte. Caractéristiques de votre projet, Web, bouton radio. Caractéristiques de votre projet, print, bouton radio, Caractéristiques de votre projet, vidéo, bouton radio. »

    On comprend bien que ça doit être très agaçant à entendre, surtout si le formulaire est long…

    Alors que faire ? Les auteurs de Fancy Form Design suggèrent de garder le tag <fieldset> mais de substituer un titre au <legend> dans des cas de figure tels que celui que nous venons d’évoquer.

  • L’importance du choix du texte

    Vous avez peut-être remarqué un autre souci avec le code du formulaire que nous venons d’examiner. Avant les trois boutons radio, l’intitulé qui correspond à ce groupe est dans un <span>. Il est peu probable que l’utilisateur entende son contenu en mode formulaire.Une méthode judicieuse suggérée par Derek Featherstone dans son tutoriel vidéo consiste à ajouter un intitulé au début du label du premier élément de la liste. Reprenons notre exemple pour illustrer cette technique :

    <fieldset>
      <h3>Caractéristiques de votre projet</h3>
    
      <label for="nomDuProjet">Nom de votre projet</label>
      <input type="text" id="nomDuProjet" name="nomDuProjet" />
    
      <span>Type de projet</span>
    
      <input type="radio" id="typeWeb" name="projectType" />
      <label for="typeWeb"><span class="visuallyhidden">Projet de type : </span>Web</label>
    
      <input type="radio" id="typePrint" name="projectType" />
      <label for="typePrint">Print</label>
    
      <input type="radio" id="typeVideo" name="projectType" />
      <label for="typeVideo">Vidéo</label>
    …
    </fieldset>

    Le label correspondant au premier bouton radio contient un <span> dont le contenu sera lu par les lecteurs d’écrans tout en étant invisible à l’écran grâce à la classe .visuallyhidden expliquée auparavant.

    Voici ce qu’un lecteur d’écran devrait dire (approximativement) en mode formulaires : « Nom de votre projet, champ texte. Projet de type : web, bouton radio ; print, bouton radio ; vidéo, bouton radio. »

    Cette lecture est beaucoup plus satisfaisante car elle est claire et succincte.

    Il s’agit donc de faire preuve de bon sens et de réfléchir aux intitulés les plus pertinents pour les utilisateurs de lecteurs d’écrans comme pour les autres.

  • Messages d’erreur et d’avertissement

    Une bonne pratique consiste à mettre les messages d’erreur ainsi que certaines instructions dans un <em> ou <strong> à l’intérieur du <label>. Ce tag peut éventuellement être masqué à l’écran. Dans le cas d’une erreur, on peut tout à fait utiliser CSS pour styler ce tag de la manière que nous avons évoqué précédemment. Voici un exemple d’utilisation :

    • Avant soumission du formulaire :
      <label for="nomDuProjet">Nom de votre projet
          <em>saisir au moins 3 caractères</em>
      </label>
      
      <input type="text" id="nomDuProjet" name="nomDuProjet" />
    • En cas d’erreur si la personne a saisi moins de trois caractères, le formulaire pourra changer de cette manière :
      <label for="nomDuProjet">Nom de votre projet
          <strong>doit contenir moins 3 caractères</strong>
      </label>
      
      <input type="text" id="nomDuProjet" name="nomDuProjet" />
    • Manque de syntaxe

      Nous avons évoqué au début de cet article le problème du manque de syntaxe dans certains cas. En mode formulaire, nous savons qu’un lecteur d’écran se focalisera sur les éléments de formulaires. Le problème est que dans certains cas, un <label> n’est pas suffisant ; on souhaite apporter des indications supplémentaires à l’utilisateur. Si l’on utilise un <label> et un paragraphe de texte apportant de plus amples informations, ce dernier risque d’être ignoré par les lecteurs d’écrans, alors que faire ?

      C’est une des problématiques auxquelles ARIA tente de répondre en apportant plus de syntaxe. Dans le cas de figure où l’on souhaite présenter un paragraphe de texte d’aide, on pourra utiliser l’attribut aria-describedby de cette manière :

      <label for="nomDuProjet">Nom de votre projet <em>saisir au moins 3 caractères</em></label>
      
      <input type="text" id="nomDuProjet" name="nomDuProjet" aria-describedby="aideNomDuProjet" />
      
      <p id="aideNomDuProjet">Vous ne pourrez pas modifier le nom de votre projet par la suite. Nous vous conseillons de blablabla.</p>

      Même si vous utilisez un label de la manière classique, c’est une bonne pratique d’utiliser aussi l’attribut aria-labelledby de cette manière :

      <label for="nomDuProjet" id="AnomDuProjet">Nom de votre projet <em>saisir au moins 3 caractères</em></label>
      
      <input type="text" id="nomDuProjet" name="nomDuProjet" aria-labelledby="AnomDuProjet" />

      Tous les lecteurs d’écrans ne savent pas interpréter ARIA, et beaucoup d’utilisateurs ne connaissent pas l’existence de cette nouvelle syntaxe comme le montre ce sondage datant de fin 2009 sur l’utilisation des lecteurs d’écran.

      Si le lecteur d’écran supporte ARIA, sa syntaxe aura la priorité sur les autres attributs, mais il faut prévoir tous les cas de figure et penser son formulaire pour qu’il soit accessible sans le support d’ARIA.

Conclusion

Nous avons survolé quelques règles d’ergonomie et d’accessibilité des formulaires mais il y en a bien d’autres. Je vous invite à consulter les ressources (listées ci-dessous) que j’ai moi même utilisé pour explorer ce sujet.

Ce qu’il faut retenir, c’est que l’on souhaite que l’internaute ait une expérience utilisateur positive, c’est à dire sans stress.

Pour ce faire, il faut avant tout :

  • simplifier chaque formulaire au maximum et ne garder que les champs essentiels.
  • garder en tête les différents profils d’utilisateurs et les nombreux degrés de handicaps qui existent.
  • prendre chaque décision d’ergonomie ou d’accessibilité en fonction du contexte.
  • soigner son code et faire attention à son choix de vocabulaire pour éviter les erreurs et les incompréhensions.

ARIA et HTML5 vont apporter des réponses aux problèmes de syntaxe mais en attendant que ceux-ci soient mieux supportés, il faut penser à tous les cas de figure et ne pas se reposer uniquement sur ces nouvelles syntaxes.

Sources & ressources

Beaucoup de ces ressources sont en anglais.

Rétroliens

  1. […] récemment écrit un article pour le blog de Soluo dans lequel j’évoque des techniques qui vont vous aider à la conception de formulaires […]

Exprimez vous!

*