Les humains auraient une tendance naturelle à être fainéants et émotionnels, c’est à dire à choisir la facilité avant tout. Le but de l’usabilité web est de répondre à cette contrainte non négligeable lors de la conception de sites ou applications web((« Usability is about human behavior. It recognizes that humans are lazy, get emotional, are not interested in putting a lot of effort into, say, getting a credit card and generally prefer things that are easy to do vs. those that are hard to do. » David McQuillen dans Taking Usability Offline, Darwin Magazine, en juin 2003)).
Si nous avons tous en effet une préférence pour la facilité, il y en a parmi nous qui ne sont malheureusement pas aidés par leurs aptitudes ou le contexte dans lequel ils se trouvent. Pour ceux-là, c’est beaucoup plus que la facilité qu’ils recherchent, c’est déjà la possibilité d’utilisation du web. C’est en pensant à eux, mais pas uniquement, que l’on parle en général d’accessibilité.
Mais si connaître son public, ses attentes et ses capacités est nécessaire, cela n’est pas suffisant, encore faut-il savoir comment prendre tout cela en compte dans la mise en oeuvre de sites ou applications web.
Une pointe d’usabilité …
Si l’utilité est une notion sans absolu relative à l’intérêt de chaque individu, il est courant de s’entendre sur la facilité ou non d’utilisation de choses jugées unanimement utiles.
L’usabilité((Le terme « usabilité » est un néologisme issu de la francisation du terme anglais « usability », venant du verbe « to use » qui signifie « utiliser »)) d’une chose est justement sa capacité à être utilisée de manière simple, efficace et agréable.
Dans le cas particulier du web, l’usabilité s’attache à rendre la navigation au sein d’un site((Les principes généraux d’usabilité du web peuvent être légèrement amendés dans le cas d’une application développée en technologies web)) la plus intuitive possible.
Il s’agit notamment de permettre à l’internaute d’identifier très clairement dès son arrivée sur le site quelles sont les possibilités qui s’offrent à lui, qu’il s’agisse d’un site éditorial ou d’une application en mode web, et qu’il soit arrivé par la page d’accueil ou directement par une page « interne ». Il est en effet important d’avoir une page d’accueil la plus pertinente possible((Voir les études de Loïc Renaud sur http://www.pagedaccueil.com/.)) puisqu’elle est le point d’entrée principal, mais il ne faut pas pour autant négliger les autres pages, sur lesquelles l’internaute peut arriver directement via un lien « profond » depuis un autre site ou un moteur de recherche.
Il s’agit aussi de permettre à l’internaute de toujours savoir ce qu’il fait, de quelle manière, et quelles peuvent être les conséquences de toutes les possibilités que l’on lui offre.
Des pratiques, pourtant courantes, qui nuisent à l’usabilité d’un site web sont, par exemple,
- l’ouverture intempestive de nouvelles fenêtres lorsque l’on clique sur un lien hypertexte,
- le masquage dans la barre de statut du navigateur de l’URL pointée par un lien hypertexte,
- le soulignement de textes hors de liens hypertextes, alors que cela est identifié instinctivement comme une mise en évidence des liens depuis la création du web,
- l’utilisation d’un même titre pour toutes les pages du site, ce qui gêne l’utilisation de favoris ou l’identification dans la barre des tâches((Et rend le référencement dans les moteurs de recherche beaucoup moins pertinent, par la même occasion)),
- les frames((Lire à ce sujet l’article Pour en finir avec les cadres d’Openweb)),
- la multiplication des typographies, couleurs et autres mises en formes visuelles plus perturbantes que pertinentes,
- etc.
Une bonne dose d’accessibilité …
Mais avant d’être au point en terme d’usabilité, tout site doit avant tout être accessible, car à quoi bon peaufiner des fonctionnements élaborés si ce n’est que pour un public restreint ?
Et cette restriction faite encore à l’heure actuelle par de trop nombreux sites n’est pas préjudiciable qu’aux personnes avec un handicap, elle l’est pour toute personne utilisant des moyens alternatifs d’accéder au web, qu’il s’agisse de terminaux mobiles de petite taille, d’écrans webTV, de connexions bas débit, etc. Les concepteurs de sites oublient un peu trop vite que tout le monde n’est pas en pleine possession de ses moyens physiques, derrière un écran de 17 pouces minimum, avec une connexion ADSL à 1024kbps minimum et avec tous les plugins imaginables((Flash, SVG, Java, Quicktime, etc.)) installés !
Tim Berners-Lee, inventeur du World Wide Web et directeur du W3C, indique justement que l’accessibilité a pour objectif de « mettre le Web et ses services à la disposition de tous les individus, quel que soit leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales ».
Que cette volonté soit bien fondée, personne ne s’avance trop à le contester, mais la volonté manque pour l’adopter.
Le 7 août 1998, le Congrès des Etats-Unis votait un amendement à la section 508 du Rehabilitation Act afin d’obliger les instances publiques à respecter des principes de base d’accessibilité dans la mise en oeuvre des technologies de l’information.
Fin 2000, le comité d’organisation des Jeux Olympiques de Sydney dût payer vingt mille dollars de dommages et intérêts à une personne aveugle pour n’avoir pas mis à sa disposition un site web accessible.
Une analyse de ce cas par l’un des experts consultés montre bien quels sont les mythes sur lesquels s’appuient les réticences à la mise en oeuvre d’une politique d’accessibilité :
- Pourquoi prendre en compte les aveugles lors de la réalisation de sites web, alors que d’une part ils sont si peu nombreux, et d’autre part le web est avant tout visuel ? Sans doute parce que l’accessibilité n’est pas destinée qu’aux handicapés.
- Pourquoi dépenser plus d’argent pour intégrer la problématique d’accessibilité dans la création d’un site web ? Sans doute parce qu’il y a beaucoup à y gagner sur le long terme, comme nous le verrons dans la suite de cette chronique.
Revenons aux préoccupations plus locales…
La France s’est préoccupée dès 2000 de l’accessibilité de ses sites web publics((Voir sur le site du Ministère de la Culture : « L’accessibilité des principaux sites internet des administrations publiques sera évaluée. Des solutions techniques et organisationnelles seront proposées à l’échéance de juin 2000 pour lever les obstacles et généraliser l’effort déjà engagé sur le site télématique du Premier Ministre. Enfin des recommandations seront formulées pour favoriser d’une manière plus générale l’accès des déficients visuels à l’ensemble des supports numérisés. »)), et le Parlement européen votait en juin 2002 une résolution sur la communication de la Commission « eEurope 2002 : Accessibilité des sites Web publics et de leur contenu ».
Mais dans son rapport du 20 janvier 2004 sur « L’accès des personnes handicapées aux Nouvelles Technologies : difficultés, besoins et solutions »((http://www.internet.gouv.fr/article.php3?id_article=1413)), Julien Perben indique notamment que « les recommandations internationales en la matière, éditées par le Web Accessibility Initiative (WAI)((http://www.w3.org/WAI/)), ne sont que trop peu prises en compte en France, à la fois par les entreprises privées et par l’administration, dont les sites qui devraient montrer l’exemple ne sont encore pas tous accessibles ». Jean-François Mattei, alors ministre de la santé, de la famille et des personnes handicapées, dépose donc le 28 janvier 2004 au Sénat un projet de loi dont l’article 25 indique qu’il est « indispensable que les sites et services électroniques des services publics de l’Etat et des collectivités territoriales et de leurs établissements publics soient accessibles ».
La démarche la plus officielle à l’heure actuelle en France pour pousser l’accessibilité est le label AccessiWeb((http://www.accessiweb.org/)) de l’association BrailleNet, qui est citée à plusieurs reprises dans le rapport de Julien Perben et qui a été intégrée début 2004 par l’ADAE((Agence pour le Développement de l’Administration Electronique :http://www.adae.gouv.fr/)) dans son Cadre Commun d’Interopérabilité des systèmes d’information publics((Cadre Commun d’Interopérabilité version 2.1)).
Elle commence donc enfin a être prise au sérieux, même si elle est encore beaucoup trop méconnue((Voir le compte-rendu par Stéphane Deschamps, membre de Pompage, du séminaire AccessiWeb du 3 mai 2004)), il ne reste plus qu’à plonger dans l’accessibilité…
Et les affres de la réalité
… mais c’est là que les ennuis commencent vraiment.
Le W3C a bien lancé sa Web Accessibility Initiative dès mai 1997 avec une première publication de Web Accessibility Guidelines en mai 1999((La seconde version des Web Accessibility Guidelines devrait bientôt être finalisée)), mais il y a un écart considérable entre ce qui est recommandé, et ce qui est applicable dans les faits.
La réalité actuelle du web vis-à-vis de la problématique d’accessibilité est que si des normes ont été définies pour y répondre, elles ne sont pas toujours évidentes à mettre en oeuvre, et ce bien souvent à cause des limites des navigateurs utilisés. Les normes en question, ce sont les dernières évolutions des langages utilisés pour créer des pages web, à savoir XHTML et les feuilles de styles CSS.
Ces normes évoluent régulièrement, mais elles ne sont malheureusement que peu respectées dans le navigateur le plus répandu, Microsoft Internet Explorer. Bien entendu, les navigateurs alternatifs tels que Mozilla ou Opera existent, et suivent de près les standards, mais leur adoption est encore loin d’être universelle.
La réalité quotidienne du créateur web est donc de jongler entre les différentes limitations auxquelles il doit faire face pour assurer à sa création l’usabilité et l’accessibilité qui sont nécessaires pour assurer son succès.
Un des points sur lesquels la majeure partie des créateurs web qui passent au standards ont le plus de mal, et c’est bien naturel, c’est l’abandon pour la mise en page des tableaux HTML au profit de positionnement de blocs par feuilles de styles. Cette modification technique est la conséquence logique d’un profond changement du principe de création web, où les contenus XHTML priment et doivent être cohérents sémantiquement, avant même d’être mis en forme par les CSS et éventuellement en action avec des scripts. Un navigateur particulier ne prenant pas en compte les feuilles de styles, par exemple un navigateur avec synthèse vocale, aura ainsi un contenu tout autant valide qu’un autre.
Pour répondre aux limitations des standards, le moyen le plus employé est celui des techniques de contournements, ou hacks, qui profitent de bugs et erreurs d’interprétation des standards faites par certains navigateurs.
Le problème est que beaucoup de créateurs web utilisent de plus en plus de hacks, ce qui ne favorise pas l’abandon des navigateurs obsolètes.
Il existe de trop nombreux hacks pour tous les référencer, mais voici l’exemple sans doute le plus populaire, le Box Model Hack conçu par Tantek Çelik((Notamment responsable du développement de Internet Explorer pour Mac OS !)) pour contourner le bug de Microsoft Internet Explorer jusqu’à sa version 5.5 (notons juste IE5.5) pour Windows concernant l’interprétation du modèle de boîtes CSS. Pour faire simple, disons que le navigateur ne prend pas en compte les bonnes valeurs pour calculer la largeur d’une boîte, ce qui conduit à un rendu différent de celui obtenu dans les autres navigateurs. Tantek a alors eu la (pas si) géniale idée de profiter d’un bug d’interprétation des CSS de ce même navigateur pour lui indiquer une autre valeur.
Dans un navigateur respectant le standard, le code suivant suffit pour donner une boîte de 400 pixels de large avec une bordure de 20 pixels, une marge intérieure de 30 pixels et un contenu de 300 pixels (20 + 30 + 300 + 30 + 20 = 400) :
div {
border: 20px solid;
padding: 30px;
width: 300px;
}
IE 5.5 considère que la taille indiquée est celle de la boîte et non celle de son contenu, ce qui fait que pour obtenir la même boîte, il faut lui donner width: 400px;.
Tantek a donc proposé le code suivant :
div {
border: 20px solid;
padding: 30px;
width: 400px;
voice-family: ""}"";
voice-family: inherit;
width: 300px;
}
IE 5.5 « voit » une taille de 400 pixels, et pense que le « } » ferme la déclaration, alors que les autres navigateurs continuent et remplacent la taille par la valeur 300px.
Ce hack semble magique au premier abord, et connaît de nombreuses variantes, mais comme tout contournement, il faut aussi se poser la question de la compatibilité future. Qui peut certifier que ce code non standard n’introduira pas un bug dans une version future d’un navigateur plus moderne ?
Utiliser des hacks pour répondre à des problèmes très précis peut s’avérer très tentant à court terme, mais il faut les éviter au maximum pour s’éviter des problèmes à long terme.
Les standards pour sauver tout le monde ?
Les standards existent et présentent de nombreux avantages, les concepteurs de sites web qui les connaissent commencent à être nombreux, mais le grand public n’est semble t’il pas encore près, et il faut toujours tenir compte du public lorsqu’il s’agit de mettre en ligne un site web.
Si les avocats de ces standards sont de plus en plus nombreux, c’est que ceux qui s’y frottent suffisamment longtemps arrivent en général à réaliser à peu près ce qu’ils avaient prévu, et ils comprennent alors pleinement l’intérêt des standards. Mais ils oublient bien vite leurs nombreux tâtonnements pour arriver au résultat escompté, et ont tendance à les oublier quand ils présentent ce qu’il est possible de faire.
Heureusement, la tendance s’améliore, et les évangélistes avouent maintenant eux-mêmes que finalement, même s’ils sont le chemin à suivre, les standards ne sont pas la panacée et qu’il est abusif de dire qu’user de standards est forcément rentable((Voir aussi, en anglais, l’article An Objective Look at Table Based vs. CSS Based Design ou Andy Budd se fait l’avocat du diable pour montrer la réalité des standards.)).
Faut-il donc se lancer ?
Nous l’avons vu, l’usage de standards favorise la mise en oeuvre de sites web en prenant en compte les problématiques d’usabilité et accessibilité.
La courbe d’apprentissage des standards, même pour un développeur web aguerri (( Adepte en général de la mise en page par tableaux)), étant d’au moins 6 mois, il est plus que nécessaire de ne plus attendre pour les adopter, et ainsi apprendre progressivement à apprivoiser les technologies qui, cela ne fait plus aucun doute, sont les seules viables à terme.
Même si Microsoft a annoncé ne pas prévoir de nouvelle version de son navigateur, et semble considérer qu’il est en position de force, les standards ne peuvent que s’imposer à terme, et ceux qui les auront adoptés progressivement dès maintenant seront sans doute en meilleure posture le jour où IE 5.5 ne sera plus qu’un mauvais souvenir.
C’est aussi l’expérience seule qui peut permettre de choisir sereinement d’adopter ou non les hacks les plus courants, selon les capacités à les maintenir dans le temps.
Pour ce qui est de l’accessibilité, même si les recommandations sont nombreuses, les adopter n’est pas qu’une affaire d’application des standards et de recopie d’extraits de code, il faudrait avant tout approfondir le sujet à sa source, en prenant connaissance des obstacles qu’il faut éviter de mettre en place pour assurer un accès universel aux sites web. Tout bon développeur peut appliquer des recettes, mais il sera bien plus efficace s’il en connaît le but.
