Grille d’analyse ergonomique d’un site web
....
1.1 Ergonomie
Afin de saisir l’importance de l’ergonomie par l’absurde, nous présentons quelques exemples de mauvaise conception d’interface. En voici deux, repris du site « User Interface Hall of Shame » [Mar05].
Dans le logiciel WinRental, nous pouvons voir un mécanisme de sélection de date qui est composé de 3 zones de contrôle, pour le jour, le mois et l’année. Comme vous le voyez dans la prise d’écran suivante, il est même possible de créer sa propre date.
De plus, lorsqu’il y a une valeur “Null” dans la base de données, le champ de l’année indique zéro.
Ce choix n’est vraiment pas ergonomique, d’autant plus qu’il existe un élément d’écran prévu à cette effet : “Date Time Picker”. Son utilisation serait nettement plus appropriée.
Il est également question ici d’un message d’erreur (voir la Figure 1). Celui-ci appartient à l’outil de contrôle de version « ClearCase » du logiciel IBM Rational Software. Cela prouve bien que même les grands noms du logiciel ne sont pas à l’abri d’erreur d’ergonomie.
En effet, ce message d’erreur ne respecte pas le critère de brièveté, l’un des critères d’ergonomie. Idéalement, ce message d’erreur devrait respecter la règle d’ergonomie suivante issue du livre de J-F Nogier [Nog02]
Le message d’erreur doit préciser la nature du problème et donner les moyens d’y remédier.
Produire des messages brefs, concis et pertinents.
Mais là n’est pas la seule erreur, puisque les deux boutons « ok » et « cancel » effectuent exactement la même opération. Ils ferment, tous les deux, le message d’erreur, uniquement.
Figure 1 - Message d'erreur du logiciel ClearCase
1.1.1 Définition
Nous allons tenter de définir l’ergonomie à partir des définitions que nous propose Google [Goo05]. En voici deux différentes :
highered.mcgraw-hill.com/sites/0072322098/student view0/glossary e-f.html
Nous avons aussi trouvé une autre définition permettant de comprendre ce terme.
Au regard de ces définitions, nous pouvons dire que l’ergonomie est l’étude scientifique des conditions de travail et des relations entre l’homme et la machine. L’ergonomie (ou l’étude des facteurs humains) vise à améliorer le bien-être des hommes et l’efficacité globale des systèmes. Dans notre situation, puisque nous nous intéressons aux interfaces utilisateurs, le terme « ergonomie » concerne une branche de l’ergonomie que nous appelons « Ergonomie d'interface homme-machine ». Nous pouvons dès lors garder en tête la signification suivante :
Rendre une interface ergonomique, c’est concevoir l’interface utilisateur en vue d’améliorer, d’optimiser l’usage de celle-ci par l’utilisateur et ainsi accroître la performance de l’utilisateur.
D’une manière plus simple, il s’agit de faciliter la compréhension et l’usage des interfaces utilisateurs. On parle parfois aussi d’ « utilisabilité 1 » d’une interface. L’utilisabilité peut être définie (ISO9241) comme l’efficacité, l’efficience et la satisfaction avec lesquels un utilisateur spécifié réalise un but spécifique dans l’environnement particulier. Où :
1.1.2 Objectif
L’utilisabilité d’une interface est essentielle, car elle détermine la performance de l’utilisateur. Plus l’interface est ergonomique, facile à utiliser, plus l’utilisateur réalisera sa tâche rapidement, sans perte de temps et avec moins de stress. Plusieurs études ont été réalisées et ont prouvé qu’une interface bien conçue permet de diminuer le temps nécessaire à la réalisation de la tâche, de diminuer le taux d’erreur, de réduire le temps nécessaire à la prise de décision, d’augmenter le temps d’extraction de l’information de l’interface, etc. et, par là, d’économiser de l’argent. L’étude de Cope et Uliano [Cop95] a montré qu’une seule fenêtre graphique, rendue plus ergonomique, a augmenté son efficacité et permis à une compagnie d’économiser jusqu’à 20.000 dollars sur un an d’opération.
De plus, l’ergonomie ou l’utilisabilité est un critère de qualité important. Prenons l’exemple d’un site web non ergonomique : lorsqu’un utilisateur arrive sur cette page web et qu’il éprouve de la difficulté à l’utiliser, il y a peu de chance qu’il revienne et il gardera une mauvaise image du site web. Le site web en question manque son objectif. Par contre, si la navigation, l’usage de l’interface est clair et précis, s’il arrive rapidement à l’information qu’il recherche, alors il la réutilisera. Un utilisateur moyen2 sera prêt à faire des concessions en termes de fonctionnalités et de performances lorsque l’interface est agréable à utiliser et qu’il ne perd pas de temps à apprendre à s’en servir. Posons-nous la question de savoir ce qui fait la force actuelle de Microsoft, l’un des plus grands fournisseurs de logiciels. A prix comparable et fonctionnalités comparables, un utilisateur ayant déjà d’autres logiciels de Microsoft, choisira le logiciel de Microsoft au lieu du concurrent puisqu’il sait que l’utilisation du logiciel de Microsoft ressemblera à ceux qu’il a déjà utilisés et qu’il prendra moins de temps à apprendre à l’utiliser. C’est aussi une raison pour laquelle certaines entreprises ne veulent pas changer de logiciel, le coût d’apprentissage pour un nouveau logiciel (même s’il est nettement meilleur) est trop élevé pour justifier la migration.
1.1.3 Application
Dans le monde de l’informatique et plus précisément celui des interfaces utilisateurs, l’ergonomie prend une place de plus en plus importante. Que ce soit au niveau du matériel informatique comme l’apparition de souris et du clavier de plus en plus ergonomique tel qu’illustré sur à la Figure 2 [Cor05], ou au niveau logiciel, au niveau des interfaces. Comme dit précédemment pour Microsoft, le « look and feel », c'est-à-dire la façon dont sont présentés les composants des interfaces et leur navigation doivent être constants d’un logiciel à l’autre, et d’autant plus entre les logiciels d’une même compagnie. Microsoft, IBM, Apple et d’autres producteurs de logiciels ont émis des « guidelines » concernant le « look and feel » de leurs logiciels [Mic95], [App87], [Ibm92]. Comme nous l’avons vu, l’ergonomie ou l’utilisabilité rendent les interfaces plus efficientes, plus efficaces. C’est dans cet objectif, que les auteurs des livres et sites web fournissent différentes règles d’ergonomie et conseils de conception.
2 Parfois c’est le contraire : les utilisateurs expérimentés préféreront Unix pour les performances, alors qu’un utilisateur débutant préférera Macintosh pour son utilisabilité élevée.
1.2 Accessibilité
Comme nous l’avons fait pour l’ergonomie, nous présentons un mauvais exemple d’accessibilité. Par exemple, la première page du site de l’UCL ... que nous avons repris à la Figure 3, avec, à côté, la visualisation de cette même page avec Lynx Viewer, un simulateur du navigateur Lynx en ligne [Del03]. Lynx est un navigateur textuel qui est utilisé par les personnes aveugles.
Nous avons indiqué quelques-unes des correspondances afin d’illustrer quelques erreurs. Les trois premières correspondances indiquées en vert et par les numéros 1, 2 et 3 sont de bons exemples. Les deux dernières, indiquées en rouge et par les numéros 4 et 5 sont des mauvais exemples.
Provide a text equivalent for every non-text element
Figure 3 - Comparaison entre la visualisation d'un site web par un navigateur classique et un navigateur textuel
On pourrait supposer évidement que rares sont les personnes qui utilisent ce type de navigateur, mais on se trompe. Par exemple, il y a plus de 6 millions de personnes handicapées en France dont 1,2 million de personnes déficientes visuelles [Kin05]. Parmi les déficients visuels, 9% sont totalement non voyants.
Par ailleurs selon une étude pour l’accès à l’emploi en Europe réalise en 2003, on a compté, dans les 15 pays de l’Union européenne, 37 millions de personnes ayant un handicap, soit 10% de la population. [Hou03]
1.2.1 Définition
Nous avons regardé quelles sont les définitions que nous donne Google pour le terme anglais « Accessibility ».
www.murdoch.edu.au/cwisad/glossary.html
Ces trois définitions donnent un bon aperçu de l’étendue du terme « accessibilité ». Dans le cadre d’un site web ou d’une application informatique, nous pourrions définir l’accessibilité comme suit :
L'accessibilité d'une interface ou d’un site web désigne sa capacité à pouvoir être consulté par tous et dans toutes les conditions.
« Dans toutes les conditions » se rapporte à la configuration matérielle de l'utilisateur, qui ne doit pas être un obstacle à la navigation de l’interface. [Tho05]
L’accessibilité est, par sa définition, proche de l’ergonomie. S’adapter à la taille de l’écran, fournir le contenu en plusieurs langues, sont des règles d’ergonomie qui améliorent également l’accessibilité de l’interface. L’accessibilité fait en quelque sorte partie de l’ergonomie, mais s’en distingue aussi. En effet, on mesure l’utilisabilité d’une interface dans un contexte particulier, c'est-à-dire par un utilisateur particulier, sur une plate-forme particulière, dans un environnement particulier, alors que l’accessibilité se soucie de rendre le contenu accessible quel que soit le contexte.
1.2.2 Objectif
L’objectif de l’accessibilité est de permettre à tous de participer à la vie active, de faire en sorte que le handicap dont certaines personnes sont victimes ne les en exclut pas. L’informatique et Internet en particulier sont devenus des éléments essentiels à la vie active. Quel que soit le métier que l’on pratique, on est confronté à tout moment à l’informatique. Du magnétoscope au guichet de banque électronique, du guichet de train au commerce en ligne, nous sommes tous confrontés à des interfaces utilisateurs. Si l’accessibilité de l’informatique et d’Internet est si important, c’est parce qu’Internet est une ressource croissante d’information et une ressource de plus en plus importante dans beaucoup d’aspect de la vie, que ce soit dans le domaine de l’éducation, du commerce, de la politique gouvernementale, sociale, récréative et bien plus encore. Il est donc essentiel de donner les mêmes accès et les mêmes opportunités aux personnes victimes d’un handicap. L’autre raison de l’importance de l’accessibilité de l’informatique est qu’Internet, plus que tout autre média, est capable de s’adapter à l’utilisateur. C'est-à-dire qu’il existe des aides techniques, des outils, des logiciels qui permettent aux personnes handicapées de surmonter leurs handicaps et d’accéder aux contenus.
1.2.3 Application
Cet objectif se traduit par des recommandations, des règles pour la conception des interfaces utilisateurs. Ces règles sont émises par des organismes, des associations.
1.2.4 Aides techniques
Les personnes victimes d’un handicap peuvent, elles aussi, utiliser Internet mais elles ont besoin d’outils particuliers. Ces outils sont appelés des « aides techniques3 ». Selon le handicap, l’utilisateur utilisera différentes aides techniques [WAI04].
D’autre part, outre ces aides techniques, les personnes victimes d’un handicap font souvent l’usage de navigateur textuel ou auditif. C'est-à-dire des navigateurs web qui transforment le site web en une version contenant uniquement du texte ou en des versions auditives qui peuvent être écoutées par l’utilisateur [WAI04].
3 Assistive technologies in English.
1.3 Règles
Ce que nous appelons règles correspond à une recommandation ou un conseil plus ou moins concret issu de résultats expérimentaux, de prédictions issues de théories de l’activité humaine, de principe de psychologie cognitive, de sens commun, d’expérience pratique, etc. Les règles peuvent être très concrètes et objectives comme « Accompagner l’icône de son nom » [Nog02] par exemple, ou, au contraire très abstraites et subjectives : « Provide Useful Content4 » [Koy03].
1.4 Validation automatique
Le meilleur outil pour évaluer l’utilisabilité d’un logiciel ou d’une interface est le test d’utilisabilité. Il s’agit de placer l’utilisateur final en situation effective d’utilisation du logiciel. Pour évaluer l’accessibilité d’une interface, on agit de manière similaire, c'est-à-dire que l’on place un utilisateur final victime d’un certain type de handicap en situation et on observe si l’utilisateur muni de l’aide technique adaptée éprouve encore de la difficulté à utiliser l’interface. Evidement, cela prend beaucoup de temps et d’argent. A partir des guidelines émis par les différentes sources, des méthodes d’évaluation ont vu le jour. Le site usabilis.com présente son mode opératoire (voir à la Figure 4) comme suit : « L'évaluation ergonomique consiste à passer en revue chacun des composants de l'interface. L'évaluateur vérifie si le composant respecte un ensemble de critères ergonomiques, appelé 'grille de critères' » [ Nog05].
Figure 4 - L'évaluation ergonomique consiste à évaluer chacun des composants de l'interface vis-à-vis d'une grille de critères.
Mais des outils de validation automatique ont également vu le jour comme WebXACT [Wat04a], A-Prompt[Apr02], LIFT[Lif05] ou Sherlock[Mah97]. Au lieu de faire évaluer le logiciel par un véritable utilisateur, l’on vérifie que l’interface a certaines propriétés qui contribuent à l’utilisabilité et l’accessibilité du logiciel. La validation automatique consiste à parcourir la structure de l’interface de manière systématique et de vérifier les valeurs des attributs, de vérifier la structure des objets, etc. Pour cela il faut que les règles soient traduites en un langage qui permet la validation automatique.
4 Fournir du contenu utile
1.4.1 Avantages
Les avantages de la validation automatique sont multiples [Ivo01], nous en présentons quelques-unes ci-dessous :
- une réduction importante des coûts car les méthodes automatiques font le travail plus rapidement.
- une meilleure uniformité des erreurs découvertes, ainsi qu’une prévision du temps et du coût des erreurs à travers une conception complète. Il n’est, en effet, pas simple de vérifier l’entièreté d’un logiciel par une méthode de validation non automatique.
- Une réduction du besoin d’expert en validation. Automatiser quelques aspects de validation telle que l’analyse ou les activités critiques permettent d’aider les concepteurs qui n’ont pas l’expertise dans ces aspects d’évaluation.
- La possibilité d’inclure l’évaluation à l’intérieur du processus de conception des interfaces utilisateurs, contrairement à l’application après implémentation. C’est important parce que l’évaluation avec la plupart des méthodes non automatiques peut typiquement être réalisée qu’après qu’un prototype ou l’interface aient été construits et tout changement à ce niveau sont bien plus coûteux [Nie93].
1.4.2 Inconvénients
Les inconvénients de la validation automatique viennent de sa limitation dans l’expression des règles principalement. En effet, certains aspects des interfaces graphiques ne peuvent pas être automatisés, tel que savoir si le texte d’un bouton sera compris ou non pas l’utilisateur. Christelle Farenc a montré que seulement 78% de l’ensemble des règles ergonomiques établies peut être évaluées par une validation automatique, et seulement 44% dans le pire des cas (voir à la Figure 5). [Far96]
Figure 5 - Le pourcentage des règles ergonomiques évaluables automatiquement dans le meilleur et le pire des cas
…
1.5 En phase de conception
La plupart des outils de validation automatique que nous présenterons au chapitre 2 sont de type « post-design » [Gae05]. C'est-à-dire que ces outils de validation sont utilisés après la phase de conception de l’interface et se basent donc sur le rendu final de l’interface utilisateur. Par opposition, ce mémoire consiste en une analyse sur : « comment serait-il possible d’intégrer un outil de validation automatique de règles d’ergonomie et/ou d’accessibilité au cours de la phase de conception ou du moins à un niveau indépendant du rendu final de l’interface utilisateur ? ».
1.6 Méthodologie
La méthodologie choisie pour cette analyse, se structure en 4 étapes (voir Figure 6). Dans un premier temps nous allons balayer nos différentes sources pour former un ensemble de règles d’ergonomie et d’accessibilité. Cet ensemble sera aussi large, aussi général que possible. Cette recherche sera expliquée au chapitre 3. La seconde étape consistera à classer ces règles selon certains critères choisis. Ce sera le sujet du chapitre 4. Ensuite, nous tenterons de traduire, d’interpréter les règles classifiées en des règles adaptées pour un langage particulier. C’est la troisième étape de notre méthodologie. Ce sera développé dans le chapitre 5. Finalement, notre étude se penchera sur les possibilités d’implémentation d’un outil de validation automatique pour ce langage particulier. C’est notre dernière étape qui sera présentée dans le chapitre 6.
Figure 6 - Les quatre étapes et leurs résultats intermédiaires de notre méthodologie
Au cours de notre démarche, les règles seront de plus en plus spécifiques. Le choix des critères de classification, le choix du langage, le choix des techniques d’implémentation vont faire que nos règles vont devenir de plus en plus précises, d’autant plus précises que le contexte d’application se définira. De même, au fur et à mesure que nous avancerons dans la démarche, nos règles générales se transformeront en plusieurs règles spécifiques. En effet, les règles que nous récolterons lors de la première étape seront très généralement abstraites et subjectives, lors de la classification et de l’interprétation, ces règles seront affinées en des règles concrètes, objectives et spécifiques au langage choisi.
1.6.2 Une restriction inévitable
Au cours de notre démarche, nous serons obligés de restreindre l’ensemble de nos règles. D’une part parce qu’il y en a des milliers et qu’il est impossible de les présenter toutes dans ce mémoire. D’autre part, parce que nous faisons des choix et « Choisir, c’est renoncer ». En effet, lors de la classification, certaines règles seront mises de coté, pour plusieurs raisons telles que : « pas classifiable », « pas pertinente pour cette analyse », « pas applicable aux interfaces utilisateurs », etc. De même, le choix d’un langage pour l’interprétation des règles va restreindre notre ensemble de règles. Aucun langage ne permet d’exprimer toutes les interfaces utilisateurs possibles à lui seul. Un langage est limité par sa structure, son étendue d’application, etc. C’est encore une explication à la restriction inévitable de notre ensemble de règles. Finalement, l’implémentation d’un outil de validation automatique, sera restreinte par les techniques utilisées pour exécuter la validation comme nous le verrons au chapitre 6.
Figure 7 - Chaque étape de la méthodologie restreint inévitablement l'ensemble des règles.
Chapitre 2 Etat de l’art
Dans l’introduction, nous avons défini notre méthodologie de travail. A partir de cette méthodologie en 4 étapes, il est intéressant d’observer ce qui a déjà été effectué. C’est l’objet de ce chapitre. Il est évident que d’autres études ont déjà été entreprises pour collecter, classifier, interpréter et évaluer les règles d’ergonomie et d’accessibilité. Parfois elles se sont concentrées sur une étape de la méthodologie, parfois sur plusieurs d’entres elles.
Pour ce chapitre, nous avons décidé de nous concentrer sur quelques outils de validation automatique.
Dans la section 2.1, nous présenterons un premier outil, WebXACT anciennement Bobby. La section 2.2, aura pour sujet A-Prompt, un autre outil de validation de règles d’accessibilité. Dans la section 2.3, d’autres études ou outils seront brièvement esquissés.
2.1 WebXACT
WebXACT est plus connu sous le nom de Bobby. Il s’agit de l’outil de vérification d’accessibilité des sites web le plus connu. Sa première version date de septembre 1996. A ce moment il se nommait encore Bobby et était un produit gratuit offert par CAST, The Center for Applied Special Technology [Cas05]. En 2001, il passe en version 3.3 et devient payant. En septembre 2002, Watchfire Corporation, un fournisseur en service et logiciel de gestion achète Bobby à CAST. CAST étant une organisation sans but lucratif, a estimé que Bobby sera plus utile et servira mieux les réalisateurs de site web si l’outil était confié à une compagnie qui est spécialisée dans le développement de logiciel et qui possède une bonne expérience dans le marketing de produit. Le produit WebXACT existe dans une version hors ligne très complète mais payante, et une version gratuite disponible en ligne (voir Figure 8).
Figure 8 - WebXACT dans sa version en ligne
WebXACT se base sur les deux grandes sources de directives concernant l’accessibilité des sites web, à savoir la section 508[508] et les directives de la WAI (Web Accessibility Initiative) [WAI98]. Nous parlerons de ces deux sources dans le chapitre 3.
Cependant, la vérification qu’il propose peut se faire soit pour les directives de la section 508, soit pour les directives WCAG 1.0 du WAI, avec la possibilité de choisir une compatibilité avec les 3 niveaux de priorité des directives WCAG 1.0. Il s’agit donc de 3 groupes, les directives de priorité 1 pour obtenir la WAI Conformance Level "A", les directives de priorité 1 et 2 pour obtenir la WAI Conformance Level "Double-A" et finalement toutes les directives, de priorité 1, 2 et 3 pour obtenir la WAI Conformance Level "Triple-A"
Puisque les règles d’accessibilité de la section 508 et celles contenues dans le WCAG 1.0 sont déjà assez fort dirigées vers le langage HTML, les concepteurs du logiciel WebXACT n’ont pas beaucoup de difficulté à interpréter les directives. En effet, le WAI fourni également des techniques HTML, CSS, etc. [W3C00a] [W3C00b] [W3C00c] pour s’assurer que le document que l’on évalue vérifie les directives voulues. WebXACT a cependant réorganisé et développé les directives du WCAG et de la section 508 en 94 points de contrôles. [Wat04b]
WebXACT est écrit en Java pour la version off line et en Java script pour la version en ligne. D’ailleurs un utilisateur a remarqué que le site de vérification en ligne de WebXACT utilise donc Java script pour fonctionner correctement. Mais justement, une des recommandations du WCAG 1.0, la directives numéro 6.3 de priorité 1 ("Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported") demande de fournir une alternative au Java script, puisque certains groupes de personnes handicapées désactivent cette technologie. [Pil03]
Les résultats que renvoient WebXACT doivent être interprétés avec un soin particulier (voir Figure 9). En effet, WebXACT attire l’attention sur beaucoup de problèmes potentiels, c'est-à-dire des règles que le logiciel ne permet pas d’évaluer. Nous le verrons plus tard, toutes les règles ne sont pas automatisables. Malheureusement, on ne peut, en général, pas dire si on a réellement une erreur ou non pour ces règles. Dans beaucoup de cas, il n’est pas nécessaire de faire attention aux éléments que propose WebXACT, mais bien plutôt de vérifier les facteurs de risques et de s’assurer qu’on les a manipulés correctement.
