Je vous propose de décortiquer un site web chaque mois afin d’examiner son interface utilisateur. Je tâcherai de choisir des sites plutôt bien exécutés, utilisant des techniques actuelles et ayant des designs intéressants.

Pour la première édition de l’année, nous allons nous pencher sur le site Life In My Shoes. Quelles sont ses forces au niveau du design et de l’expérience utilisateur ? Quelles sont ses points faibles ?

Présentation du site

La campagne Life In My Shoes a pour vocation de combattre les idées reçues sur les personnes atteintes par le VIH. Il a été commissionné par l’association Body and Soul qui lutte pour le respect, la dignité et le bien-être des enfants, des jeunes et des familles vivant avec le VIH.

Le site vise un public jeune qu’il tente de sensibiliser à ces problématiques.

J’ai choisi de parler de Life In My Shoes car tout en étant un site relativement simple, le sujet est traité de manière intéressante et attractive, avec une expérience utilisateur assez riche.

Le style graphique

Le design de ce site est relativement épuré, voire minimaliste.

Couleur

La palette de couleurs est très réduite : en fait, une seule couleur est utilisée : le jaune. Pour l’accompagner, le designer a choisi d’utiliser toute une gamme de gris. Le gris, et les aplats de gris clair en particulier, on l’avantage de créer une atmosphère posée et propre, propice à la lisibilité de texte gris foncé ou noir.

Imagerie

Le travail sur les graphismes et les photos est intéressant. La plupart des visuels sont des mélanges de photographie et dessin manuel. Les photos on été découpées afin d’éliminer le fond et de ne conserver que le sujet principal.

Ce traitement de l’imagerie a permis d’harmoniser les visuels entre eux. Même si les différentes photos fournies étaient de style hétérogènes, leurs différences sont gommées par leur découpage et leur assemblage avec du dessin.

Typographie

Le travail typographique a été réalisé avec beaucoup d’habileté même si je ne suis pas une adepte du texte centré (sauf exception). La police d’écriture à l’honneur est Houschka Rounded. C’est une police sans empâtement, à la fois très lisible et agréable à regarder.

La police utilisée pour les titres en lettres capitales est Sevigne ST.

La taille du corps de texte varie entre 16px sur le blog, et 19px sur d’autres pages. L’interligne est très bien ajusté, ce qui fait que le tout est très facile et plaisant à lire.

Beaucoup de web designers (moi y compris) se permettent des tailles de police de 12px ou 11px sans se rendre compte que c’est très difficile à lire. L’interligne est souvent beaucoup trop serré, ce qui ne donne pas envie d’aller au bout du premier paragraphe.

Comme l’explique cet article du Typographe, un corps de texte en 16px est idéal car cette taille correspond à peu près à la taille de texte que nous avons l’habitude de lire sur papier.

Depuis que ma vue a baissé légèrement, je réalise à quel point il est important de ne pas proposer des tailles de textes en dessous de 14px. Très faible est la portion de la population ayant une vision à la Superman.

C’est la mode des designs minimalistes sur internet, bien qu’ils ne soient pas appréciés de tous. On peut le comprendre ; même si l’équilibre entre vides et pleins est harmonieux et que la typographie est belle, ces designs peuvent être visuellement un peu fade.

Dans le cas de Life In My Shoes, je trouve que cet écueil a été évité grâce à plusieurs techniques et astuces subtilement utilisées.

L’interactivité

« (Design is) not just what it looks like and feels like.Design is how it works. »
Steve Jobs

Pour paraphraser cette citation du brillant Steve Jobs, le design n’est pas uniquement affaire d’esthétique et de cosmétique. Le design comprend aussi la manière dont le produit – ici le site web – va réagir aux interactions. Pour résumer, ce qui importe ce n’est pas seulement si c’est « joli », c’est l’expérience utilisateur dans son ensemble.

J’ai trouvé que l’expérience utilisateur sur ce site était subtilement enrichie par différents niveaux d’interactivité et de réactivité.

Les transitions

Lors du passage d’une page à l’autre, la zone de contenu est balayée avec un effet de transition. On aurait pu simplement charger la nouvelle page de manière traditionnelle, mais cet effet est un petit plus assez attractif.

Les contenus de la page d’accueil et de la page Journey So Far apparaissent de manière animée eux aussi. Notez l’effet subtil de parallax sur la page d’accueil, c’est à dire que la photo de l’homme apparait en premier et le fond dessiné circulaire s’insère en décalé dans le temps. On retrouve cet effet sur les différentes pages de Journey So Far lorsqu’on navigue avec les flèches jaunes.

Sur la page About us, on retrouve l’effet de parallax qui est cette fois vertical. Lorsque l’on descend dans la page, que ce soit en utilisant la molette de la souris ou les boutons présents dans la page, on voit que les morceaux de textes et les éléments graphiques bougent à des vitesses différentes. C’est une bonne manière d’inciter à parcourir toute la page, et de faire lire le texte à l’audience.

User input

Autre aspect sympa du site se passe sur la page Be Involved dont le contenu est généré par les utilisateurs. On leur propose d’uploader une photo de leurs pieds chaussés (référence au nom de la campagne) et de partager en une phrase un moment où ils se sont sentis différents, mis à l’écart.

C’est une manière simple et ludique pour l’internaute de s’impliquer et de partager avec d’autres. Visuellement, cela crée ces petites vignettes que l’on peut retourner d’un clic. La simplicité du concept et de l’interface donne envie d’explorer les différentes vignettes, et pourquoi pas d’y ajouter son emprunte.

Responsiveness

Le site a été conçu de manière a s’afficher correctement sur toutes les plateformes et résolutions d’écran. Que vous le consultiez sur un smartphone ou un grand écran d’ordinateur, l’interface devrait à peu près s’adapter. Je dis « à peu près » car le résultat n’est pas parfait sur certaines pages.

Si vous voulez en savoir plus sur ce sujet, je vous recommande de lire ce cas d’étude que j’ai écrit sur le « responsive design ».

Vidéos

Dans la liste des interactions avec le site, j’aimerais ajouter une petite note sur les vidéos car ce site en comprend plusieurs.
Il n’est pas a la portée de tous de proposer des vidéos sur un site, cependant lorsque c’est possible et que c’est pertinent, cela peut être une vraie valeur ajoutée. En tant qu’utilisateur on n’a pas toujours envie de lire du texte. Regarder une vidéo bien faite peut être tout aussi informatif et demander moins d’effort.

Rollovers

Sur la page Journey So Far, j’ai apprécié les petites bulles qui apparaissent lorsqu’on passe la souris sur les noms en noir des personnes citées. C’est une manière ludique de présenter plus d’informations à l’internaute tout en les rendant « optionnelles ». De cette manière elles ne polluent pas la page en étant tout le temps présente.

J’aurais aimé retrouver ce comportement sur d’autres liens du site, dans les contenus mais aussi par exemple sur les icônes des réseaux sociaux ou les logos des partenaires en bas de page.

Note sur l’ergonomie

Elle est plutôt bien pensée dans l’ensemble. La navigation est aisée, le texte est découpé en blocs faciles à lire. J’aurais cependant quelques critiques à émettre.

Navigation

L’état sélectionné d’un élément de navigation ne saute pas aux yeux. Lorsqu’on se trouve sur une page, l’élément de navigation correspondant est d’un gris un peu plus foncé que les autres éléments mais la distinction entre les deux états n’est à mon sens pas suffisante.

La navigation sur la page About us grâce à la barre verticale de droite n’est pas très explicite. J’ai mis du temps à comprendre pourquoi plusieurs points étaient en jaune. Je vous laisse deviner la raison mais voici un indice : cela dépend de la hauteur de votre fenêtre et de votre écran.

Heureusement, l’utilisateur a deux autres options pour naviguer dans cette page : en scrollant à l’aide de la souris ou de la barre de défilement du navigateur et à l’aide des boutons noirs sur jaune situés dans la zone de contenu.

URLs

La section Journey So Far est divisée en trois écrans. Au niveau du code il s’agit d’une seule et même page, mais du point de vue de l’utilisateur ce sont trois pages séparées. On navigue de l’une à l’autre à l’aide des flèches jaunes.

Une bonne pratique consiste à donner des URLs différentes à ces pages, même si en réalité il n’y a qu’une seule page. Dans cet exemple l’URL ne change pas.

En résumé

Les « plus »

• Palette de couleurs lumineuse et épurée
• Style d’imagerie créatif et homogène
• Typographie de qualité et hautement lisible
• Interactivité variée
• Animations par petites touches
• Site « responsive », c’est à dire qui s’adapte aux différentes résolutions d’écrans
• Vidéos qui égayent et informent

Les « moins »

• Ergonomie médiocre de la navigation
• Le texte centré est à éviter
• Utilisation de javascript pour répartir du contenu sur plusieurs pages, sans changer l’URL

Conclusion

J’ai aimé ce site à la fois pour sa simplicité et pour tous les détails qui apportent un « plus » à l’expérience utilisateur.

On sent que ce projet a nécessité beaucoup de temps et de réflexion afin d’aborder ce sujet sensible de manière ludique, interactive et attractive pour les jeunes (et les moins jeunes), sans tomber dans l’excès au niveau des animations.

Le mois prochain, je vous présenterai la critique d’un autre site.
D’ici là si n’hésitez pas à poster vos commentaires. Êtes-vous d’accord avec mon analyse ? Pas d’accord du tout ?

Nous allons voir comment dans un blog « responsive » on peut afficher un format de date différent, comme par exemple avoir tantôt le mois en toutes lettres (ex : Septembre), tantôt l’abréviation du mois (ex : SEP), le tout en gardant une syntaxe HTML propre.

Voir l’exemple

Rappel sur le design « responsive » (ou « réactif ») : il s’agit d’utiliser les media-queries pour s’adapter à la taille du device et/ou du navigateur de manière intelligente et ergonomique. Pour plus d’infos, voir cet article sur les media-queries par Alsacréations.

Nouveau site, nouveaux challenges

Cet été nous préparons la refonte du site de soluo.fr. En fait, plus qu’une refonte, nous refaisons tout !

Notre nouveau site sera « responsive » (ou réactif), comme le site de Secri Gestion dont nous avons parlé dans des articles antérieurs.

Pour le nouveau site, nous avons choisi de séparer le blog. Il reprendra la charte graphique du site mais aura une structure et un design différent.

Tout blog qui se respecte contient des articles, auxquels certaines données « meta » sont associées. En général il y a au moins une date de publication et un auteur. L’article peut aussi être catégorisé et taggué par exemple.

Concentrons nous sur la date de publication d’un article. Notre blog sera lui aussi réactif, c’est à dire que son interface va s’adapter à la taille du navigateur et de l’appareil utilisé pour le visualiser.

Dans mon design « grand format », c’est à dire pour écrans d’ordinateurs classiques, j’ai choisi de montrer la date comme sur un petit bloc-calendrier. Je veux que l’abréviation du mois en 3 lettres s’affiche en haut, au dessous duquel on verra le jour en gros, puis l’année en plus petit, comme sur cette image :

Facile, sauf que dans le design pour petits formats (pour les smartphones par exemple) je veux montrer la date d’une autre manière. Le tout s’afficherait sur une ligne avec jour, mois, année, comme ceci :

Positionner les mêmes éléments de manières différentes ne me fait pas peur. Avec les media-queries, c’est facile. Dans le premier cas on peut se servir des positions absolute / relative, et dans le second cas, on laisse les éléments inline se positionner les uns après les autres naturellement.

Le problème : le format de la date

Je ne suis pas développeuse, mais je me doute que si je demande à mon collègue développeur de me fournir 2 formats de date différents selon que certaines media-queries sont déclenchées ou pas, il va me regarder de travers.

Une solution serait d’avoir la date 2 fois dans le code, dans 2 formats différents. Dans un cas on masque l’un, ou l’autre.

Cette solution ne me satisfait pas car j’aime que mon code reste propre.

J’ai posé la question sur Twitter et on m’a suggeré le pseudo-element :after et la propriété content de CSS.

Même si je n’ai pas tout à fait compris la suggestion car je ne souhaitais pas utiliser de lien, cela m’a donné une bonne piste.

J’ai aussi demandé l’avis de la communauté de Sitepoint sur leur forum, et j’y ai posté ma solution (English)

La solution : utiliser l’attribut TITLE

La solution qui me parait la meilleure est de générer la date dans 2 formats différents, du moins pour le mois, qui est l’élément problématique ici.

La balise contiendra le nom entier du mois, et l’attribut TITLE contiendra l’abréviation en 3 lettres.

Après il suffit d’un peu de CSS avec des media-queries pour afficher l’un ou l’autre.

Voici le code que j’ai écrit assez rapidement. Je ne suis pas contente de la manière dont je cache le mot « juillet », je pense qu’on peut mieux faire. Mais ça marche !

<head>

<style type="text/css">

.dateBox {
	font-family: trebuchet ms, helvetica, arial;}

@media screen and (min-width: 800px) {
.dateBox {
	-moz-box-shadow: 2px 2px 0 #dcdcdc;
	-webkit-box-shadow: 2px 2px 0 #dcdcdc;
	box-shadow: 2px 2px 0 #dcdcdc;

	background: #eee;
	color: #000;
	font-size: 14px;
	overflow: hidden;
	padding: 15px 2px 2px;
	position: relative;
	text-align: center;
	width: 50px; }

.day {
	font-family: georgia, serif;
	font-size: 34px; }

.month {
	color: #eee;
	left: 3px;
	margin-top: -15px;
	position: absolute;
	text-transform: uppercase;
	top: 3px;
	width: 50px; }

.month:after {
	color: #000;
    content: attr(title);
    display: block; }
}

@media screen and (max-width: 800px) { 

.dateBox {
	color: #666;
	font-size: 12px;
	font-style: italic;}

}

</style>
</head>
<body>

<div class="dateBox">
	<span class="day">12</span>
	<span title="JUL" class="month">juillet</span>
	<span class="year">2011</span>
</div>

Pour voir comment ça marche, redimmensionnez la fenêtre de votre navigateur.

Voir l’exemple

N’hésitez pas à me faire part d’améliorations éventuelles, notamment pour la manière de cacher le contenu de la balise « month ».

Note sur la compatibilité

Cet exemple ne fonctionnera que sur les navigateurs modernes, qui comprennent les media-queries. C’est un petit essai que j’ai fait rapidement, sans me soucier de la compatibilité avec mon très cher Internet Explorer (6, 7 et 8). Cependant il est tout à fait possible de faire fonctionner tout ça sur IE en utilisant un outil tel que 320 and up qui inclut des fichiers javascript.

Credits : merci à IconSweets pour l’icône Calendrier.

Après les phases initiales de recherche et de design que nous avons abordé dans deux articles précédents, vient le temps de l’intégration HTML et CSS.

En principe ce n’est pas très compliqué : il suffit de suivre la méthode de 320 and up qui consiste à intégrer d’abord pour la taille de fenêtre la plus petite.

Je dis « en principe », car nous avons rencontré un certain nombre de difficultés, notamment avec Internet Explorer 7 et 8, malgré les outils javascript fournis dans le template.

Note : Comme pour la majorité des sites que nous réalisons, nous avons décidé de ne pas supporter IE6 pour ce projet.

L’intégration pour 320px et 480px de large

Note : Pour tester j’ai utilisé un iPhone 3GS ainsi que Firefox 3.6, Chrome, Safari, IE7 et IE8 sur desktop. J’aurais voulu pouvoir tester sur d’autres smartphones mais je n’avais pas cette possibilité.

Andy Clarke propose deux versions du template : la première avec une feuille de style unique et la seconde avec de multiples feuilles de styles. J’ai préféré travailler avec plusieurs feuilles de styles car cela me paraissait plus « propre », mais c’est un choix très personnel.

On commence donc par style.css qui est la feuille de style de base. Elle correspond à une largeur de fenêtre de 320px au maximum.

La méthode de 320 and up consiste à intégrer d’abord pour les plus petits formats, et de rajouter des feuilles de styles les unes au dessus des autres en allant vers le format le plus large.
Cela signifie que les règles CSS contenues dans style.css seront prises en compte par toutes les tailles écrans. Certaines devront être écrasées par la suite afin de positionner les éléments d’une nouvelle manière pour une taille de fenêtre supérieure.

Pour les écrans allant jusqu’à 480px de large, on doit penser aux appareils mobiles de type smartphone. Les zones cliquables doivent être suffisamment larges pour effectuer un « clic » avec le doigt. On peut faire le choix de masquer certains éléments s’ils sont superflus et si leur absence peut rendre l’interface plus claire et intuitive.

Dans une logique d’optimisation et de performance, on évitera l’utilisation d’images de fond volumineuses, et on limitera les effets graphiques d’une manière générale.

L’utilisateur d’un appareil mobile a très peu de patience – encore moins que sur un ordinateur classique – c’est pourquoi il est si important de peaufiner l’ergonomie de l’interface pour les petits formats.

Une fois satisfaite du résultat sur mon iPhone en mode portrait, je suis passée à l’intégration du mode paysage, c’est à dire en 480px de large. Rien ne nous oblige à tout changer pour chaque taille d’écran. Je pense que le passage de 320px à 480px demande un petit travail d’adaptation qui n’est pas radical dans un le cas d’un site comme celui-ci.

En l’occurrence j’ai principalement changé la présentation des biens sur la page d’accueil et sur les pages « A louer » et « A vendre » pour que la fiche du bien passe en mode horizontal. L’image est plus petite qu’en mode portrait mais au moins on voit toutes les informations en un clin d’oeil.

Si j’avais laissé exactement les même styles qu’en 320px de large, la photo du lieu aurait paru énorme et il aurait fallu scroller pour voir les information relatives à un lieu.

Annonce immobilière sur la page d’accueil en 320px de large (iPhone)

Annonce immobilière sur la page d’accueil en 480px de large (iPhone)

L’intégration pour 728px et 992px de large

Le passage entre les versions 728px et 992px de large était un petit peu plus complexe, notamment à cause du header et de la navigation que je devais adapter. Je m’en suis souvent sortie en ajoutant plus de markup (généralement des DIVs), chose qui n’est pas idéale.

En effet, si le site avait été de largeur statique, j’aurais utilisé beaucoup moins de balises mais puisque la disposition de certains éléments doit pouvoir changer, il faut de quoi les positionner de différentes manières : tantôt avec un positionnement absolu ou relatif, tantôt avec un float.

Il faut jongler avec les différents éléments du HTML et de CSS pour arriver à ses fins et ne pas oublier de tester le site sur différentes tailles d’écran et sur tous les navigateurs à supporter lorsque l’on apporte des changements à une feuille de style.

Pour les pages « A louer » et « A vendre » j’ai souhaité utiliser des selectors CSS3 grâce à Selectivizr et à un plugin pour jQuery qui étend le support des pseudo-class et selectors CSS3. J’aurais voulu pouvoir utiliser des selectors tels que nth-of-type(2n+4) sur tous les navigateurs, mais après quelques échecs nous avons abandonné cette belle idée car cela ne fonctionnait pas sur Internet Explorer.

Nous comptons revenir sur ce problème prochainement afin de comprendre d’où est venu cet échec.

Page d’annonces en 768px de large

Page listing des annonces en 960px de large

Adaptation de 320 and up

Sur la page d’accueil j’avais prévu deux colonnes à hauteur égale pour « Syndic » et « Gestion locative ». Dans ce cas de figure j’étais obligée de recourir à un petit peu de javascript pour calculer la hauteur de la colonne la plus haute et forcer la hauteur de l’autre colonne. C’est très facile à implémenter, cependant le problème est que si la fenêtre est redimensionnée, la hauteur des colonnes ne change pas.

Pour résoudre ce problème j’ai « triché » en ajoutant suffisamment de padding-bottom pour que le texte ne déborde pas lorsque la largeur d’écran est réduite.

Cependant, le vrai problème était pour les versions 320px et 480px car étant très étroites, j’ai voulu positionner les colonnes l’une au dessus de l’autre. Comme je ne souhaitais plus qu’elles aient la même hauteur, j’ai ajouté une media-query et une feuille de style pour viser toutes les largeurs de fenêtre en dessous de 768px.

Le seul style que cette feuille de css contient est :

section.homeMainContent article {
height: auto !important;
}

Ainsi, la j’écrase la hauteur générée par le javascript afin que les deux colonnes prennent une hauteur « naturelle », en fonction de leur contenu.

Internet Explorer…

En théorie 320 and up contient je javascript nécessaire au bon fonctionnement des media-queries sur Internet Explorer.

Lors de la phase d’intégration j’étais assez contente du résultat sur IE7 et IE8 sur XP et Windows 7, même si ce n’était pas parfait à 100% ; certains éléments de l’interface ne se positionnaient pas tout à fait comme ils auraient dû lors du redimensionnement de la fenêtre. Néanmoins, ces légers « bugs » me paraissaient suffisamment discrets pour que le site soit mis en ligne tel quel.

Après la mise en ligne du site, le client nous a signalé un problème que nous n’avons pas réussi à reproduire à ce jour : sur 2 de leurs ordinateurs, seule style.css était prise en compte, ce qui donnait un résultat catastrophique sur un écran classique.

Nous avons l’intention d’investiguer mais pour l’instant nous préférons fournir une version statique en 960px de large aux utilisateurs d’Internet Explorer 7 et 8. A suivre…

Dans le prochain article je ferai le bilan de cette expérience : je vous donnerai quelques astuces pour réussir votre site réactif, et je vous ferai part des leçons apprises grâce à cette aventure, dans l’espoir de vous éviter de vous confronter aux mêmes problèmes.

Dans un article précédent nous avons parlé des outils que nous avons choisi pour la réalisation du site secri.fr, afin d’en faire un site « responsive » (ou en français, « réactif »).

Cependant, avant de passer à l’intégration du site il nous a fallu repenser le design. En effet, le visuel du site en 960px de large avait déjà été validé par le client, avant que nous décidions d’en faire un site réactif.

Note : en principe une telle décision devrait se faire en amont et avec l’accord du client car cela représente plus de travail qu’un site statique (et donc un coût un peu plus important) mais nous avions envie d’expérimenter sur ce projet qui s’y prêtait bien.

Le design initial

Le design de départ, qui avait déjà été validé par le client, prenait la largeur classique de 960px.

Page d’accueil en 960px de large

Page listing des annonces en 960px de large

J’ai estimé qu’il faudrait prévoir 4 « versions » du site réactif.

• La plus petite irait jusqu’à 320px de large (ce qui correspond au mode portrait de l’iPhone)
• La suivante serait utilisée pour les largeurs entre 320px et 480px (480px étant la largeur de l’iPhone en mode paysage)
• La suivante pour les largeurs entre 480px et 768px (768px est la largeur de l’iPad en mode portrait)
• La dernière correspondrait au design conçu pour le site statique en 960px, et irait de 768px à 1000px de large.

Étant donné que le site secri.fr contient relativement peu de contenu, je n’ai pas vu l’intérêt de prévoir une largeur supérieure car l’interface aurait perdu en ergonomie et en esthétique.

Pour d’autres types de projet on peut tout à fait envisager des largeurs de fenêtre supérieures, comme le fait le site de 320 and up.

Adaptations du design

Page d’accueil en 768px de large

Je suis brièvement repassée par la case Photoshop pour visualiser la page d’accueil en largeur 768px. Il fallait surtout revoir la navigation car les éléments risquaient de ne pas tous rentrer à droite du logo. J’ai donc choisi de sortir le logo de la barre de navigation et de le centrer, ainsi que de centrer la liste des liens.

La liste des biens passe en mode horizontal, ce qui fonctionnera aussi très bien pour la version d’en dessous qui est de 480px de large, avec quelques adaptations.

Page d’accueil en 768px de large

Liste des annonces en 768px de large

Pour les pages « A louer » et « A vendre », il n’y a plus assez de place pour 4 annonces par ligne, on passe donc à 3 annonces seulement. Le reste ne change pas.

Page d’annonces en 768px de large

Pour les deux versions les plus petites (320px et 480px), je n’ai pas eu besoin de travailler dans Photoshop car le travail effectué sur la version de largeur 768px m’a permis de les visualiser dans ma tête pour ensuite les implémenter directement pendant la phase d’intégration.

Ce que je ferai différemment à l’avenir

• Je travaillerai probablement sur 2 ou 3 tailles du site en parallèle, sans forcément décliner tous les gabarits pour chacune d’entre elles. Il est très possible que je continue à me baser sur un design en 960px de large, tout en réfléchissant à chaque étape à mes choix graphiques et à la manière dont ils vont affecter la syntaxe HTML.
• Je réfléchirai un peu plus aux conséquences de mes choix ergonomiques sur la phase d’intégration, notamment pour éviter l’ajout de scripts supplémentaires.

Dans un prochain article je parlerai de la phase d’intégration. Celle-ci s’est déroulée relativement bien grâce à l’outil 320 and up mais il y a eu quelques petits soucis liés à javascript et à certains navigateurs, pour ne pas citer de noms…

Nous avons récemment mis en ligne le site secri.fr, pour une agence immobilière située en région parisienne. Nous l’avons intégré de sorte qu’il soit « réactif ». En anglais on parle de « responsive web design« .

En pratique, cela signifie qu’on utilise les media-queries (CSS3) pour appliquer des styles différents selon la taille de l’écran, de la fenêtre, ou encore de l’orientation d’un appareil mobile (smartphones et tablettes).

Cela permet donc de présenter à l’utilisateur un design et une ergonomie optimisés pour chaque type d’appareil qu’il utilise ainsi que pour la taille de la fenêtre de son navigateur.

Pour voir de quoi il s’agit, amusez-vous à redimensionner la fenêtre de votre navigateur lorsque vous êtes sur secri.fr.

Notons que selon les projets, il peut être préférable de créer un site ou une application mobile séparés. Cependant, dans la plupart des cas, l’utilisation des media-queries est la meilleure option car elle est relativement facile à implémenter et reste peu coûteuse.

Les problèmes liés à la création d’un site réactif

Lorsqu’on approche le sujet pour la première fois, cela peut paraître très complexe car très vite, on comprend qu’il va falloir changer ses méthodes de travail.

Quelques questions peuvent venir à l’esprit :

• Dois-je créer une maquette graphique pour chacune des différentes apparences du site ? Cela représente beaucoup de travail et d’échanges avec le client !
• CSS3 ne fonctionne que sur les navigateurs récents ; que faire des navigateurs plus anciens ?
• Comment aborder la phase d’intégration ?
• Est-ce compliqué d’obtenir différentes « versions » d’un site en gardant la même syntaxe HTML ?

Lors de la réalisation du site de Secri Gestion, notre premier site réactif, je me suis confrontée à ces problématiques. Je vais vous faire part du cheminement que nous avons suivi en espérant que cela vous aidera à réaliser vos sites.

L’idée de départ

Peu avant de commencer l’intégration de secri.fr, j’ai trouvé le template 320 and up, créé par le talentueux Andy Clarke. C’est une extension de HTML5 Boilerplate (par le tout aussi talentueux Paul Irish) que nous utilisions déjà pour tous nos sites.

Ces templates, composés de HTML, de CSS et de Javascript, sont une très bonne base pour créer un site réactif en bénéficiant des meilleures pratiques. Grâce au Javascript fourni, même Internet Explorer 6 se comportera comme un navigateur moderne. Enfin presque.

Plus qu’un template, 320 and up est une méthode de travail. C’était ça la vraie nouveauté pour moi car j’ai dû repenser ma manière de travailler. En effet, pour un site statique on passe généralement du design à l’intégration d’une façon assez linéaire.

Dans le cas d’un site réactif ayant 4 apparences différentes (la première pour les fenêtres allant jusqu’à 320px de largeur, puis jusqu’à 480px, 768px, et supérieure à 992px), il va falloir travailler autrement. La méthode d’Andy Clarke consiste à intégrer d’abord la version la plus petite, puis à passer au cran au dessus et ainsi de suite, jusqu’à l’intégration de la version la plus large en dernier. Ayant tenté le procédé inverse par le passé, je ne suis pas prête de revenir en arrière car c’était laborieux !

A noter que nous souhaitions réaliser un site à la fois réactif et flexible, c’est à dire qu’au lieu de « sauter » d’une apparence à l’autre lors du redimensionnement de la fenêtre, les éléments devaient s’adapter à la largeur de la fenêtre avec souplesse. Il fallait donc utiliser des pourcentages pour les largeurs des différents éléments.

Nous verrons dans un prochain article comment je m’en suis sortie au niveau du design, puisque la maquette graphique faisant 960px de large avait déjà été validée par le client.

Deuxième partie de cet article : la phase de design

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

Dans cet article nous allons parcourir quelques règles d’accessibilité qui concernent le code HTML, l’écriture des contenus, ainsi que les phases de conception et de design. Ces règles rendent service à une multitude d’utilisateurs. En parallèle, elles favorisent un bon référencement naturel, ce qui n’est pas négligeable. Il y a donc tout à gagner en les implémentant.

Accessibilité web : qui est concerné ?

Selon Wikipedia, l’accessibilité du Web est la problématique de l’accès aux services et contenus en ligne pour les handicapés et les seniors.

Avec 22% de plus de 60 ans (INSEE) et environ 15% de personnes ayant un certain degré de handicap, on s’attendrait à ce que la majorité de sites web soient accessibles. Ils sont pourtant une faible minorité en ce début d’année 2011.

Il y a plusieurs causes à ce manque d’accessibilité du paysage web actuel :

• Les développeurs et intégrateurs ne sont pas formés en accessibilité ou ils ont du mal à communiquer au reste de leur équipe l’importance de l’accessibilité.
• Les clients ne sont pas sensibilisés à ce sujet ou pensent que ça va leur coûter trop cher.
• Les designers pensent qu’un site accessible ne peut pas être esthétique et que leur liberté de création va être réduite.

Il y a probablement d’autres causes en jeu, mais un des problèmes certain est le manque d’information de tous les partis concernés. En réalité, il est relativement facile de créer des sites accessibles en respectant quelques règles de base.

Règles de base pour un site accessible

• Une syntaxe HTML impeccable
  C’est une évidence ! Il s’agit par exemple de n’utiliser des tableaux que pour les données tabulaires ; d’utiliser des balises de titres pour les titres etc. Une bonne syntaxe sera aussi bénéfique pour les moteurs de recherches donc il y a tout à gagner.
• Des titres descriptifs
  Selon un sondage réalisé par WebAIM en 2009 sur l’utilisation faite des lecteurs d’écrans, 50% des personnes interrogées utilisent la fonctionnalité qui leur permet de naviguer d’un titre à l’autre lorsqu’ils cherchent une information. C’est leur manière de « lire en diagonale », d’où l’importance d’utiliser le bon marquage, et de choisir une formulation qui décrira le contenu qui correspond à cette section.
• Des liens descriptifs
  De la même manière qu’un utilisateur de lecteur d’écran peut lister tous les titres d’une page, il peut aussi lister tous les liens qu’elle contient. 16% des personnes interrogées dans le même sondage utilisent cette fonctionnalité. Il est donc important de choisir la formulation de chaque lien avec soin, pour qu’il ait du sens une fois sorti de son contexte. Il faut éviter à tout prix les libellés de type « cliquer ici » ou « en savoir plus ».

  Une méthode possible est de rajouter dans un span caché des internautes voyant une partie du lien :

  Par exemple considérons le lien suivant :

  <a href="http://fr.wikipedia.org/wiki/Accessibilit%C3%A9_du_Web">
  en savoir plus <span class="lecteurDecran"> sur l'accessibilité du web</span>
  </a>

  Dans la feuille de style, définissons un style qui masquera à l’écran le texte contenu dans le span, mais le laissant « visible » pour les lecteurs d’écran :

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

  Dans cet exemple, les personnes utilisant un lecteur d’écran entendent la totalité du lien, au lieu de seulement « en savoir plus » qui ne veut rien dire une fois sorti de son contexte. Cependant, les personnes utilisant un navigateur classique ne voient que « en savoir plus » à l’écran.

• L’importance des listes
  Les listes sont très utiles car les lecteurs d’écrans annoncent le nombre d’items qu’elles contiennent avant de les énoncer. Ne pas oublier de créer des listes pour les menus de navigation. En fait, les listes sont assez fréquentes et elles ne doivent pas nécessairement être accompagnées de puces ou des numéros à gauche.

  Une petite astuce consiste à se poser la question suivante : est-ce un titre ou un paragraphe ? Si la réponse est négative, il y a de grandes chances pour qu’il s’agisse d’une liste.

• Mettre les contenus importants en haut de page
  Dans le code HTML, il est préférable de mettre le contenu important avant les contenus contextuels ou secondaires. Les lecteurs d’écrans lisent les pages de haut en bas, il est donc logique de leur présenter les contenus importants en premier. Pour les internautes voyants, on se sert de CSS pour placer les différents contenus où on le souhaite sur la page.
• L’attribut ALT
  Toutes les images qui ne sont pas des images de fond (ces dernières sont définies dans les feuilles de style), doivent impérativement avoir un attribut ALT. Si ces images sont purement décoratives cet attribut doit être laissé vide. De cette manière, le lecteur d’écran l’ignorera totalement.
  Si en revanche une image apporte du sens, le texte contenu dans l’attribut devrait être descriptif mais bref.

  77% des utilisateurs de lecteurs d’écrans veulent savoir qu’une photo représente une jeune femme qui sourit, contre seulement 12.8% qui préféreraient que ce genre d’image soit totalement ignorée par le lecteur d’écran. Ce type de visuel peut apporter une information sur le ton et l’image de marque d’une entreprise par exemple.

• La conclusion en premier
  Pour chaque paragraphe, il est conseillé de résumer le contenu de celui-ci dans la première phrase, pour que l’utilisateur de lecteur d’écran soit en mesure de décider s’il souhaite continuer à lire ou passer à une autre partie de la page. Tous les utilisateurs bénéficieront de ce style d’écriture.
• Des titres de pages descriptifs
  Le titre de la page web est le premier élément que lit un lecteur d’écran, c’est pourquoi il est essentiel qu’il soit pertinent et descriptif.

Une multitude de déficiences et de handicaps

Nous nous sommes focalisés sur les utilisateurs non voyants utilisant des lecteurs d’écrans, mais il existe bien d’autres profils d’utilisateurs handicapés auxquels il faut penser.

Selon une étude publiée en 2002 sur les handicaps, il y a en France environ 12 millions de personnes souffrant d’un handicap, à des degrés très variés. Cela correspond à environ 15% de la population. De plus, ces chiffres ne prennent pas en compte des déficiences assez répandues qui ne sont pas des réellement des handicaps, mais qu’il faut tout de même inclure dans la problématique de l’accessibilité web. Il y a par exemple le daltonisme (8% de la population), la dyslexie (10% de la population) et l’épilepsie (environ 1% de la population).

Pour faciliter l’expérience de ces utilisateurs ainsi que de tous les autres, on peut ajouter quelques règles pour les phases de conception et de design :

• Utilisation de contrastes forts
  Le contraste entre le texte et la couleur de fond doit être important pour être facile à lire. De plus, il est recommandé d’utiliser des fonds clairs avec du texte foncé plutôt que l’inverse pour les sites avec beaucoup de contenu.

  Il existe plusieurs outils en ligne pour vérifier que l’on a fait un bon usage des couleurs, comme Check my colours et Contrast-A

• Utilisation des couleurs avec parcimonie
  Il peut être tentant, pour le web designer débutant, d’utiliser une palette chromatique large, cependant trop de couleurs peuvent nuire à la lisibilité de la page et distraire l’oeil. De plus, éviter les associations de couleurs telles que le rouge avec le vert car les daltoniens auront des difficultés à discerner les deux.
• Eviter à tout prix les animations rapides et répétitives
  Avez vous essayé de lire un article avec plein de bannières de publicité animées à côté ? C’est très pénible pour beaucoup d’utilisateurs. Autant que possible, il faut éviter ces animations rapides et répétées. Si vous devez mettre de la pub sur une page, préférez des versions statiques ou des animations lentes et qui s’arrêtent au bout de quelques secondes.

Conclusion

Rendre un site web accessible, ce n’est pas très difficile, il y a quelques bonnes habitudes à prendre mais une fois qu’elles font parties de nos méthodes de travail, on ne peut pas dire qu’il y ait un travail supplémentaire à fournir.

Cependant l’accessibilité devient plus difficile à implémenter lorsqu’il s’agit d’applications internet riches plutôt que de simple sites web. En effet, celles-ci utilisent souvent des éléments de javascript et de AJAX qui permettent de rafraîchir une partie de la page seulement. D’autre part, ces applications comportent généralement des formulaires qu’il faut savoir intégrer correctement afin qu’ils soient accessibles. Nous explorerons ces domaines dans un prochain article.

Ressources utilisées pour la rédaction de cet article

• Improving usability for screen reader users (Webcredible)
• Sondage réalisé par WebAIM en 2009 sur l’utilisation faite des lecteurs d’écrans (WebAIM)
• Définition de l’accessibilité du web (Wikipedia)
• Personnes handicapées dans le monde, en Europe et en France
  (accessiweb.org)
• CSS in Action: Invisible Content Just for Screen Reader Users (WebAIM)
  
• Screen reader user survey results (WebAIM)

Paris Web 2010 s’est déroulé du 14 au 16 octobre et a rassemblé des centaines de professionnels du web : des développeurs, des intégrateurs, des web designers, et d’autres profils du web, du marketing à l’accessibilité.

Les sujets abordés étaient tantôt méthodologiques, techniques ou quasi philosophiques. D’après ce que j’ai pu voir, les conférences qui ont généré le plus de réactions du publics étaient celles de Francis Chouquet, CSS3/Photoshop : quel avenir pour le métier de web designer ? et d’Eric Daspet Le web, un métier de valeur.

J’ai eu l’impression qu’il y avait un certain malaise dans une industrie jeune et dynamique où beaucoup cherchent leur place.

Le designer et le code

Il y a le débat (j’ai envie de dire “vieux comme le monde” mais ça me paraît un peu prématuré) : le web designer doit-il savoir coder ? Les opinions divergent fortement :

• Ne pas savoir coder peut brider la créativité car on ne comprend pas les possibilités liés à la technologie et on peut passer à côté de certaines choses.
• Savoir coder peut aussi brider la créativité car on pense aux contraintes (ou “spécificités”) du web au lieu de donner libre cours à son imagination.

Pour moi, les deux arguments sont valides mais est-ce que ça ne dépend pas de l’individu, de sa sensibilité et de ses méthodes de travail ? Je trouve que c’est tant mieux s’il y a plusieurs approches et outils possibles à la création Web.

Dans des petites structures, les profils hybrides seront appréciés tandis que dans les grosses agences, on cherchera des personnes plus spécialisées. Ce n’est peut-être pas toujours vrai mais dans l’ensembe ça résume bien la situation.

Des experts en mal de reconnaissance

Lors de la conférence d’Eric Daspet sur la valeur des métiers du web, plusieurs membres du public ont parlé du problème de manque de reconnaissance de leur expertise. Dans beaucoup de leurs entreprises, le Web, c’est pour les stagiaires.

Les experts sont donc peu reconnus et leurs intitulés de postes reflètent ce problème, tout comme leurs minces salaires qui ne correspondent pas aux nombreuses compétences qu’on exige d’eux. Eric Daspet nous a parlé d’offres de stages non payés qu’il voit toujours passer et qui demandent des compétences solides dans des langages de programmation complexes et très spécifiques, ainsi que de nombreuses années d’expériences !

Des solutions ?

Certains proposent de s’accorder sur une nomenclature pour nos métiers. Je trouve dommage qu’on veuille à tout prix s’étiqueter comme dans d’autres industries. Ne peut-on pas tirer parti du légér flou qui règne quand on parle de “web designer” ? Chacun peut se façonner une casquette à sa taille en quelque sorte. D’autant plus que nos métiers évoluent tellement vite ; comment définir ce qui est en constante mutation ?

Selon Eric Daspet, les professionnels du Web ont tendance à se positionner en executants car ils disent trop souvent « oui » aux demandes déraisonnables des moins experts. C’est une piste.

Quelqu’un a évoqué l’artisanat pour parler de nos métiers. L’idée m’a plu instantanément. Quand on cherche une définition du mot “artisan” sur Google on trouve trois définitions dont deux qui me paraissent les plus pertinentes :

Celui ou celle qui exerce un métier mécanique ou manuel, qui suit les règles d’un art établi, par opposition aux métiers dits industriels où la production est fournie par des automates; Celui qui est l’auteur, l’origine de quelque chose.

C’est un travailleur manuel. Il travaille pour des particuliers. L’artisan travaille seul, en famille ou avec des compagnons.

On trouve ici l’idée d’un savoir-faire très humain, même s’il utilise la technologie. L’artisan est à la fois concepteur et executant : il est auteur de son oeuvre. L’autre notion qui me parait importante est que l’artisan travaille soit seul soit en groupe. Il peut donc être très polyvalent ou assez spécialisé, ce qui n’enlève rien à son savoir-faire.

Conclusion

En somme, ces débats confirment mes impressions à mon retour en France l’année dernière, après des années passées au Royaume Uni où les diplomes et les étiquettes ont une moindre importance : les métiers du Web et en particulier du Design Web sont peu valorisés notre pays. Les intitulés de postes sont nombreux et fourre-tout mais qu’importe, tout cela est en pleine mutation. Il y a un an j’avais l’impression que tout le monde ne jurait que par Flash ici, mais déjà j’entends un autre son de cloche. Je garde donc espoir pour l’avenir des Artisans du Web.

• Suivez moi sur Twitter
• Suivez Francis Chouquet sur Twitter
• Suivez Eric Daspet sur Twitter

CSS3 en bref

CSS3 permet la création d’effets visuels qui ne pouvaient pas être réalisés auparavant, ou qui nécessitaient du marquage en plus et/ou du Javascript.

En bref, CSS3 simplifie le job de l’intégrateur et met plus d’outils à sa disposition.

Parmi les nouveautées inclues dans les specifications CSS3, on trouve :

• text-shadow : en une ligne on peut ajouter une ombre portée à du texte, et bien plus encore car on peut ajouter autant d’ombres qu’on le souhaite. Pour chaque ombre on définit les distances par rapport au texte d’origine sur les axes x et y, ainsi qu’une valeur de flou. Voici un exemple.
• RGBA : avant on avait la propriété « opacity » qui permettait de rendre des objets translucides. L’inconvénient c’est que tout ce qui est contenu dans cet objet devient translucide, ce qui peut rendre les textes moins lisibles. Avec RGBA on peut définir des couleurs de fond et leur degré d’opacité avec la propriété « background », donc pas de problème de texte illisible.
• Images de fond multiples : avec CSS3 on n’est plus limité à une image de fond par objet ; le nombre est a priori illimité.
• box-sizing : cette propriété permet de changer le « box model ». On a la possibilité d’inclure le padding dans la taille de l’objet, ou le padding + la bordure.

Cette liste n’est pas exhaustive ; Il existe bien d’autres propriétés : dégradés, animations, rotations et autres.

Le problème

Toutes ne sont pas compatibles avec les mêmes navigateurs et à ma connaissance, aucune n’est compatible avec les versions 7 et 8 d’Internet Explorer. Il faudra attendre IE9 pour voir du CSS3 chez Microsoft. (Voir ce tableau de compatibilité des navigateurs avec CSS3.)

Comment utiliser CSS3 dès aujourd’hui alors que Internet Explorer concerne plus du tiers des internautes ?

Cela va dépendre du projet, car si vous créez un site pour un public en particulier qui utilise à 80% IE7, ce n’est peut-être pas très intéressant d’utiliser CSS3. En revanche si votre public se situe dans la moyenne avec 35% de IE, ou mieux, si vous vous adressez à un public assez « geek », vous pouvez dès maintenant utiliser CSS3 tout en travaillant sur des vues alternatives pour les navigateurs moins évolués.

Par ailleurs, il faut savoir que certaines propriétés CSS3 peuvent être reproduites à l’aide de filtres pour IE (ombres, transparence, rotations). Ces filtres sont un peu pénibles à utiliser et ne produisent pas exactement les mêmes effets que CSS3 mais ça peut dépanner. Ne pas oublier de les mettre dans des feuilles de style séparées.

Solution : la dégradation gracieuse

Il est tout a fait possible de concevoir un site utilisant CSS3 pour des effets d’ombres, de rotations, de dégradés ou autre, et d’offrir une version alternative, plus simple, aux navigateurs moins évolués.

Cas pratique : CannyBill.com

Le site CannyBill.com a été réalisé par Andy Clarke. Si vous visualisez ce site sur plusieurs navigateurs vous verrez quelques petites différences. Cet article écrit par Andy Clarke explique sa démarche et présente des aperçus des différents navigateurs.

Selon Andy Clarke, star du Design Web et défenseur des standards Web, il ne faut pas chercher à obtenir exactement le même design dans tous les navigateurs ; il faut produire la meilleure version du site pour le meilleur navigateur (sa référence à lui est Safari 4), puis on descend la chaîne des navigateurs jusqu’à IE en adaptant le design.

Au final, l’utilisateur ne se rendra compte à aucun moment qu’il ne voit pas certains effets du fait du navigateur qu’il utilise. On parle donc de « dégradation gracieuse » car quel que soit le navigateur utilisé, l’internaute est face à un site cohérent visuellement.

Cas pratique : For a beautiful web

Sur la page d’accueil il y a 3 jaquettes de DVD en vente. Sur Safari 4, quand on passe la souris sur une jaquette, le DVD sort vers la droite avec un effet de rotation. Sur Firefox 3.6 le DVD sort sans effet de rotation, et sur IE 7 et 8, le DVD ne bouge pas.
Dans aucun de ces cas l’internaute se demande-t-il si c’est normal ou « cassé » – car peu de gens regardent un même site sur 5 navigateurs différents – donc il s’agit d’un petit plus pour les utilisateurs de Safari et Firefox.

CSS3 en 2010

Donc, pourquoi ne pas utiliser CSS3 dès aujourd’hui ? Il existe un outil qui permet de styler les éléments d’une page différemment selon qu’un navigateur supporte telle ou telle propriété CSS3 en incluant un simple fichier Javascript. Il s’agit de Modernizr. Par exemple, si le navigateur utilisé ne supporte pas le RGBA, Modernizr ajoute la classe « no-rgba » sur le tag HTML, ce qui permet de définir d’autres couleurs pour tous les navigateurs qui ne supportent pas RGBA.

Dans cette expérience, j’ai utilisé du RGBA, des images de fond multiples, et la propriété box-sizing pour inclure le padding et la bordure dans les tailles que j’ai défini.

Quelques liens

J’ai trouvé plusieurs outils qui génèrent les styles en donnant les versions des différents navigateurs. Chacun de ces outils ne propose pas les mêmes propriétés donc il faut en utiliser plusieurs.

• CSS3 please
• CSS3 generator
• Plusieurs outils par Western Civilisation :
  • pour les transformations 2D et 3D
  • pour les dégradés
  • pour les ombres de texte
  • pour les contours de texte
• CSS3 gradient generator pour générer des dégradés
• Border radius pour générer des coins arrondis