Archive pour la catégorie ‘Ergonomie’

Concevoir des formulaires ergonomiques et accessibles

Par raphaelle, publié dans Ergonomie, accessibilité le 03 mars 2011

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.

Dans un précédent article sur l’accessibilité 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

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.

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.

  

  En 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

  

  Pour 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 Boilerplate par 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.

• Livres
• Fancy form design par Jina Bolton, Tim Connell et Derek Featherstone
• Web Form Design: Filling the blanks par Luke Wroblewski, 2008
• Vidéo
• In Top Form: Designing and Building Accessible Forms par Derek Featherstone
• Articles
• Introduction à WAI ARIA (traduction) par Pierre Bertet sur Les Intégristes
• Screen Reader User Survey Results sur WebAIM

5 types de notifications pour applications web

Par raphaelle, publié dans Applications web, Ergonomie, Web design le 12 mai 2010

Chez Soluo nous travaillons actuellement sur un projet d’application web. C’est dans ce cadre que je me suis penchée sur les différentes manières d’afficher des messages d’erreur, d’avertissement, d’information et de confirmation.

Les messages d’erreur sont probablement les plus connus, mais les autres types de notifications peuvent aussi être utiles. Parfois, on veut signaler à l’utilisateur que l’action qu’il a déclenché s’est déroulée comme prévue, car si rien ne se passe à l’écran, il peut croire qu’une erreur s’est produite et c’est très frustrant. D’autres fois, une partie des actions ont réussi tandis que d’autres ont échoué. Il faut donc en informer l’utilisateur.

J’ai identifié 5 manières de présenter de telles informations au sein d’une interface web. Le souci est de savoir laquelle utiliser et dans quel cas. De plus, dans une application comme sur un site web, il faut faire preuve de cohérence : on évitera d’utiliser ces 5 styles de notifications sur une même interface, on risquerait de désorienter l’utilisateur.

1ère méthode : la zone unique de notification

C’est un emplacement, souvent situé en haut de l’interface, qui sert à afficher les notifications de tous types à travers l’application. Cette zone vient toujours se positionner à la même place. Si on décide de la situer dans le header, cela implique de la laisser vide en l’absence de notification. On peut aussi choisir de l’afficher sous le header de manière à ce qu’elle pousse le contenu vers le bas lorsqu’elle apparaît.
Exemple de zone unique de notification

Avantages : Participe à la cohérence de l’application car les messages sont toujours au même endroit. Il n’y a donc pas de surprise, et c’est une bonne chose. De plus, rien ne nous empêche d’utiliser cette approche et de la combiner avec la suivante dans certains cas.

Inconvénients : Quand l’utilisateur est descendu en bas d’une page longue, cette zone est alors masquée. Si on ne voit pas le message, on peut avoir l’impression que rien ne s’est passé. Si la page revient brusquement tout en haut afin que le message soit visible, cela peut être frustrant pour l’utilisateur que l’on a presque redirigé, sans lui demander son avis.

2ème méthode : les messages contextuels

Ce sont les messages que l’on positionne au sein même de la zone concernée. Le meilleur exemple est celui des formulaires. Si le formulaire ne valide pas car un champ comporte une erreur, on préférera mettre en valeur ce champ – en rouge par exemple – plutôt que de mettre un message générique en haut du formulaire. De cette manière l’utilisateur n’a pas trop d’effort à faire : il sait tout de suite ce qui s’est passé et comment rectifier le problème.

Pour faire encore mieux, on peut allier les méthodes 1 & 2 en mettant un message en haut de page avec les détails de l’erreur ET en faisant ressortir les champs à modifier.
Exemple de message contextuel

Avantages : Le message est positionné dans la zone de l’interface concernée, donc l’utilisateur a toutes les chances de le voir.

Inconvénients : Représente un peu plus de travail pour les développeurs et intégrateurs car chaque message est un peu « sur mesure ».

3ème méthode : la fenêtre modale

Elles sont très à la mode, surtout pour la présentation de galeries photo, mais aussi pour les notifications importantes. En général elles sont positionnées de manière centrale dans la fenêtre, avec un calque transparent en fond, signifiant ainsi que le reste de l’interface est désactivé.
Exemple de fenêtre modale (lui-même présenté dans une fenêtre modale)

Avantage : On peut être sûr que l’utilisateur va voir le message. Il y a une idée « d’urgence », ou du moins à une situation critique qu’il faut examiner de plus près.

Inconvénient : C’est une approche assez agressive car on empêche l’utilisateur d’interagir avec le reste de l’application. De plus, on l’oblige à prendre une décision, sans quoi il ne peut pas se débarrasser de la fenêtre. Bref, il ne faut pas abuser des fenêtres modales.

4ème méthode : la boite de dialogue

Par boite de dialogue, j’entends « l’alert box » du navigateur. Elle s’apparente à la fenêtre modale car elle requière une action de la part de l’utilisateur. Par contre le web designer n’a aucun contrôle sur son aspect visuel et son positionnement : cette boite appartient à l’interface du navigateur plutôt qu’à celle de l’application web ou site web.
Exemple de boite de dialogue

Avantages : Le sentiment d’urgence et de gravité qu’elle procure si utilisée avec parcimonie.

Inconvénient : C’est encore plus intrusif qu’une fenêtre modale : on l’associe plus à une « erreur fatale ». Son utilisation est troublante quand il s’agit de communiquer un message purement informatif ou de confirmation car on s’attend à un message d’une certaine gravité.
Contrairement à la fenêtre modale, la boite de dialogue peut passer inaperçue : le reste de l’interface est désactivé mais ce n’est pas mis en évidence visuellement.
Vous l’aurez compris, je n’ai pas beaucoup d’affection pour ce mode de notification et je ne vois pas très bien où il a sa place sur le web.

5ème méthode : les notifications de type « Growl »

Ce sont ces messages qui apparaissent assez discrètement dans un coin de l’écran ou de la fenêtre. Parfois ils disparaissent d’eux-même au bout de quelques secondes, d’autres fois il faut cliquer sur un bouton pour les fermer. Ces notifications se superposent donc à l’interface de manière plutôt subtile.
Voir la démo d’un plugin de type « Growl »

Avantages : Ce système permet d’afficher des messages dans une même zone de la fenêtre quelle que soit la longueur de la page. Cela résout donc le problème de la 1ère méthode où le message peut être masqué si on est en bas de page. Ce type de notification permet de discrètement afficher des messages informatifs et n’empêche pas l’utilisation du reste de l’interface.

Inconvénients : Si on utilise ce système pour des notifications importantes, on risque de ne pas les voir ou de ne pas comprendre l’urgence du message car leur positionnement dans la page n’est pas contextuel. De plus il y a des zones auxquelles nous faisons moins attention (en bas à gauche/droite).

Alternative aux notifications intrusives

Je suis arrivée à la conclusion que toutes ces méthodes – à part peut être la boite de dialogue – sont des solutions valides, mais qu’il faut savoir utiliser au bon moment.

Les solutions intrusives telles que les fenêtres modales et les boites de dialogue sont à utiliser le moins possible, car leur problème est justement… qu’elles sont intrusives.
Et si on pouvait s’en passer complètement ?

En lisant le chapitre « Notifying and Confirming » du livre About Face 2.0, The essentials of interaction design (Alan Cooper & Robert Reimann, Wiley Publishing, 2003), j’ai réalisé qu’il y avait presque toujours une alternative au message intrusif.

Par exemple, si l’utilisateur clique sur un bouton « supprimer » afin d’effacer un document de l’application, pourquoi afficher une fenêtre modale lui demandant de confirmer l’action à effectuer ? Dans 95% des cas, la personne veut vraiment effacer le document. Lui demander de confirmer cette action peut instiguer le doute et créer un certain stress. Par ailleurs, si la même fenêtre apparaît à chaque fois que l’utilisateur souhaite effacer quelque chose, il risque d’y être tellement habitué qu’il va machinalement cliquer sur « OK ».

Mieux vaut donc effacer le document sans rien demander, mais en donnant après coup la possibilité de le restaurer. Gmail fait ça très bien ; il m’arrive parfois de sélectionner un email et de cliquer sur « signaler comme spam » au lieu d’un autre bouton. Aussitôt l’action effectuée, la possibilité de l’annuler est bien visible dans la zone de header, sur fond jaune.

Cette manière de faire est beaucoup plus pertinente car elle traite des cas rares – ces 5% – où l’utilisateur s’est trompé, au lieu d’ajouter une étape pour les 95% des cas où tout se passe comme prévu.

Il faut tout de même savoir que la création d’une fonction « annuler » peut représenter une tonne de travail pour les développeurs. Il peut donc être plus rentable de s’en passer. Par exemple, permettre d’annuler la suppression d’un document est assez simple. En revanche, si l’élément à supprimer est relié à d’autres éléments, tout se complique.