Openweb.eu.org

Contrastes de texte

Nicolas Hoffmann — 2012-02-16T19:51:00Z

Les contrastes de textes sont un élément essentiel d'accessibilité des sites internet. Un choix judicieux permet de garantir une lisibilité maximale aux personnes ayant un handicap visuel permanent (déficience visuelle, etc.), temporaire (fatigue, écran de mauvaise qualité, etc.)… et toutes les autres.

Bien souvent par méconnaissance, les contrastes de textes sont traités rapidement, pour ne pas dire ignorés. Ils sont pourtant un point très important d'accessibilité, et plus largement de lisibilité des contenus des sites internet. Qui plus est, en pleine connaissance du sujet, c'est un point d'accessibilité en général assez facile à traiter grâce aux CSS et qui apporte de grands bénéfices.

Même les personnes n'ayant pas à proprement parler de handicap en bénéficient également : l'expérience de lecture est d'autant plus agréable si l'internaute n'a pas à plisser les yeux pour lire un texte !

Quelques statistiques :

il est estimé que 15% à 20% de la population des États-Unis ont des difficultés pour lire (en incluant la dyslexie),
selon l'INSEE (2002), 3,346 millions de personnes en France déclaraient avoir une déficience visuelle,
environ 8 à 12% de la population mondiale serait dyslexique, dont 5 à 15% des enfants,
la fréquence des daltoniens est, en moyenne, de 8% dans la population masculine et 0,5% dans la population féminine mondiale.

Les problèmes de vue s'accentuant avec l'âge et le secret de l'éternelle jeunesse n'ayant pas encore été découvert, il est aisé de comprendre qu'un jour ou l'autre, inévitablement, la question de la lisibilité des textes va se poser à une grande majorité de personnes.

Recommandations WCAG, un bon indicateur

Contrastes

Selon les recommandations WCAG 2.0 du W3C, pour obtenir le niveau AA, la règle 1.4.3 nous indique ceci :

Le texte (ou les images de texte informatif) de moins de 18 points (ou moins de 14 points en gras) devrait posséder un contraste de luminosité d'au moins 4,5 pour 1 avec son arrière-plan. Le texte (ou les images de texte informatif) de plus de 18 points (ou plus de 14 points en gras) devrait posséder un contraste de luminosité d'au moins 3 pour 1 avec son arrière-plan.

Toujours selon les mêmes recommandations WCAG 2.0, pour obtenir le niveau AAA, la règle 1.4.6 nous indique :

Le texte (ou les images de texte informatif) de moins de 18 points (ou moins de 14 points en gras) devrait posséder un contraste de luminosité d'au moins 7 pour 1 avec son arrière-plan. Le texte (ou les images de texte informatif) de plus de 18 points (ou plus de 14 points en gras) devrait posséder un contraste de luminosité d'au moins 4,5 pour 1 avec son arrière-plan.

Note importante : les chiffres et recommandations de contrastes énoncés dans cet article ne sont applicables qu'à une lecture sur écran.

Vous pouvez trouver les formules mathématiques pour calculer les contrastes.

Luminosité et différence de tonalité

D'autres indicateurs sont intéressants en plus du calcul de contraste : la luminosité et la différence de tonalité. Les formules pour calculer la luminosité et la différence de tonalité sont également disponibles. Toutefois vu leur complexité, les expliquer en détail impliquerait un article bien plus long.

Il est recommandé d'avoir une luminosité supérieure ou égale à 125 et une différence de tonalité supérieure ou égale à 500 pour garantir une bonne lisibilité.

Bien sûr, il est hors de question de faire à chaque fois des calculs laborieux pour chaque couleur de texte et sa couleur de fond, des utilitaires permettent de le faire rapidement, d'obtenir ces informations… et bien sûr d'agir en conséquence.

Des utilitaires pour étudier les contrastes des textes

Color contrast check

Color contrast Check est un utilitaire web très pratique, il affiche les valeurs des contrastes et si ces derniers sont conformes aux recommandations WCAG. Il indique également la luminosité ainsi que la différence de tonalité. Plus pratique encore, il permet d'adapter les couleurs directement et de voir l'impact sur les résultats. Ainsi, cela permet d'étudier et d'adapter les choix de couleurs rapidement et efficacement.

Contrast-A

Contrast-A est plus orienté « recherche de couleurs » et « choix de palettes ». Néanmoins, il est très complet :

il permet également de visualiser ces choix avec différents types de handicaps, comme les différents types de daltonisme (la protanopie, la deutéranopie et la tritanopie) et la déficience totale de vision des couleurs (color blindness en anglais),
des notes sont attribuées aux choix des couleurs selon chacun des handicaps,
et toutes les valeurs sont calculées : les contrastes ainsi que la luminosité et les différences de tonalité.

Color contrast analyser

Color contrast analyser est un logiciel (sous Windows et Macintosh) qui permet de calculer la luminosité et la différence de tonalité ainsi que ces valeurs pour les différents types de daltonisme, ce qui permet de voir si les pages sont correctement consultables par des personnes souffrant de ces handicaps. Il est très complet et très simple d'utilisation.

Extensions Firefox

Des extensions comme WCAG contrast checker pour Firefox permettent de rapidement évaluer les contrastes des textes. Un simple clic vous permet de rapidement voir si vos textes sont conformes aux recommandations WCAG 2.0.

Autres outils sur les logiciels de graphisme

Photoshop intègre depuis la version CS4 des filtres pour le daltonisme, ils sont sous Affichage > Format d'épreuve > Dyschromatopsie (protanopie et deutéranopie). Il existe également des plugins comme ceux proposés par VisCheck.

Gimp a lui aussi des outils dédiés aux problèmes de visions.

Inkscape, un logiciel libre de graphisme vectoriel, a également des extensions dédiées aux problèmes de vision des couleurs.

Note importante : même si l'article se concentre uniquement sur les contrastes (pour d'évidentes raisons de longueur), la lisibilité des textes ne se résume pas uniquement à cette question. Certains des outils présentés ci-dessus tiennent compte de la taille du texte, mais d'autres facteurs peuvent influencer la perception des contrastes de couleurs et modifier la gêne occasionnée pour l'utilisateur :

le choix de la police (avec ou sans sérif, la forme et l'épaisseur des caractères),
les styles appliqués (gras, italique, lettres capitales),
l'espace entre les lettres et entre les lignes (pensez à une valeur suffisante pour line-height en CSS),
la longueur du texte (ce qui est acceptable pour un titre ne le sera pas forcément pour de longs paragraphes),
le comportement de la police au redimensionnement effectué par l'utilisateur,
la qualité de l'anticrénelage de la police selon le système d'exploitation et/ou le logiciel utilisé,
etc.

Des recommandations, des valeurs… mais pas une finalité

En prenant les recommandations énoncées et en utilisant « bêtement » les outils proposés ci-dessus, nous pourrions croire par exemple que les contrastes très forts conviennent parfaitement, que ce soit une couleur claire sur fond sombre ou une couleur sombre sur fond clair… ce n'est pas du tout aussi simple !

Contraste négatif ou positif ?

Les recherches ont prouvé que les textes à contraste positif (texte foncé sur fond clair) sont plus lisibles que ceux à contraste négatif (texte clair sur fond sombre).

Ajoutons à cela d'autres cas de figure :

un fond sombre accentue les problèmes de reflets, très gênants notamment en situation de mobilité, encore plus si vous avez un soleil puissant dans le dos,
autre cas en situation de mobilité, l'écran d'un ordinateur portable sera bien moins lumineux pour économiser de la batterie, un contraste négatif insuffisant risque d'handicaper la lecture.

Note : rappelons bien que le but n'est pas de proscrire des combinaisons de couleurs ou d'interdire les contrastes négatifs, mais de chercher une lisibilité maximale.

De forts contrastes positifs ?

Les trop forts contrastes, même positifs, agressent l'œil, gênent la lecture et accentuent la fatigue oculaire.

Le noir pur #000 sur fond blanc pur #fff gêne par exemple les dyslexiques : le contraste trop élevé a tendance à faire « trembler » ou « bouger » les textes. Ce phénomène est décrit sous le nom de « syndrome d'Irlen » ou « syndrome de sensibilité scotopique » et ne concerne pas uniquement les dyslexiques.

Pour donner un autre exemple, un texte noir pur sur fond blanc pur accentue l'effet de halo pour les personnes âgées et/ou sensibles à la lumière. Pour avoir une idée de cet effet, il suffit d'imaginer lire un texte dans une pièce sombre sur un écran très lumineux, il faudra plisser les yeux pour distinguer le texte car la forte lumière du fond blanc aura tendance à être aveuglante.

Dans ces cas, il faudra soit utiliser un gris très léger en couleur de fond au lieu d'un blanc pur, soit éclaircir légèrement le noir pur du texte.

Conclusion

Tout est dans l'équilibre : un bon contraste est nécessaire et important, toutefois, les valeurs trop extrêmes sont à éviter. De très nombreux outils permettent de trouver des valeurs satisfaisantes, et ce aussi bien au niveau de la création du graphisme qu'au niveau de l'intégration CSS.

Il est même même fréquent de constater qu'une très légère adaptation avec les outils précités apportera beaucoup de confort de lecture en plus, même pour les publics n'ayant pas à proprement parler de handicap visuel.

Références, compléments :

Ne perdez plus vos internautes, faites du card sorting / tri de cartes - Troisième partie : Résultats, analyse et (re)conception

Eric Mazzone, Gautier Barrère — 2012-02-02T19:32:41Z

Vous savez désormais ce qu'est le tri de cartes et comment le mettre en place. Découvrez sans plus attendre comment analyser les résultats et préparer le terrain pour une reconception efficace.

Au départ, vous obtiendrez des données brutes par participant. Ces données doivent être consolidées avant d'être analysées. Sachez que le travail à mener mobilise une expertise assez pointue. Si vous avez ces compétences à disposition, il faut vous en servir et si ce n'est pas le cas, il faudra sans doute faire appel à un spécialiste.

Faites l'analyse sans le client afin de garantir une objectivité maximale et d'éviter toute forme d'influence. Le client aura toutefois un rôle important pour aligner les solutions que vous proposerez à son organisation.

Pour analyser les données vous devrez combiner 2 techniques :

analyse quantitative ;
analyse exploratoire.

Analyse quantitative

L'analyse quantitative permet d'identifier rapidement les éléments qui posent problèmes et ceux qui peuvent être validés en exploitant uniquement les données chiffrées collectées. Pour être analysées, ces données peuvent être consolidées dans différentes matrices.

Matrice de co-occurrences

La matrice de co-occurrences permet d'identifier les cartes les plus souvent associées entre-elles par les participants et ainsi de constituer des grappes de cartes (un ensemble de cartes qui pourront être rassemblées dans un groupe).

Dès lors que deux contenus sont associés par au moins ¾ des participants, on peut considérer qu'ils peuvent être catégorisés ensemble d'un point de vue utilisateur. Les taux inférieurs nécessitent une analyse plus approfondie afin de vérifier les raisons pour lesquelles l'association n'est pas systématique.

Ci-dessus, la carte “Atelier 5 - 14h00-15h30 le …” a été classée par 96% des utilisateurs avec la carte “Atelier 7 - 14h00 - 15h30. Les cartes doivent donc bien être placées dans la même catégorie.

Matrice de propagation

La matrice de propagation illustre les différents groupes dans lesquels les participants ont placé les cartes. Contrairement au mode de tri de cartes fermé, lors d'un tri de cartes ouvert, la définition des groupes est entièrement libre (les utilisateurs peuvent nommer les groupes comme ils le souhaitent) ce qui rend l'analyse plus complexe car des termes différents peuvent être utilisés pour désigner une même catégorie. Une analyse des catégories et une fusion des termes ayant le même sens doit être faite avant d'analyser la matrice.

Ci-dessus, on peut voir que la carte “Dossiers dans lesquels on …” a été classée par 67% des utilisateurs dans le groupe nommé “Catégories”.

Certaines cartes ont une forte propagation et sont classées de manière égale avec toutes les autres cartes et/ou catégories. C'est à double tranchant : cela veut soit dire que la carte doit être proposée partout de manière contextuelle, soit qu'elle ne se rapproche d'aucune autre.

Dendrogramme

Le dendrogramme propose une vue complémentaire à la matrice de co-occurrences en illustrant la distance entre les cartes. La distance est calculée en fonction de la fréquence d'association de deux cartes ou deux groupes de cartes. Plus la fréquence d'association est élevée, plus les cartes sont considérées comme proche.

Avec les dendrogrammes, il est aisé de faire varier le nombre de groupe souhaité. Par exemple si vous souhaitez constituer sept groupes, il suffit de diviser le dendrogramme en sept sections définies par la distance euclidienne la plus longue à considérer.

Analyse exploratoire

Selon l'objectif souhaité il est possible de réaliser l'analyse exploratoire avant ou après l'analyse quantitative. Par exemple, si vous souhaitez d'abord identifier une tendance, vous pouvez commencer une l'analyse exploratoire sans requérir à des matrices complexes.

L'analyse exploratoire peut compléter ou remplacer l'analyse statistique. Elle permet notamment :

d'illustrer les tendances ou les logiques de classement ;
d'identifier les raisons d'une forte dispersion d'une carte (dans ce cas elle complète l'analyse statistique) ;
d'identifier la compréhension des contenus.

Le card sorting in situ est plus propice à l'analyse exploratoire : on peut revenir sur ce que les gens ont fait et en discuter avec eux. A distance, c'est plus délicat.

Reconception avec ou sans le client ?

Faites la reconception avec le client. Cela vous permettra d'intégrer les besoins organisationnels et marketing dans la reconception.

Proposition de solutions

Une fois l'analyse réalisée, vous aurez un ensemble de données à votre disposition vous permettant d'émettre des hypothèses de structure.

Faites la reconception avec le client. Suite aux séances de tri de cartes vous devrez fournir à votre client une structure d'informations qui devra s'intégrer avec ses contraintes. Par exemple certains termes devront être obligatoirement utilisés parce qu'ils sont déjà employés dans d'autres supports commerciaux. Votre proposition devra allier les résultats issus des séances de tri de cartes et les contraintes de votre client.

Votre état des lieux devra mettre en avant :

les contenus mal intitulés ;
les contenus qui ne sont pas à la bonne place et catégories mal intitulées ;
les besoins d'une nouvelle catégorie (même si ce n'est pas la finalité d'un tri) ;
les besoins de liens réciproques ;
les différences de catégorisation selon les profils ciblés.

Lors de la reconception, n'oubliez pas les fondamentaux, qui ne ressortiront pas forcément des résultats du card sorting :

organisez votre arborescence de manière thématique et non organisationnelle ;
faites une arborescence d'abord en largeur puis en profondeur ;
faites une arborescence régulière ;
limitez la profondeur de l'arborescence.

Utilisez des visuels pour communiquer

Évitez de venir avec des matrices de co-occurence et des dendrogrammes auprès de votre client. Venez avec la cartographie visuelle de l'arborescence que vous proposez.

Conclusion

Il y a tellement de profils utilisateurs, de contextes d'utilisation et de logique d'utilisation différentes que l'on n'est jamais sûr de rien sans impliquer les utilisateurs.

On ne peut définitivement pas se mettre dans la peau de l'utilisateur et faire une arborescence dans son coin.

SVG ou Canvas, que choisir ?

Jeremie Patonnier — 2012-01-25T16:35:49Z

Depuis plusieurs années que je m'intéresse à SVG et aux nouvelles possibilités qu'offre HTML5, on me pose régulièrement cette même question : « Quel est le mieux entre SVG et Canvas ? ». Je réponds alors stoïquement et laconiquement : « Les deux mon capitaine, ça dépend ». En effet, ça dépend, voilà donc un petit guide pour vous aider à choisir entre ces deux technologies.

Voyons tout d'abord ce que ces technologies ont en commun. Après tout, s'il est si difficile de choisir entre l'une et l'autre c'est qu'elles semblent offrir les mêmes choses... Mais quoi exactement ? Pour mémoire, SVG est un format d'image vectoriel et Canvas une balise HTML5 permettant d'y dessiner ce que l'on veut. Toutes deux permettent donc de créer des images directement dans le navigateur. Dès l'instant où vous allez vouloir utiliser les capacités de votre navigateur pour produire des images, vous allez donc vous poser la fatidique question. Et soyons honnêtes, les cas d'usage de ces deux technologies se recoupent souvent.

Il est très rare que dans le cadre du Web nous ayons deux standards qui fassent la même chose... En fait, cela n'arrive jamais. En effet, si ces deux technologies cherchent en apparence à atteindre le même objectif (dessiner), elles ne vont pas du tout le faire de la même manière ni dans des conditions identiques, et c'est là que va se nicher le délicat choix entre l'une et l'autre. J'en profite ici pour évacuer immédiatement une question récurrente liée au support des standards : tous les navigateurs supportant l'une de ces technologies supportent également l'autre, ce qui inclut Internet Explorer 9 et suivants.

Vecteurs contre bitmap

La première différence entre ces deux technologies tient aux types de données qu'elles manipulent. SVG est un format vectoriel, là où Canvas est un format bitmap. On a donc d'un côté, des formes définies à l'aide de points et de courbes, et de l'autre une bouillie de pixels anonymes.

La différence entre les deux va donc se jouer sur des questions assez simples finalement : si vous devez envisager un redimensionnement sans perte de qualité, SVG sera plus indiqué. À l'inverse, si vous devez réaliser des opérations complexes sur les pixels (ce qui est le cas quand vous devez interpoler deux images ou si vous travaillez sur un flux vidéo en temps réel par exemple) c'est Canvas qui sera le plus indiqué.

Déclaratif contre programmatif

Une autre différence de fond entre ces deux technologies tient à la façon de les utiliser. SVG est un langage qui repose sur une syntaxe XML, il est dit déclaratif : en clair, vous dites explicitement au navigateur ce qu'il doit dessiner et il se débrouillera au mieux de ses capacités pour le faire. Canvas lui, repose sur une API (plusieurs en fait, mais là, je vais me concentrer sur l'API de dessin 2D qui est la plus proche de SVG) qui est accessible via JavaScript : vous allez devoir programmer la façon dont le navigateur va devoir dessiner ce que vous voulez.

Ces deux approches ont chacune leurs avantages et leurs défauts. Par exemple, si vous avez une question de performance à gérer, Canvas sera sans doute plus approprié. En effet, dans une approche programmative, vous contrôlez la méthode de dessin avec beaucoup plus de précision et pouvez mettre en place des stratégies d'optimisations spécifiques selon vos propres besoins. Par contre, dans une approche déclarative, c'est le navigateur qui décidera de la façon de dessiner votre image en effectuant lui même les opérations d'optimisation qu'il estime nécessaires.

Prenons le problème sous un autre angle : si vous devez dessiner des objets complexes, SVG sera sans doute plus adapté. En effet, la méthode déclarative de SVG propose, par essence, un degré d'abstraction plus important que l'API 2D de la balise canvas (et je ne vous parle même pas de WebGL). Elle vous permet donc de dessiner des courbes extrêmement complexes avec un effort ridicule en comparaison de Canvas (sans même parler des logiciels de dessin qui vous offrent une interface hyper intuitive pour dessiner ces formes et les exporter directement en SVG). À l'inverse, si vous devez mettre en œuvre des interactions complexes entre formes, la souplesse de l'API Canvas 2D vous offrira des outils bien plus simples à manipuler pour contrôler l'efficacité et les performances de vos dessins.

DOM or not DOM, zat iz ze question

SVG reposant sur une syntaxe XML, son interprétation par un navigateur conduit à la construction d'un arbre DOM qui comprendra l'ensemble des éléments qui constituent l'image. De son côté, Canvas n'est pas encombré par cette contrainte et une image dessinée via cette API ne donnera pas lieu à sa représentation dans un arbre DOM.

La question est donc : « Avez-vous besoin d'un arbre DOM lié à votre image ? ». Disposer d'un tel arbre offre certains avantages. D'un point de vue accessibilité par exemple, un arbre DOM sera visible par les technologies d'assistance et en cas de besoin, vous pouvez même envisager de rajouter des rôles Aria à votre arbre pour qu'il soit plus facilement compris. D'un point de vue plus technique, chaque élément de l'image étant accessible via l'API DOM, il est extrêmement facile de les manipuler individuellement et partiellement sans avoir à vous soucier de garder à la main un état pour chacun d'entre eux.

Mais ne pas avoir d'arbre DOM a aussi de nombreux avantages en particulier pour les performances. En effet, créer et maintenir un arbre DOM requiert d'importantes ressources surtout en terme de mémoire. Accessoirement, l'API DOM est notoirement lente et cela se fera particulièrement ressentir si vous devez traiter de très nombreux éléments très vite (par exemple pour certaines animations) ou simultanément (pour les jeux par exemple)

Considérations annexes

Un dernier point qu'il ne faut pas oublier : SVG, contrairement à Canvas, est un vrai format d'image indépendant. En conséquence, vous pouvez l'utiliser partout où l'on peut traditionnellement utiliser des images : en temps qu'arrière-plan ou contenu généré via CSS ou au sein d'une balise img en HTML. De même en temps que format d'image, il existe pléthore de logiciels qui permettent d'exporter au format SVG ce qui n'est pas du tout le cas avec Canvas.

Je vous ai également épargné les évidences comme, par exemple, le fait qu'en l'absence de JavaScript, les images Canvas ne seront pas affichées là où les images SVG, elles, le seront.

Conclusion

Chacune des ces technologies a donc ses avantages et ses inconvénients. Là où cela devient intéressant, c'est quand vous commencez à mixer les deux : les possibilités ouvertes sont alors quasi infinies. En effet, certaines fonctionnalités natives de SVG sont très complexes à implémenter avec Canvas (par exemple, les formes de découpe via l'élément clipPath). De même réaliser des transformations au niveau des pixels est impossible avec SVG (par exemple réaliser un détourage dynamique de type "fond vert" sur la base d'une image rasterisée). Ainsi, si vous utilisez les deux technologies simultanément, vous arriverez à faire des choses étonnantes. Par exemple un détourage vidéo réalisé avec Canvas qui, via Javascript, génère dynamiquement un éléments SVG clipPath permettant de superposer cet élément vidéo sur du contenu HTML, tout en laissant ce contenu HTML sélectionnable. Les possibilités étant énormes, voila deux petits exemples concrets pour vous faire une idée : Un puzzle vidéo (à voir avec Firfox pour un meilleur résultat) et une galerie d'image composite.

Prenez le temps d'expérimenter les deux technologies et de bien regarder celle qui correspondra le mieux à vos cas d'usage. Céder à la facilité en n'en utilisant qu'une seule vous conduira nécessairement à des impasses ou à des pertes de temps liées au syndrome "réinvention de la roue".

Sprites CSS : performance et maintenabilité

Nicolas Hoffmann — 2011-08-16T15:09:16Z

L'optimisation des performances des sites implique de diminuer le nombre de requêtes HTTP. Pour ce faire, il est possible de regrouper les images utilisées dans les CSS, cette technique s'appelle les sprites CSS.

Présentation de la technique

La technique dites des sprites CSS consiste à exploiter un fichier unique pour stocker de multiples images, positionnées les unes à côté des autres. Celles-ci seront ensuite appelées dans la feuille de style, et la fenêtre d'affichage sur l'une ou l'autre image sera définie en CSS grâce à la propriété background-position.

Les avantages des sprites CSS sont multiples :

cela permet de se passer totalement de JavaScript : il n'y a pas besoin de préchargement d'images ni de gestionnaire d'événement comme onmouseover pour déclencher l'effet survolé, tout se fait via les propriétés CSS,
dans les cas de recherche de performances ou d'optimisations pointues, cette technique permet d'obtenir des résultats très intéressants en réduisant le nombre de requêtes au serveur pour afficher plusieurs images,
comme cette technique se base sur (X)HTML et CSS, tous les avantages de ces derniers utilisés à bon escient sont présents : séparation présentation/structure, code lisible et léger, accessibilité, etc.

Attention : la technique des sprites CSS n'est utile que pour des images à but décoratif, il ne faut pas remplacer toutes les images ainsi. Les images faisant partie du contenu doivent rester dans le code HTML.

Exemple d'intégration d'un menu de navigation

Plutôt qu'un long discours, voyons comment construire un menu de navigation utilisant cette technique. Voici le code HTML de ce menu :

   A propos des sprites 
  Sprites par ci 
  Sprites via CSS 
  Sprites inside

Nous avons donc une image contenant les trois états possibles (de bas en haut) : actif (page courante), normal et survolé.

Il va de soi qu'il est possible d'utiliser les sprites CSS de plein de manières différentes. Le postulat de cet exemple est le suivant : l'image de fond de #navigation contiendra la partie de l'image avec les liens dits « actifs », et les liens seront positionnés chacun par dessus.

Quand on survolera le lien, il suffira de décaler l'image. Si un élément doit être affiché comme actif (pour indiquer à l'internaute sur quelle partie il se situe), il utilisera une classe active, qui fera disparaître l'image du lien... ce qui fera apparaître l'image de fond.

Les propriétés générales permettent de positionner l'arrière-plan et le menu, ainsi que le texte du lien :

#navigation{ margin:0 auto; padding:0; width:549px; height:70px; background:#fff url(sprites.jpg) 0 -140px no-repeat; } /* pour chaque lien, propriétés communes */ #navigation li{ float:left; list-style-type: none; } #navigation a{ margin:0; display:block; height:70px; width:97px; background:url(sprites.jpg) 0 0 no-repeat; font-size:17px; padding:20px 22px 0 18px; }

La liste navigation prend donc en fond la partie de l'image contenant les images des liens actifs. Chaque lien vient se positionner et aura la même image de fond, les textes sont également positionnés à l'aide du padding.

Ensuite, chaque fond de chaque lien est positionné.

 #navigation #aboutsprites{ background-position:0 -70px; } #navigation #spritesci{ background-position:-137px -70px; } #navigation #spritescss{ background-position:-274px -70px; } #navigation #spritesinside{ background-position:-411px -70px; }

L'effet de survol se fera en décalant l'image de fond, dans notre exemple, elle sera décalée de 70 px vers le haut pour chaque lien.

 #navigation #aboutsprites:hover, #navigation #aboutsprites:active, #navigation #aboutsprites:focus{ background-position:0 0; } #navigation #spritesci:hover, #navigation #spritesci:active, #navigation #spritesci:focus{ background-position:-137px 0; } #navigation #spritescss:hover, #navigation #spritescss:active, #navigation #spritescss:focus{ background-position:-274px 0; } #navigation #spritesinside:hover, #navigation #spritesinside:active, #navigation #spritesinside:focus{ background-position:-411px 0; }

Note : les propriétés background-position-y et background-position-x existent et auraient été bien utiles dans ce cas. Mais elles ne sont pas reconnues comme standards, et donc ne sont pas implémentées dans tous les navigateurs. Dommage !

Le menu est presque terminé, il ne nous reste plus qu'à désactiver le soulignement du texte des liens.

 #navigation a{ text-decoration:none; }

La classe active est assurée simplement par cette ligne.

 #navigation .active{ background-image:none; }

Voici le résultat final de l'exemple de menu utilisant les sprites CSS.

Attention : une précédente version utilisait une technique très légèrement différente, toutefois, un bug curieux sur toutes les versions d'Internet Explorer (9 comprise) empêche le fonctionnement optimal de ce menu (le clic droit sur le texte du lien pour l'ouvrir dans un nouvel onglet ne fonctionne pas correctement). À ce jour, nous n'avons pas d'explication rationnelle à vous donner... si ce n'est que le problème semble venir de display:inline-block sur le span du menu. En contournement, la nouvelle version utilise la propriété padding sur #navigation a pour positionner le texte à l'intérieur du lien.

L'exemple peut être qualifié de cas d'école et fonctionne très bien :

au lieu de 12 requêtes (3 états fois 4 images), nous avons une seule requête HTTP pour l'image de notre menu de navigation,
le code CSS est plutôt léger et relativement simple,
aucun code Javascript n'est nécessaire pour le faire fonctionner,
comme dans l'exemple, les images ont un lien logique entre elles (ce sont toutes les images du menu de navigation), générer cette image reste aisé, il n'y a pas de forte contrainte de positionnement pour le graphiste,
le décalage étant instantané, l'illusion d'image réactive est parfaite,
le code HTML reste très "naturel", ce qui implique une dégradation correcte si les CSS sont désactivées et une facilité d'évolution (version smartphone, refonte, etc.),
les sélecteurs permettant de définir le menu sont extrêmement simples et efficaces : la vitesse de rendu en sera améliorée,
comme le texte de chaque lien n'est pas pris dans l'image de fond, le texte du lien reste visible si les images sont désactivées ou injoignables,
petit détail qui a son importance : si les images sont effectivement désactivées ou injoignables, il faut penser à vérifier que la couleur de fond du lien soit bien identique à celle de l'image. Dans notre exemple, c'est assuré par background:#fff; dans #navigation.

Conclusion

Cette technique dite des sprites CSS permet de concilier une intégration CSS sans préchargement avec des contraintes de performances, dans notre cas, sans pour autant perdre en accessibilité.

Evidemment, mettre toutes les images en une seule peut compliquer la maintenance du site. Pour des raisons pratiques, il sera préférable de regrouper les images ayant un lien logique entre elles. Si la quête de performances doit être poussée à l'extrême pour un site à très fort trafic, toutes les images décoratives du site peuvent être groupées, dans ce cas, il sera nécessaire de définir exactement où doivent être positionnées chacune desdites images.

A titre d'exemple récent, les sprites CSS ont été utilisés pour le logo de Google commémorant l'anniversaire de Les Paul. Vous pouvez voir l'image utilisée pour réaliser le logo animé.

Références, compléments :

Les Performances web, pour aller plus loin

Nicolas Hoffmann — 2011-07-03T15:42:52Z

Dans Introduction à la performance web, les bases des bonnes pratiques et des enjeux de la performance web ont été posées. Cet article a pour but d'aller plus loin dans ce vaste domaine en décryptant l'affichage d'une page et les pistes pour l'accélérer.

Principe du chargement d'une page

Le graphique en cascade (waterfall en anglais) permet de mieux comprendre comment une page s'affiche. Voyons un exemple réalisé avec Web Page Test qui, dans ce cas, simule un chargement d'une page :

Le vocabulaire

Posons les bases du vocabulaire : ce graphique en cascade indique le chargement d'une page. Cet exemple est un premier accès (First view) : il faut tout télécharger, nous ne bénéficions pas de la mise en cache des contenus. Nous pourrons voir plus loin dans cet article les avantages cette mise en cache dans un second accès (Repeat view).

La requête DNS (DNS Lookup) permet de connaître l'adresse IP correspondant au nom de domaine demandé, ce qui permettra de s'y connecter.

La connexion initiale (Initial Connection) indique le temps pour effectuer la connexion TCP/IP afin de lancer le téléchargement de chaque fichier.

Le début de rendu (Start Render) indique le moment où le navigateur commence à effectuer son travail de rendu, après avoir téléchargé les fichiers CSS (symbolisé par la barre verticale verte sur l'image ci-dessus).

La barre bleue indique quand le document est complet (Document Complete), c'est-à-dire quand les éléments demandés pour le rendu de la page ont tous été téléchargés et rendus.

Une nuance importante : nous pourrions penser que le document est à la fin du téléchargement des éléments. Il n'en est rien : le document est considéré comme totalement chargé (fully-loaded) peu après la barre du document complet. Dans notre exemple, l'icône de favori se charge après que la page ait été rendue. Nous y reviendrons.

Le nombre d'éléments dans le DOM indique également la complexité de la page. Un DOM conséquent (supérieur à 1000 éléments) sera plus long à afficher par les navigateurs, particulièrement les moins récents comme Internet Explorer 6.

Premières observations

Même si dans notre exemple il n'y a qu'un nom de domaine, il ne peut rien se passer sur un nom de domaine avant qu'il ne soit « résolu » (en vert foncé sur l'image) : cela peut handicaper fortement le rendu d'une page si ces derniers se sur-multiplient. Il est donc aisé de comprendre pourquoi par exemple Google Page Speed recommande de minimiser les requêtes DNS à résoudre.

Néanmoins relativisons ce propos : la ligne de conduite généralement admise est la suivante : un navigateur peut effectuer six requêtes en parallèle vers un même domaine ou sous-domaine (comme par exemple Firefox 4 et Internet Explorer 9). Internet Explorer 6 et 7 par contre ne peuvent effectuer que deux requêtes simultanées vers un domaine.

A bon escient, cela peut être utilisé pour paralléliser les chargements : 2 domaines = 4 requêtes simultanées pour Internet Explorer 7.

Toujours dans l'exemple, le début de rendu de la page n'intervient pas avant le chargement des CSS et du Javascript placés dans le head… Tout comme la requête DNS bloque le téléchargement des fichiers sur un domaine, le rendu d'une page ne démarre pas avant que les éléments placés dans le head. On comprend aisément pourquoi il est conseillé de minimiser le nombre de CSS et de fichiers Javascript, et pour ces derniers de les placer en bas de page.

Comme notre exemple simule un chargement d'un site en HTML5 sous Internet Explorer, le Javascript est obligatoire dans le head.

Même si l'exemple ne comporte que très peu d'images (une dizaine) sur une page plutôt légère (3 ko), on peut constater que la partie pure du rendu des contenus par le navigateur est déjà plus longue que le temps écoulé avant le début du rendu. Sur des pages plus lourdes, plus complexes et avec plus de fichiers, cette partie augmente drastiquement. C'est pour cela que, souvent par abus de langage, on parle d'optimisation de performances web, on parle d'optimiser l'affichage Front-end (côté navigateur), ce dernier prenant en général le temps le plus conséquent.

Mise en cache avancée

L'exemple de mise en cache des contenus donné dans l'« Introduction à la performance web » était volontairement simplifié à l'extrême. Voyons un exemple plus avancé de mise en cache de contenus dits « statiques » (qui ne sont pas appelés à évoluer, images, CSS, etc.) via un fichier htaccess :

  Header unset Cookie Header unset Set-Cookie Header set Cache-Control "max-age=31536000" header set vary "Accept-Encoding" header append vary "User-Agent" header append Cache-Control "public" header append Connection "Keep-Alive" header append Keep-Alive "timeout=5, max=100" FileETag None

Header unset Cookie et Header unset Set-Cookie permettent d'éviter la gestion des cookies pour ces fichiers statiques (qui peuvent amener des requêtes HTTP inutiles).

Header set Cache-Control "max-age=31536000" gère le contrôle du cache : les éléments sont mis en cache pour une année (le nombre correspond à une année en secondes), c'est-à-dire que le cache est valide une année durant.

header set vary "Accept-Encoding" : Cette instruction indique aux proxies de mettre en cache deux versions de la ressource : une compressée, et une non compressée. Ainsi, cela donne la possibilité aux proxies de proposer les deux versions, selon ce que l'utilisateur demande.

Les deux lignes concernant le Keep-Alive permettent d'activer les connexions persistantes, c'est-à-dire de laisser la connexion ouverte au cas où le navigateur ait d'autres requêtes (ce qui économise des requêtes TCP/IP). Attention, si cela améliore les performances pour le client, cela peut faire consommer des ressources et surcharger le serveur… Et donc impacter les performances. En général, il est recommandé de régler cette option sur un serveur de fichiers statiques.

FileETag None : nous n'utilisons pas les Etags, la mise en cache est correctement assurée par le Cache-Control.

Observons le résultat sur la même page sur une seconde consultation :

Comme nous pouvons le voir, aucun fichier précédemment mis en cache n'est retéléchargé. En résulte une économie conséquente de requêtes HTTP et de bande passante, il ne reste que la page PHP en question. Cette dernière est chargée en 304 millisecondes, et le rendu total passe de 2 secondes à 700 millisecondes (!).

D'autres pistes plus avancées

Lazy-loading

Nous l'avons vu, une bonne utilisation de la mise en cache des contenus permet de bien améliorer la performance lors d'une seconde consultation. Toutefois, il est également possible d'améliorer la première consultation en différant le chargement de certains éléments après que le document soit complet. Des sites comme Twitter ou Gmail utilisent beaucoup cette technique.

On appelle cette technique le lazy-loading (littéralement « chargement fainéant », qu'on traduira plutôt par chargement différé, ou chargement à la demande). Cela se fait via Javascript.

Exemple avec Jquery :

 $(document).ready(function(){ // ici le chargement de vos fichiers // une fois la page chargée et rendue // exemple très simple $('#image_to_load').attr('src','img.gif'); });

Ainsi, l'image ayant l'id image_to_load aura sa source chargée après le rendu de la page.

Attention : ce code est donné juste à titre d'exemple pour expliquer le principe de la méthode, il vaut mieux éviter de laisser une balise img vide.

On peut ainsi ne charger :

que certains types de contenus (exemple : les images contenues dans la page),
que les contenus à la demande (exemple : un système de recherche Javascript, qui ne sera actif que quand on utilise la recherche du site),
ou que les contenus visibles à l'écran, selon que l'utilisateur scrolle sur la page.

Tout cela permet de réduire le temps de chargement de la page. Observons le chargement d'une page avec un chargement différé d'une image :

Web page test le confirme : l'image a bien été chargée après que le document soit rendu.

Attention : certes le gain de performances peut être important, mais ne sacrifiez pas tout aux performances. Prévoyez une solution de repli au cas où Javascript soit désactivé, sinon il pourrait y avoir perte d'information et/ou de référencement si cette technique est utilisée à mauvais escient ! Dans notre exemple, cela peut se faire via la balise noscript qui indiquera au navigateur n'ayant pas Javascript activé de charger l'image, ou via une redirection vers une version n'utilisant pas de chargement différé.

Diminution du nombre de requêtes HTTP via DATA-URL

Les Data-URL permettent de mettre du contenu directement en ligne dans vos CSS ou dans votre HTML.

Voici un exemple dans une CSS :

background:#000 url(pattern_136.gif) repeat; sera remplacé par : background:#000 url(data:image/gif;base64,R0lGODlhOAA4AIAAABUVFQAAACH5 BAAAAAAALAAAAAA4AdgAAAK/TGB5asiuYJKNrWjpxS7zoXTJ 1ZgaW3juaLay5ou2dbyjas5HOv83PvZhDtaMUbUKZ NepnH51ESnQaoNWs2WnNpr0+oF47jA8lCMNY/R5HBKnXar20c4hR6vn7v6vo8NiBRoZ4Rn+DQo p7jGl+d4l+j31XgoSBn5d6m5hVn5JtlZGLoJStrnu ZiHWspp+ijqupoiu0obaWuKS7jLu6ibChmLOdrLW PxqeVxLDCzs3Py8pzwczSoNPZ2tbc2dVgAAOw==) repeat;

(des retours à la lignes ont été ajoutés pour de simples raisons de lisibilité)

En général, le code produit est un petit peu plus lourd que l'image originale sous forme de fichier. Toutefois, cela économise une requête HTTP. Pensez à bien activer la compression GZIP ou DEFLATE pour optimiser cet équivalent textuel d'une image.

La mise en cache de ces contenus est fonction d'où ils ont été insérés : si, comme dans l'exemple, l'image est dans une CSS mise en cache, elle sera donc de facto mise en cache (en tout cas, le code correspondant). Si par contre, le contenu se situe dans une page HTML ou PHP qui n'est pas mise en cache, le code correspondant ne le sera donc pas non plus.

Attention : Les navigateurs récents comme Firefox ou Opera supportent très bien cette possibilité. Quant à Internet Explorer, il ne supporte cela qu'à partir de la version 8… Et ce dernier limite la taille de la Data-URL à 32 ko. On réservera donc cette technique aux très petites images et de préférence décoratives et non utiles à la compréhension de la page. Encore une fois il ne faut pas tout sacrifier aux performances.

Commentaires conditionnels

Les commentaires conditionnels permettent d'appliquer des règles CSS spécifiques pour certaines versions d'Internet Explorer, et ce afin de patcher son moteur de rendu parfois défaillant ou illogique.

Il a toutefois été constaté que ces commentaires conditionnels bloquaient pendant un certain temps le téléchargement des fichiers.

Idéalement, si les performances web sont critiques pour votre projet et si vous pouvez vous passer des commentaires conditionnels, évitez de les utiliser. Toutefois une solution curieuse, mais parfaitement fonctionnelle, résout ce problème : il suffit de mettre un commentaire conditionnel vide en haut de votre source. Exemple :

CONCLUSION

Une meilleure compréhension du mode de chargement et de construction des pages permet d'en optimiser la vitesse de chargement. Une mise en cache soignée ainsi que des chargements différés peuvent accélérer le rendu de vos pages très efficacement.

Il va de soi que cet article n'est pas exhaustif, d'autres techniques sont possibles, elles feront l'objet de probables futurs articles.

Références et outils :

Améliorez la qualité et l'accessibilité de vos sites web

Elie Sloïm — 2011-05-30T12:52:06Z

Pour répondre aux évolutions futures comme aux besoins en termes de qualité et d'accessibilité, la conception et le suivi d'un projet de site web suppose de respecter cinq étapes. Revue de détail.

Cet article est paru dans le numéro No 239 du journal Archimag (novembre 2010). Nous remercions la rédaction de ce journal pour leur aimable autorisation.

Concevoir un site internet peut sembler relativement simple. Mais lorsqu'il s'agit d'obtenir un site pratique, évolutif et accessible, la tâche devient beaucoup plus ardue. Pour créer un site que vous n'aurez pas envie de jeter ou de refaire complètement après quelques mois et, surtout, qui réponde aux attentes de vos internautes, il est essentiel de bien définir vos objectifs et vos ambitions. La production d'un cahier des charges détaillé devrait vous aider à mettre en ligne un service satisfaisant à la fois ses utilisateurs et ses concepteurs. Cependant, même avec un bon cahier des charges, les attentes et exigences que vous avez en matière de qualité ou d'accessibilité peuvent être interprétées de manière très différente par les prestataires. C'est pourquoi il existe des référentiels pour définir le niveau attendu de qualité du site. Ces standards peuvent vous aider à préciser vos attentes en matière de qualité ou d'accessibilité.

1 Démarrez avec des idées claires

Pour commencer, parlons d'accessibilité. Rendre un site accessible consiste à faire en sorte qu'il soit consultable par tous les internautes, quel que soit leur contexte de navigation. Par exemple, certains utilisateurs seront amenés à écouter vos pages grâce à une synthèse vocale dans un logiciel de lecture d'écran. D'autres internautes, dans l'impossibilité d'utiliser leur souris, seront amenés à naviguer au clavier, avec des dispositifs de pointage spécifiques ou encore avec des outils ou logiciels d'assistance. Ces cibles peuvent a priori sembler minoritaires mais un créateur de site qui souhaite communiquer efficacement peut difficilement se passer des cibles seniors, par exemple.

Les règles d'accessibilité dépassent largement le cas des personnes handicapées. Elles concernent également le référencement et la navigation avec des terminaux mobiles.

Dans ce domaine, le RGAA (Référentiel général d'accessibilité pour les administrations) français, les standards SGQRI 008 au Québec, et les critères Accessiweb contiennent des règles permettant d'assurer une navigation sans difficulté pour tous les internautes et une restitution correcte des contenus dans tous les contextes.

La qualité web est un concept plus large qui se penche sur la satisfaction de l'ensemble des exigences des internautes. Le concepteur de site s'intéresse à l'accessibilité mais également au référencement, à l'ergonomie, à la performance, à la sécurité ou encore à la qualité des contenus. Dans ce domaine, le référentiel de bonnes pratiques Opquast (Open Quality Standards) est utilisable librement. [1]

A titre d'exemple, voici trois critères issus de ce référentiel :

Les sons et vidéos sont déclenchés par les utilisateurs.
Le site propose une page d'erreur personnalisée.
Le site est accessible avec ou sans « www » avant le nom de domaine.

2 Faites le choix des référentiels d'accessibilité et de qualité

Faut-il choisir un référentiel d'accessibilité, un référentiel de qualité ou les deux ?

Le choix d'un référentiel d'accessibilité permettra d'atteindre un haut niveau d'accessibilité mais attention, le respect exclusif d'un tel référentiel peut conduire à mettre de côté des points importants comme la performance ou la sécurité [2].
Le choix d'un référentiel de qualité permet quant à lui de traiter de tous les aspects de la qualité d'un site mais ne permet pas d'atteindre un très haut niveau d'accessibilité.

Si vous êtes un acteur public – commune, acteur territorial...–, la mise en application d'un référentiel national comme le RGAA (en France) ou SGQRI 008 (au Québec) étant obligatoire, vous avez tout intérêt à choisir ce référentiel en priorité avant de vous pencher sur les aspects qualité.

3 Contrôlez la conformité du cahier des charges

Une fois votre choix de référentiel effectué, il importe de passer en revue votre cahier des charges pour vérifier que celui-ci prend en compte les exigences fondamentales en matière de qualité ou d'accessibilité. Attention, une simple référence à un référentiel ne suffira pas. Il arrive très fréquemment que malgré un cahier des charges exigeant, par exemple, le respect d'un référentiel dans son ensemble, le site produit soit finalement très peu accessible. En effet, les référentiels de qualité et accessibilité contiennent 150 à 250 critères. De nombreux prestataires qui les connaissent mal sous-estiment la charge de travail et la compétence nécessaires pour les respecter. C'est pourquoi, au-delà de la mention d'un référentiel dans le cahier des charges, il sera intéressant de demander aux futurs prestataires de quelle manière ils comptent le mettre en application. Vous pouvez également leur demander d'expliciter les solutions envisagées pour des fonctionnalités précises.

4 Suivez pas à pas le processus de production

Par la suite, pour éviter les écarts entre les attentes et les résultats, il importe de suivre la production du site web. Un processus, à la méthode de mieux en mieux définie, guide cette production.

Le plus fréquemment, il consiste à :

Produire des maquettes ergonomiques des principales pages du site – accueil, page de contenu, formulaire de contact, accueil de rubrique, etc. Ces maquettes sont quelquefois appelées story-boards. Cette phase permet d'obtenir une idée de la navigation sur le site et de l'emplacement des zones de menu, des contenus, du moteur de recherche.
Elaborer des maquettes graphiques, à partir des maquettes ergonomiques, de manière à donner au site sa couleur et son allure et à définir les éléments graphiques du site.
Effectuer des découpes pour transformer les maquettes graphiques dans le langage HTML. C'est ce qu'on appelle la phase d'intégration.
Mettre en place les contenus dans le CMS (content management system ou système de gestion des contenus, comme par exemple Spip, Wordpress, EZPublish ou encore Joomla). Ces CMS donnent accès à des formulaires permettant de créer des rubriques, des pages et de mettre en place les contenus.

A chacune des phases décrites ci-dessus, il est essentiel de faire des revues rapides de ce que produit votre prestataire en évaluant le résultat de chaque étape en fonction du référentiel choisi. De manière générale, plus un défaut est détecté tardivement, plus le coût de sa réparation sera élevé. Il importe donc de détecter les défauts le plus tôt possible dans le processus de production. C'est pourquoi ce type d'évaluation est indispensable pour garantir le résultat final et pour minimiser les coûts de réalisation. Pour le moins, l'examen des maquettes graphiques, des intégrations et, bien évidemment, de l'ensemble du site une fois les contenus mis en place sont essentiels.

5 N'attendez pas la fin pour vous poser les bonnes questions

Dans tous les cas, sachez que rien n'est plus désagréable que de se rendre compte qu'on a laissé passer des gros défauts pendant la production d'un site. De votre côté, vous devez bien définir vos objectifs fonctionnels et de qualité, puis choisir un prestataire compétent. Pour vous aider à choisir, voici quelques questions à se poser :

Le prestataire, connaît-il les référentiels de qualité et accessibilité ?
A-t-il déjà développé des sites internet en les utilisant ?
Est-il en mesure de vous proposer un processus de production solide et séquencé ? Effectue-t-il des recettes et des contrôles lors de chaque phase de production ?

Si vous êtes capables de répondre par l'affirmative aux quatre questions posées, votre projet a de fortes chances d'atteindre un bon niveau de qualité et d'accessibilité. Dans le cas contraire, le succès est possible, mais nettement plus aléatoire. La connaissance des standards industriels du secteur est un gage de professionnalisme. C'est également pour vous une assurance contre les échecs et les refontes successives. Enfin, cela garantit que le coût de réalisation du site sera calculé au plus juste et ne sera pas consacré à la correction de défauts faciles à traiter en amont de la production.

Les référentiels de qualité et accessibilité peuvent vous aider à produire un site évolutif, correctement référencé, facile à utiliser dans tous les contextes de navigation et pour tous les utilisateurs. Certains prestataires vous proposeront des devis quelquefois un peu supérieurs à leurs concurrents mais l'investissement que vous ferez sur ce sujet en amont ne peut que vous bénéficier sur la durée.

[1] L'auteur de cet article est l'un des fondateurs de l'initiative Opquast, qui a conduit à produire ce référentiel de bonnes pratiques

[2] Attention, une formulation dans la version initiale de cet article pouvait laisser penser que le choix d'un référentiel d'accessibilité impliquait forcément de laisser de côté des sujets comme la performance ou la sécurité. Ce n'est bien entendu pas notre propos. Mais ce risque existe et il faut en être conscient.

Introduction à la performance Web

Nicolas Hoffmann — 2011-02-10T10:29:32Z

Travailler les performances d'un site web peut être un travail de très longue haleine et extrêmement technique, impliquant de multiples acteurs et de multiples compétences. L'idée de cet article est de comprendre pourquoi ce domaine est en plein essor et d'en poser les bases.

Définition et cadre de l'article

Les performances web sont un domaine qui peut être extrêmement large. Cela peut aller de la rapidité du ou des serveur(s) jusqu'à l'utilisation efficace d'une base de données et d'un langage de web dynamique comme PHP, tout en passant par des intégrations HTML/CSS de qualité, l'optimisation des images, etc.

Cet article ne compte pas (et ne peut pas !) aborder tous ces multiples domaines. Nous allons plutôt nous concentrer sur l'optimisation de la vitesse d'affichage d'un site dans un navigateur.

Les performances web, pourquoi ?

Améliorer l'expérience utilisateur

Les visiteurs de votre site apprécieront que vos pages s'affichent le plus rapidement possible. De récentes études montrent qu'une baisse de la rapidité d'affichage d'un site peut induire une baisse de fréquentation significative, et cela tombe sous le sens : le visiteur d'un site de e-commerce aura tendance à passer chez un concurrent plus efficace si le site en question met 10 secondes à s'afficher. Pour prendre un autre exemple, attendre 3 à 4 secondes à chaque recherche sur Google serait extrêmement pénible.

Envisager le web mobile

Si la rapidité est importante sur un ordinateur disposant par exemple d'une bonne connexion ADSL, elle est quasiment critique en situation de mobilité. Les connexions sont en général moins rapides, et paradoxalement, les utilisateurs sont moins patients et attendent autant de rapidité que sur un ordinateur de bureau classique.

Optimiser les coûts

Un site dont les performances sont optimisées sera généralement moins gourmand en ressources (bande passante, processeur, ...). Sa configuration d'hébergement pourra être adaptée sur mesure et le site supportera facilement une charge importante de visites.

Améliorer son référencement

Google a par exemple récemment annoncé que les performances web étaient un des critères pris en compte dans son algorithme de référencement.

Améliorer les performances en pratique

Avant de chercher des solutions plus complexes, travailler les performances d'un site consiste d'abord par prendre de bonnes habitudes et de bons réflexes dès la conception. Prendre ces bonnes habitudes est parfois plus intéressant et plus aisé que de corriger après coup.

Il faut déjà mettre les fichiers Javascript et CSS en fichiers externes. Pour vos CSS, placez-les dans le head et non directement dans la page : le navigateur téléchargera ainsi rapidement les informations pour mettre en forme le site et pourra commencer son travail de stylage des éléments. Pour prendre une analogie, un ouvrier qui a déjà tous ses outils à portée de main travaillera plus vite que celui qui les a éparpillés sur le chantier ou qui doit les trouver ou les découvrir au fur et à mesure de son travail.

Quant au Javascript, il est par contre conseillé de le mettre le plus possible en bas de page, juste avant , pour éviter qu'il ne bloque le rendu et le téléchargement des autres composants. Pour reprendre une analogie, il vaut mieux mettre une surcouche de peinture à la fin de la construction que pendant.

Créer des CSS et du HTML efficaces

Côté HTML

Privilégiez une structure légère, identifiez bien les éléments clés permettant l'application des styles et évitez autant que possible le code redondant ou inutile.

Bannissez les erreurs 404 de votre vocabulaire, pensez à vérifier les contenus de votre site avec un utilitaire comme Xenu Link Sleuth.

Côté CSS

Pensez à utiliser autant que possible des sélecteurs efficaces. Par exemple : #bandeau a au lieu de #bandeau ul#navigation li a
Évitez de terminer vos sélecteur par *, par un [xxx] ou par un pseudo sélecteur,
Évitez également les expressions CSS comme :
background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );
Ce sont des éléments non standards uniquement reconnus par Internet Explorer. Même s'ils peuvent être utiles pour émuler des comportements standards non pris en charge par Internet Explorer 6 et 7, ces expressions sont plus longues à rendre pour le navigateur et très fréquemment évaluées... leur utilisation est donc à bannir autant que possible.

Pensez à bien factoriser vos propriétés CSS en utilisant judicieusement vos sélecteurs. Exemple :

#bandeau a{ display:block; width:150px; height:65px; } /* en supposant que tous les liens de votre bandeau ont cette taille */ #bandeau #accueil{ width:200px; } /* inutile de répéter les propriétés pour #bandeau, on ajuste seulement celle nécessaire */

Partez autant que possible des propriétés générales pour aller aux plus spécifiques afin d'éviter des redondances ou des redéfinitions inutiles,
Utilisez les notations compactes, par exemple : background:#fff url(/images/images.jpg) 0 0 no-repeat; au lieu de toutes les propriétés séparées : background-color, background-image, background-position, etc.). Certes l'économie est relative, mais sur de très grosses CSS elle est toujours bonne à prendre.
Pour prendre un autre exemple : margin:15px 0 10px 5px; remplacera avantageusement
```
 margin-top:15px; margin-right:0; margin-bottom:10px; margin-left:5px; 
```

À cet effet, vous pouvez utiliser un outil comme CSS Compressor. Ce dernier peut vous indiquer quelles notations sont à raccourcir pour prendre de bonnes habitudes.

Côté images

Indiquer les dimensions des images permet au navigateur de "réserver" leurs places et de poursuivre l'affichage du reste de la page pendant leur chargement. Ainsi, le navigateur n'a pas à "découvrir" la taille des images après les avoir chargées.

Exemple : , une fois corrigé pour ne demandera pas inutilement au navigateur des reconstructions de la page pour prendre en compte la nouvelle taille une fois l'image chargée.

Et surtout ne redimensionnez pas ces images via le HTML : charger une miniature en 200 x 150 pixels sera bien plus rapide que de charger une image dont la résolution est supérieure (ex. : 800 x 600) pour la redimensionner via le navigateur (cette image sera beaucoup plus lourde).

En prime, l'affichage sera plus beau avec une image ayant une taille exacte, un navigateur n'est pas prévu pour ré-échantillonner une image.

Il va de soi que cette liste de conseils n'est pas exhaustive, néanmoins elle permet de poser une bonne base, voyons maintenant les optimisations proprement dites.

Réduire le nombre de fichiers à télécharger

Afficher une page implique pour votre navigateur des requêtes HTTP à envoyer au serveur. Le navigateur ne peut demander tous les fichiers en même temps (et particulièrement en situation de mobilité, où les connexions sont moins rapides). Ainsi envoyer moins de requêtes au serveur permettra à votre navigateur de télécharger plus rapidement les éléments nécessaires à l'affichage de la page, et donc de les afficher plus vite.

Dans cette optique, voici plusieurs points à prendre en compte :

Combiner autant que possible les fichiers Javascript : si vos scripts peuvent être tous groupés dans un unique fichier, autant le faire !

Côté CSS, il est également souhaitable de diminuer le nombre de fichiers. Il est possible de proposer plusieurs CSS par exemple en utilisant la règle @media pour spécifier dans le même fichier CSS votre version print et vos media queries pour Smartphone :

 /* ici vos propriétés générales */ body{ background:#fff; color:#333; } /* supposons que seule la couleur du texte doive varier, on modifie juste cette propriété, le reste sera hérité des propriétés ci-dessus */ @media screen and (max-device-width:640px){ body{ color:#111; } } @media print{ body{ color:#000; } }

Ainsi, vous n'utilisez qu'un seul fichier CSS pour votre site, sa version imprimable et sa version pour smartphone.

Les images utilisées dans vos CSS peuvent être combinées à l'aide de la technique dite des sprites CSS : les images sont combinées en une seule image et on utilise la propriété background ou background-position pour afficher la partie souhaitée de l'image. À cet effet, je vous invite à lire les sprites CSS. Cette technique présente l'avantage de fortement diminuer les requêtes HTTP et de se passer de Javascript pour d'éventuels préchargements. La maintenance et l'intégration peuvent être un peu plus difficiles en contrepartie.
Mettre en cache vos fichiers pouvant l'être (CSS, images, Javascript, icône de favori) est une bonne habitude à prendre, cela évite de devoir recharger des fichiers qui ne sont pas supposés changer à chaque consultation.

Exemple via un fichier .htaccess :

  Header set Cache-Control "max-age=31536000" # 1 an pour les extensions précitées header append Cache-Control "public" # public indique que la mise en cache est possible # pour tout le monde y compris pour les proxies # (sinon nous aurions mis private pour empêcher # les proxies de mettre en cache)

Dans notre exemple, les images sont mises en cache pour une durée d'un an. Autrement dit, pendant un an, cela évite au navigateur ayant déjà chargé ces images de les retélécharger : l'économie en vitesse de rechargement (pour le navigateur) et en bande-passante (pour le serveur) peut être considérable. Toutefois, si un changement devait être opéré sur une image, il est recommandé de changer le nom de l'image, afin d'éviter que la mise en cache n'empêche de voir ce changement.

Réduire le poids des fichiers téléchargés

Une fois que le nombre de fichiers a été réduit autant que faire se peut, il faut également s'atteler à en réduire le poids. Fort heureusement, de nombreux outils et techniques offrent des possibilités efficaces et intéressantes.

PNG (le cas échéant GIF) et JPG doivent être optimisés. La plupart des logiciels proposent une option "optimisé pour le web" pour les images. Néanmoins, les résultats peuvent être insuffisants. Vous pouvez dans ce cas essayer des outils comme Yahoo Smush it ou PNG Optimizer, très efficaces et très pratiques.

Minifier CSS, Javascripts et même HTML si cela est possible est une bonne habitude à prendre. Pour les CSS, des outils comme CSS Compressor peuvent apporter des gains substantiels. Côté Javascript, Google Closure Compiler permet de produire du code Javascript plus efficace : il enlève le code inutilisé et permet donc d'en réduire le poids.

Il est également possible d'activer la compression de certains fichiers : en pratique le serveur compresse les données (code XHTML, CSS, ...), les fichiers transitent par le réseau, le navigateur décompresse les données avant de les interpréter. Les deux types de compressions utilisées sur un serveur Apache standard sont GZIP et DEFLATE : elles sont supportées par tous les navigateurs modernes.

Pour donner quelques exemples, une CSS de 8 ko peut voir son poids réduit à 2 Ko via la compression DEFLATE, et une bibliothèque comme Jquery voit son poids passer de 77 ko à une vingtaine de ko.

En pratique, un fichier htaccess suffit pour les activer. Par exemple, pour activer la compression DEFLATE :

 AddOutputFilterByType DEFLATE text/html text/css application/javascript #etc...

Première mise en garde : ce type de compression est à utiliser uniquement pour des contenus de type textuels. Il serait totalement inutile d'utiliser cela pour recompresser des images, cela consommerait beaucoup de ressources serveur pour un résultat nul.

Seconde mise en garde : ne misez pas tout sur la compression. Prenez bien le temps de travailler, d'optimiser et de minifier vos CSS avant de les compresser via GZIP ou DEFLATE. La rapidité d'affichage n'en sera que meilleure.

Des outils pour apprendre... et aller plus loin

Deux extensions de Firebug permettent de travailler et d'apprendre à perfectionner les performances des sites Internet : Yahoo Yslow et Google Page Speed.

Yslow propose des notes sur chaque point (mise en cache, compression, etc.) allant de A à F avec un indice global sur 100, et Pagespeed propose une note globale sur 100 en fonction de plusieurs paramètres. Ces deux extensions se complètent bien et permettent d'évaluer rapidement le travail effectué (ou à effectuer) sur les performances d'une page.

Google propose une documentation complète en rapport avec les points mentionnés via Page Speed : Google Code Web Performance Best Practices Yahoo en fait de même et propose également Best Practices for Speeding Up Your Web Site.

On peut également signaler GT Metrix, qui se base sur ces deux extensions et qui permet de comparer les résultats entre plusieurs pages.

Web page test permet (entre autres possibilités) de voir le temps que votre page va mettre à s'afficher lors d'un premier chargement, et lors d'un deuxième chargement. Cela peut vous permettre par exemple de voir l'efficacité de la mise en cache de vos contenus.

D'autres outils plus poussés comme Yottaa permettent d'analyser de manière plus globale les performances de pages internet : visualiser la vitesse d'affichage de votre site depuis divers points du globe, vérifier la complexité vos pages, etc.

Conclusion

Travailler et prendre en compte les performances des sites internet est une évidence qualitative. L'essor de la navigation en situation de mobilité, l'implication de divers acteurs majeurs du web comme Google ou Yahoo, et plus globalement le besoin d'afficher rapidement des sites parfois complexes et riches - d'autant plus dans des secteurs à forte compétitivité - font que les performances des sites internet sont à prendre en compte par tout professionnel du web, qu'il soit décideur ou technicien.

Il va de soi que cet article n'est qu'une introduction au domaine des performances web. Néanmoins, les techniques et outils abordés vous offrent la possibilité d'avoir des résultats très satisfaisants. D'autres pistes sont envisageables et commencent à voir le jour. Elles feront l'objet de très probables futurs articles.

Références :

Ne perdez plus vos internautes, faites du card sorting / tri de cartes - Deuxième partie : Mise en oeuvre

Gautier Barrère — 2011-01-26T16:40:23Z

Dans le premier article, nous vous avons présenté le principe du card sorting. Découvrez désormais les différentes étapes de mise en oeuvre de cette technique, de la définition du protocole au bilan avec les utilisateurs, en passant par le choix des cartes à tester... C'est parti.

L'évaluation en ergonomie, que ce soit à travers un card sorting ou toute autre technique impliquant des utilisateurs, nécessite l'intervention d'un expert dans le domaine et la mise en place d'un protocole rigoureux. Il est également très important d'engager un évaluateur neutre : ne faites jamais réaliser l'évaluation par une personne impliquée dans la conception. On ne peut pas être juge et partie.

Etape 1 : mettez en place un protocole rigoureux

Le protocole va permettre :

de choisir la technique d'évaluation appropriée à votre contexte (est-ce que le card sorting est adapté pour ce que vous souhaitez faire)
de définir les hypothèses que vous souhaitez tester
d'identifier les métriques et le type d'analyse adaptés à vos besoins (analyse qualitative, analyse quantitative…)
de tester ce que vous souhaitez réellement tester, sans biais, sans guider l'utilisateur
d'obtenir des résultats fiables et utilisables pour la reconception

La définition du protocole est fondamentale car elle va conditionner le card sorting et la pertinence des résultats que vous obtiendrez : si le protocole n'est pas correctement mis en place, le temps que vous investirez dans les tests peut déjà être considéré comme perdu !

Etape 2 : choisissez les bons utilisateurs

Assurez-vous que les utilisateurs que vous sollicitez soient représentatifs de la population que vous ciblez. C'est l'analyse des profils utilisateurs qui va vous permettre de décrire en détails les caractéristiques ciblées et de définir des profils types (personas).

Les études scientifiques démontrent qu'il faut entre 20 et 30 utilisateurs par profil type identifié.

Vous pouvez recruter autour de vous, mais attention, il est important d'identifier d'abord la cible et ensuite de recruter. Faire appel aux personnes ne correspondant pas à la cible anéantirait vos résultats. Choisissez les utilisateurs parce qu'ils correspondent à votre cible et non par soucis de simplicité pour l'organisation de vos tests.

Etape 3 : choisissez des contenus de cartes pertinents

D'une manière générale, lors de tout test utilisateur, il est primordial de s'assurer que les scénarios de test proposés aux utilisateurs (les objectifs que vous leur proposez d'atteindre) soient représentatifs de leurs besoins (est-ce qu'ils correspondent vraiment aux attentes utilisateurs identifiées lors de la phase d'analyse).

Quand vous rédigez vos cartes, faites très attention :

à la clarté des contenus : un contenu mal rédigé vous empêchera de tester les hypothèses de départ. Vous aurez des difficultés à comprendre les raisons pour lesquelles il a été classé à l'endroit choisi par vos utilisateurs
à la granularité des contenus : vous pouvez rédiger une carte sous la forme d'un titre, d'un descriptif générique, d'un exemple réel de contenu, d'une image, etc. Vous pouvez combiner plusieurs approches (par exemple en mettant un titre et un exemple réel de contenu), mais quoi qu'il arrive conservez une approche de granularité identique à travers toutes vos cartes

Nombre de cartes

En moyenne, on préconise d'utiliser au maximum entre 50 et 60 cartes par card sorting.

Des contenus testables

Assurez-vous que les contenus à trier soient vraiment testables : par exemple cela n'a pas de sens de tester une loi, un organigramme ni même la façon dont une fonctionnalité doit interagir avec l'utilisateur.

Tester plusieurs niveaux dans l'arborescence

Généralement on s'arrange pour faire trier des contenus qui sont de même niveau dans l'arborescence (par exemple des contenus de niveau 2 dans des catégories de niveau 1).

Si vous souhaitez tester plus de deux niveaux, vous devez procéder par étapes. Admettons que vous testiez les trois premiers niveaux d'une arborescence, vous devez définir une première étape pour faire trier des cartes de niveau 3 dans des catégories de niveau 2, puis une seconde étape pour faire trier des cartes de niveau 2 dans des catégories de niveau 1.

Trop de cartes ?

Quand on souhaite aller plus en profondeur et tester les niveaux 3, 4 et 5, on est vite confronté à un nombre trop élevé de cartes. Il vous faudra donc faire des choix et définir des priorités. Faire des échantillons sur base d'une sélection aléatoire est une éventualité à considérer.

Une fois que vous disposez de tous les éléments pour commencer le card sorting, vous pouvez vous atteler à l'organisation de la séance, la préparation du matériel et le déroulement du test.

Etape 4 : organisez les séances de manière rigoureuse

Card sorting in situ

Nombre d'utilisateurs : on préconise généralement de faire intervenir entre 5 et 8 utilisateurs par séance (on fait donc plusieurs séances pour obtenir au moins 20 utilisateurs par profil type identifié). Attention, même si l'on sollicite plusieurs utilisateurs en même temps l'exercice est individuel
Durée de la séance : 1h30 avec 45 minutes de manipulation des cartes

Prévoyez deux évaluateurs par séance : un animateur qui se consacre aux participants, puis une personne qui s'occupe de la logistique, qui note et gère la réception des données.

Le grand avantage du card sorting in situ est qu'il permet une fois le test réalisé de revenir sur certaines hypothèses en direct avec les utilisateurs. Ces derniers peuvent ainsi expliquer leurs choix, indiquer les difficultés rencontrées, etc. Les informations recueillies sont précieuses car elles permettent d'identifier très rapidement les contenus incompris.

Card sorting à distance

Nombre d'utilisateurs : pas de limite
Durée de la séance : pas plus de 45 minutes (généralement cela dure entre 20 et 30 minutes)

Le principal avantage du card sorting à distance est que vous pouvez, sans grand souci logistique, faire appel plusieurs fois aux utilisateurs et organiser votre card sorting en plusieurs étapes.

Pensez également à annoncer le temps global nécessaire à la réalisation du test lors des consignes introductives. Cela vous évitera de perdre des utilisateurs en cours de route.

Etape 5 : préparez le matériel

Card sorting in situ

Cartes cartonnées (format 15*10cm), post-it, élastiques, stylos, une table assez spacieuse, etc. Prévoyez des cartes vierges pour les gens qui souhaitent ajouter des contenus ou placer une carte dans plusieurs rubriques.

N'hésitez pas à recycler votre matériel de bureau : les cartes peuvent par exemple être découpées dans des intercalaires.

Card sorting à distance

De nombreux outils sont à votre disposition tels que Optimalsort ou Websort sont à votre disposition.

Etape 6 : lancez le déroulement du card sorting

Phase 1 : accueil et consignes

Mettez les utilisateurs à l'aise et en condition
Expliquez l'objectif du test pour obtenir ce que vous souhaitez, mais sans trop en dire pour ne pas biaiser les résultats
Un seul mot d'ordre : Faites des regroupements qui font du sens pour vous !

Lors d'un card sorting in situ, étant donné que vous avez la possibilité de répondre plus facilement aux questions des utilisateurs, la formulation de la consigne est moins critique. Faites néanmoins très attention à plonger les utilisateurs dans les mêmes conditions en respectant le protocole établi. Pour un card sorting à distance, faites vraiment attention à la consigne et au déroulement du tri, vous n'aurez pas le droit à l'erreur.

Phase 2 : demandez aux utilisateurs de trier les cartes

C'est parti, chaque utilisateur peut trier les cartes qu'il a à sa disposition :

Faites trier individuellement
Demandez aux utilisateurs de regrouper les cartes sans forcément nommer les groupes
Laissez la possibilité aux utilisateurs de placer une carte à deux endroits (pour cela proposez des cartes vierges)
Laissez aux utilisateurs la possibilité de constituer le nombre de catégories qu'ils souhaitent. Vous pourrez aisément revenir par après en leur demandant de réduire le nombre de groupes
Laissez la possibilité aux utilisateurs de créer une catégorie “Autre” s'ils n'arrivent pas à trier une carte

Phase 3 : demandez aux utilisateurs de nommer les catégories

Cette phase vaut uniquement pour un card sorting ouvert, lors duquel on demande aux utilisateurs de classer les cartes dans des catégories qu'ils créent eux-mêmes.

Faites apposer les titres des catégories à l'aide d'un post-it
Rappelez que l'objectif est de faire des titres de rubriques. Si vous obtenez des noms trop longs, demandez aux utilisateurs de surligner les mots clés
Laissez la possibilité aux utilisateurs de renommer leurs groupes a posteriori

Phase 4 : faites le bilan avec les utilisateurs

Cette phase est normalement réalisée lors d'un card sorting in situ et plus difficilement applicable pour un card sorting à distance.

A la fin du card sorting expliquez la finalité du test aux utilisateurs :

orientez les discussions pour obtenir le maximum d'informations
minimisez le travail de saisie (souvenez-vous : une personne pour animer et une personne pour noter) et intégrez directement les résultats dans un logiciel dédié pour gagner du temps pour l'analyse

Conclusion

Vous avez désormais toutes les "cartes" en main pour mettre en place un card sorting. Dans le prochain article de la série, nous verrons comment analyser les résultats en vue de la reconception.

Crédit photo : Gautier Barrère Licence : Creative Commons Attribution-ShareAlike

Accessibilité du Web : les pièges les plus fréquents

Denis Boudreau — 2011-01-19T14:33:12Z

L'accessibilité ne constitue pas un simple maillon supplémentaire que l'on peut ajouter à la chaîne de production Web. Elle doit plutôt s'intégrer à chacun des maillons de cette chaîne. La seule façon de relever avec succès le défi de l'accessibilité est de répartir la responsabilité et de partager les tâches pour produire un contenu accessible.

Bousculer les habitudes

Les standards en matière d'accessibilité pour les personnes handicapées et les populations vieillissantes bouleversent de nombreuses habitudes au sein des organisations qui entreprennent de les instaurer dans leurs pratiques de développement Web. Les exigences de ces standards remettent en question des pratiques souvent jugées jusque-là adéquates, éprouvées et optimales. La volonté d'intégrer ces nouvelles préoccupations de qualité au sein d'une équipe de production entraîne des changements soudains qui sont susceptibles de déstabiliser la rentabilité d'une production de site Web.

Bien que les principes appliqués dans la pratique d'accessibilité ne soient pas difficiles à mettre en œuvre, grands sont les risques de tomber dans certains pièges. Cet article vise à identifier ceux dans lesquels les organisations sont les plus susceptibles de tomber. Cette liste n'est certes pas exhaustive, mais pour le bien de cet article, nous avons retenu uniquement ceux qui sont les plus fréquemment identifiés dans notre pratique.

Intimement liés les uns aux autres, ces pièges entraînent souvent une cascade de conséquences déplorables pour le potentiel d'accessibilité des projets Web. En voici la liste :

Considérer l'accessibilité comme une étape de fin de parcours et ignorer le caractère transversal de la pratique d'accessibilité
Attribuer la responsabilité de l'accessibilité aux seuls intégrateurs Web
Limiter la validation de l'accessibilité aux seules exigences décrites dans les standards
Confondre les notions de conformité au standard d'accessibilité et de mise en accessibilité
Présumer que les outils de validation feront tout le travail
Sous-estimer l'impact des plateformes technologiques

Pour chaque piège identifié, nous tenterons d'analyser la nature et la cause du problème. Nous présenterons ensuite divers conseils pour rapidement intégrer des mécanismes de prévention qui favoriseront leur évitement.

Quelques pièges fréquents

Considérer l'accessibilité comme une étape de fin de parcours et ignorer le caractère transversal de la pratique d'accessibilité

Le premier piège dans lequel tombent plusieurs gestionnaires et chargés de projet, lors de la planification des différentes étapes d'un projet Web, consiste à percevoir l'accessibilité comme un maillon supplémentaire qui s'ajoute en fin de parcours à la chaîne de production Web.

Dans cette perspective erronée, l'accessibilité apparaît comme une grille de validation supplémentaire à prévoir au moment de la phase de contrôle de la qualité du projet, tout juste avant la mise en ligne du résultat. La notion de grille de contrôle qui accompagne les standards d'accessibilité n'est certes pas étrangère à cette perception.

Dans le cas d'une mise en accessibilité en fin de parcours, les experts en accessibilité observent trop souvent que certaines décisions ont miné le potentiel d'accessibilité du projet. À titre d'exemple, mentionnons les situations suivantes :

des systèmes de navigation sur un site Web qui sont entièrement dépendants de la souris, et donc inutilisables pour quiconque navigue avec le clavier ;
des choix de technologies naturellement incompatibles avec les technologies d'adaptation informatiques ou exploitées de manière incompatibles avec celles-ci ;
des contenus mis en ligne dans des formats téléchargeables plutôt qu'en format HTML et qui s'avèrent impossibles à interpréter par les lecteurs d'écran ;
des textes de remplacement aux contenus non textuels qui n'ont pas été prévus par les développeurs alors que le rédacteur, ou même l'organisation, était disposé à les prévoir et y consacrer les efforts nécessaires ;
des maquettes graphiques aux contrastes de couleurs insuffisants, alors que cette signature visuelle est déjà placardée partout dans la ville et sur le Web.

En conséquence, l'organisation se retrouve souvent devant le constat qu'il est trop tard pour bien faire les choses. Soit parce que les budgets ou les échéanciers ne permettent plus de faire marche arrière, soit parce que les choix technologiques limitent la capacité d'une équipe à produire des contenus accessibles. Or, le simple fait de se poser les bonnes questions au bon moment permet d'éviter les échecs dans la très grande majorité des cas.

Contrairement aux dimensions « traditionnelles » du Web, telles que le design, l'analyse, l'ergonomie, l'utilisabilité, la rédaction, l'intégration et même la programmation, l'accessibilité ne s'inscrit pas comme une étape distincte et supplémentaire. Elle se répartit dans chacun des maillons d'une chaîne de production Web de manière à prévoir chaque intervention au moment opportun. Il s'agit d'une intégration transversale.

Certains choix faits en début et en milieu de parcours facilitent la mise en place de l'accessibilité ou, au contraire, génèrent des barrières. L'intégration transversale de l'accessibilité permet d'éviter des oublis importants, en particulier lors de choix techniques ou stratégiques. Ces oublis peuvent occasionner des délais et de coûteux efforts supplémentaires pour corriger la situation, lorsque des correctifs sont possibles. Comme on le sait, il est toujours plus avantageux de prévenir que de guérir.

Tout gestionnaire ou chargé de projet doit reconnaître cette particularité de la transversalité de l'accessibilité. Il comprendra alors la nécessité de déterminer à quels maillons de la chaîne de production Web doivent être assignées les différentes responsabilités et tâches associées aux exigences décrites dans les standards.

Attribuer la responsabilité de l'accessibilité aux seuls intégrateurs Web

Actuellement, la responsabilité d'appliquer les exigences d'accessibilité revient encore trop souvent au seul intégrateur Web. Il est illusoire de croire qu'elle peut reposer sur les seules épaules d'un champion de l'accessibilité au sein d'une organisation.

S'il est vrai que la très grande majorité des exigences d'accessibilité nécessitent une intervention des intégrateurs Web, plusieurs décisions et orientations doivent être prises dans les premières étapes du projet afin d'assurer un travail efficace. Pour qu'une démarche d'accessibilité s'avère une réussite, il importe que chaque intervenant d'une équipe comprenne les éléments d'accessibilité qui relèvent de sa responsabilité. On évitera ainsi de retourner :

aux rédacteurs pour demander les équivalents textuels des images ;
aux designers pour qu'ils revoient leur charte graphique afin d'adopter des couleurs aux contrastes suffisants ;
aux programmeurs pour assurer une association explicite entre les libellés et leurs champs correspondants dans un formulaire ;
ou encore au chargé de projet pour remettre en question des choix technologiques qui limitent ou empêchent le respect de certaines exigences.

Que l'on songe aux analystes, aux ergonomes, aux designers, aux rédacteurs ou aux architectes d'information, chacun est appelé à prendre des décisions ou à faire des actions qui peuvent influer sur le potentiel d'accessibilité du projet. Pour éviter que ces interventions aient des conséquences négatives quant au résultat final, il importe que l'accessibilité devienne une responsabilité partagée.

Limiter la validation de l'accessibilité aux seules exigences décrites dans les standards

La mise en accessibilité d'un site Web est très souvent perçue comme une vérification à effectuer à partir d'une petite liste d'exigences, comme s'il suffisait de vérifier le respect de chaque exigence pour produire un site Web accessible. Dans les faits, ce n'est pas si simple.

L'application de toutes les exigences décrites dans les standards permet d'atteindre une conformité à un standard. Toutefois, l'application systématique de ces seules exigences n'est pas un gage suffisant d'accessibilité : il faut aussi prévoir des tests fonctionnels avec des technologies d'adaptation informatiques qui permettent de valider que l'expérience utilisateur est positive. En effet, il est tout à fait possible de produire un site Web satisfaisant à toutes les exigences d'accessibilité, mais qui est tout de même non accessible sur certains aspects. Quelques petites subtilités manquées suffisent à engendrer un degré de confusion important pour l'utilisateur n'étant pas en mesure de percevoir visuellement l'interface.

Par tests fonctionnels on entend le recours à des technologies d'adaptation informatiques, telles que synthèses vocales, lecteurs d'écran et progiciels de grossissement, pour vérifier que le résultat interprété par ces outils correspond bien au résultat observé lors d'une validation visuelle des pages Web. À titre d'exemple, une absence de ponctuation dans les textes de remplacement des images ou encore une ponctuation visuelle basée seulement sur la disposition ou l'ordre de lecture de contenus présentés en tableau HTML, peuvent produire un résultat très différent de ce que l'on avait imaginé. De même, c'est souvent en relisant une page Web avec un lecteur d'écran que l'on constate que certains renseignements transmis visuellement seront manquants en synthèse vocale ou en Braille. La lecture en synthèse vocale peut aussi révéler des confusions dues à la prononciation ou à l'enchaînement de certains contenus (exemple : « standards et normes » et « standards énormes »).

En ajoutant les tests fonctionnels aux tests techniques, les producteurs de contenus Web s'assurent de ne rien laisser échapper lors des contrôles de qualité liés à l'accessibilité.

Confondre les notions de conformité aux standards d'accessibilité et de mise en accessibilité

Pour la plupart des chargés de projet et des développeurs Web, les notions de conformité aux standards d'accessibilité et de mise en accessibilité des contenus Web sont interchangeables. Or, ces deux notions ont des significations très différentes, et l'une ne saurait constituer un gage d'assurance pour l'autre.

La notion de conformité aux standards d'accessibilité repose sur le respect efficace, satisfaisant et systématique de toutes les exigences énumérées dans un standard. Dans le domaine de la normalisation, la conformité à un standard signifie que l'application satisfait à toutes les exigences de celui-ci. Le résultat est dichotomique : l'application est conforme ou elle ne l'est pas. En normalisation, un énoncé tel que : Ce site Web est conforme à 60 % au standard n'a pas de sens. Cette notion est donc objective parce qu'elle se limite à l'application des exigences prescrites et mesurables.

La notion de mise en accessibilité repose quant à elle sur un effort visant à faire tomber un maximum de barrières à l'utilisation des contenus Web pour les personnes ayant des limitations fonctionnelles. Notion subjective, elle suppose la mise en place de plusieurs mesures d'adaptation des contenus pour répondre aux besoins particuliers des utilisateurs. Contrairement à la notion de conformité au standard d'accessibilité, elle suppose des tests fonctionnels pour assurer qu'au-delà du respect des exigences des standards, les efforts déployés ont de réels effets bénéfiques sur l'expérience utilisateur des personnes handicapées qui consultent ces contenus.

Les résultats de la mise en accessibilité ne se mesurent cependant pas objectivement, car il est impossible de juger à partir de quel moment un site Web est « suffisamment accessible ». Ainsi, il revient au développeur Web, en fonction des intentions de l'organisation ou des budgets disponibles, de déterminer le seuil à partir duquel le résultat sera considéré comme satisfaisant.

Il est donc possible de produire un site Web conforme aux standards qui ne réponde pourtant pas tout à fait aux besoins des utilisateurs parce que certains détails auraient échappé aux développeurs. Dans le même esprit, un site Web jugé « suffisamment accessible » aux yeux des mêmes développeurs pourrait ne pas répondre en totalité aux besoins d'une clientèle particulière qui aurait été laissée de côté lors de la démarche. D'où l'importance de combiner les deux notions pour atteindre le résultat le plus large possible.

Présumer que les outils de validation feront tout le travail

L'accessibilité ne peut se mesurer seulement par la présence ou l'absence de certains éléments clés qu'un outil d'évaluation pourrait automatiquement déceler. Tout comme l'ergonomie, l'accessibilité fait appel au bon jugement des développeurs et donc aussi à une évaluation humaine compétente.

Dans un monde idéal, la notion de contrôle de la qualité relèverait de machines. Il serait ainsi inutile de se pencher sur les besoins d'adaptation des personnes handicapées sur le Web, car les outils seraient en mesure de prendre en charge toute cette préoccupation. Selon les législations en place dans les pays respectifs d'où ils proviennent, les outils sont souvent accompagnés d'affirmations promotionnelles qui ont pour effet de gonfler leurs capacités quant au potentiel d'accessibilité. Plusieurs gestionnaires et chargés de projet ont tendance à croire que ces outils peuvent faire tout le travail à leur place, mais dans les faits il n'en est rien. Quiconque remet la responsabilité de l'objectif d'accessibilité entre les mains des outils, ou des plateformes, qu'il utilise est voué à connaître de grandes déceptions le jour où il entreprendra des tests d'évaluation pour mesurer le niveau d'accessibilité réel du projet.

De l'ensemble des exigences d'accessibilité contenues dans les standards, la vérification d'une minorité seulement peut être automatisable au point où l'intervention humaine deviendrait inutile. On estime généralement autour de 30 % le nombre d'exigences pour lesquelles la vérification peut être complètement automatisée. À titre d'exemple, s'il est aisé de vérifier par programmation la présence d'un attribut alt pour le texte de remplacement d'une image, il est impossible de vérifier automatiquement si la valeur de l'équivalent textuel saisi reprend tout le texte apparaissant dans l'image.

Sous-estimer l'impact des plateformes technologiques

En plus des interventions requises pour chaque exigence à répartir dans la chaîne de production Web, il est crucial que certains stratèges dans l'équipe de production Web (en général les responsables des décisions techniques tels les gestionnaires, les chargés de projets ou les analystes), s'interrogent sur le potentiel des outils et des choix technologiques envisagés. En effet, la meilleure des équipes Web, avec les processus les plus rigoureux pour l'accessibilité, ne pourra pas atteindre ses objectifs de conformité si les outils retenus lui rendent la tâche impossible.

En outre, plusieurs gestionnaires et chargés de projet présument à tort que puisqu'ils font appel à des plateformes technologiques de haut niveau acquises à fort prix, les enjeux d'accessibilité seront forcément pris en charge de manière automatique et satisfaisante.

Dans la pratique d'accessibilité, nombre d'organisations sont aux prises avec des plateformes technologiques de tout ordre où les exigences les plus élémentaires d'accessibilité se heurtent aux limites techniques des outils en place. Par exemple, des changements en apparence très simples qui requièrent une correction facile au code HTML ou XHTML s'avèrent impossibles à effectuer en pratique parce que les développeurs Web n'ont pas accès au code source de leurs outils. Dans un tel contexte, il n'est pas possible d'espérer atteindre des objectifs de conformité aux standards.

S'il est vrai que les plateformes technologiques en logiciels libres présentent généralement un meilleur potentiel d'accessibilité en raison de la possibilité de modifier le code généré à même les outils, il ne faudrait pas conclure pour autant que les outils propriétaires ne peuvent assurer le respect des exigences d'accessibilité. Certains outils sont donc plus souples que d'autres. L'important est d'être conscient de cette réalité et de se poser les « bonnes questions » lorsque vient le temps de choisir une plateforme plutôt qu'une autre.

Voici quelques exemples de questions à se poser :

Afin de répondre aux préoccupations d'accessibilité de l'organisation, l'outil envisagé permettra-t-il de modifier le code HTML généré ?
L'outil envisagé sera-t-il suffisamment souple pour s'adapter aux pratiques de développement interne de l'organisation ?
L'outil envisagé permet-il déjà de répondre à certaines exigences élémentaires d'accessibilité du Web ?
Le fournisseur de cet outil a-t-il clairement ciblé l'accessibilité comme un élément majeur du développement de sa solution logicielle ?
L'organisation évaluera-t-elle de façon détaillée le potentiel de l'outil quant à l'accessibilité avant de s'engager avec le fournisseur qui le propose ?

Cet article a d'abord été rédigé par Denis Boudreau (AccessibilitéWeb) dans le cadre d'un mandat avec le ministère des Services gouvernementaux du Québec (MSG), en lien avec la démarche de normalisation menant à la rédaction des projets de standards sur l'accessibilité pour les personnes handicapées (SGQRI 008). Il est également disponible en version intégrale sous le titre « Guide sur les pièges communs de l'accessibilité Document (PDF, 260ko) », sur le site du MSG.

Ne perdez plus vos internautes, faites du card sorting - Première partie : Vue d'ensemble

Gautier Barrère — 2010-12-19T19:19:20Z

Trop souvent dans un projet web, on se rend compte au moment de la rédaction qu'il y a beaucoup de contenus, que l'on se répète, que l'organisation n'est pas fluide. Que faire pour organiser et nommer les informations afin que l'utilisateur trouve rapidement ce qu'il recherche ? Une possibilité est d'utiliser la technique du card sorting. Sans plus tarder, découvrez le premier article de la série. Deux autres suivront pour clôturer le dossier.

Le card sorting est issu des techniques de sciences humaines et sociales. Il était initialement utilisé par les chercheurs pour étudier la façon dont sont structurées les connaissances chez l'être humain. Dans le contexte d'un site web, l'objectif du card sorting est de comprendre la logique de structuration et de nommage des utilisateurs pour mettre en place des arborescences efficaces.

Le principe du card sorting

La procédure de base est simple :

vous recopiez les contenus et services que vous souhaitez proposer dans votre site sur des cartes ;
vous demandez aux utilisateurs de classer les cartes selon leur logique ;
vous demandez aux utilisateurs de nommer les tas de cartes qu'ils ont faits (uniquement lors d'un card sorting ouvert).

Card sorting versus Analyse des besoins ?

Point important avant de commencer. Même si pendant le card sorting vos utilisateurs peuvent vous donner des indices sur l'importance d'un contenu ou pointer du doigt des contenus manquants, le card sorting n'est pas là pour identifier les contenus répondant aux besoins des utilisateurs. Il est uniquement là pour vous aider à les organiser de manière logique pour ces derniers.

Quand appliquer le card sorting ?

Deux possibilités :

en mode « conception » : vous arrivez en fin de phase d'analyse, vous avez notamment identifié les contenus et services qui répondent aux besoins de vos utilisateurs, vous avez besoin d'organiser tout cela de manière logique et parlante pour eux ;
en mode « évaluation » : vous disposez d'un site web et souhaitez avoir un retour utilisateur sur la logique de structuration et de nommage de l'existant.

Card sorting ouvert ou fermé ?

Il existe deux types de card sorting :

ouvert : les catégories dans lesquelles vous demandez à vos utilisateurs de classer les cartes ne sont pas définies à priori. Ce sont les utilisateurs qui les définissent ;
fermé : les catégories dans lesquelles vous demandez à vos utilisateurs de classer les cartes sont déjà définies (c'est le cas quand vous avez déjà des idées précises pour l'arborescence).

Le choix d'un type ou d'un autre dépendra du contexte de votre projet et de vos objectifs.

Le card sorting ouvert est très intéressant car vous donnez les pleins pouvoirs aux utilisateurs. Sachez malgré tout que cela n'est pas toujours très constructif : vous risquez d'avoir une multitude de titres de catégories proposées sans pouvoir prendre de décision.

Ainsi, si vous disposez déjà d'une structure de site, il est plus simple de faire un card sorting fermé, de cibler les lacunes et de les améliorer.

Card sorting in situ ou à distance ?

Le grand avantage du card sorting est qu'il peut être réalisé in situ (sur place) ou à distance. Cela implique bien évidemment une préparation différente avec des avantages et des inconvénients. Pour de meilleurs résultats vous pouvez combiner les deux approches.

Conclusion

Vous avez désormais une bonne vue théorique de la technique du card sorting. Dans le prochain article de la série, nous découvrirons comment la mettre en pratique.

Crédit photo : Gautier Barrère Licence : Creative Commons Attribution-ShareAlike