X

Test utilisateur avec un mal-voyant : c’est vraiment trop injuste !

petit Calimero triste

... entendez-bien que cela ne provient pas du choix de l'utilisateur mal-voyant, mais bel et bien de notre projet web soumis au test ! Nous nous attendions de toute façon à une petite claque, mais pas à ce point :) Explication.


Le profil d'Olivier
Ancien de la pub, gérant actuel d'une société de conseil, il a perdu son acuité visuelle depuis 18 ans. La perception centrale est nulle. Olivier se repère donc très bien dans l'espace grâce à la périphérie visuelle subsistante : il gère sa société, participe à des marathons, fait de la voile. Une canne est tout simplement inutile !

Face à son problème visuel, l'ensemble du corps médical lui a conseillé d'exploiter au mieux ce qui lui reste de possibilités plutôt que de le considérer comme nun on-voyant et de l'orienter vers l'apprentissage du braille.

Olivier s'est alors adapté peu à peu à son environnement, grâce à des formations et à de la volonté. Il s'est équipé informatiquement pour son activité : un PC classique, un clavier ergonomique, un écran 20", une tablette/vidéo-loupe grossisant x50, une pédale de switch entre logiciels ouverts, l'outil ZoomText pour cette fois zoomer l'interface de son écran, le logiciel Jaws pour la navigation vocale, un téléphone à touches grossies. Un équipement indispensable acquis en 2004 pour l'équivalent de 9.000 euros... Merci aux fonds de l'AGEFIPH !

Aujourd'hui Olivier n'utilise pas Jaws.

J'ai énormément de mal à m'en servir ou à le configurer. La voix est horrible. Les informations remontées sont abrutissantes d'exhaustivités. Cela perturbe mes collègues de travail avoisinant à moins que je ne me rende sourd avec un casque.

Bref. Il préfère de loin utiliser ZoomText qui correspond mieux à ses facultés.

Le test utilisateur : un véritable drame sur le plan de l'accessibilité
Nous concevons, intégrons et développons nos projets interactifs, autant que faire se peut, en gardant constamment en tête les recommandations d'accessibilité WCAG. Nous effectuons des tests 'in live' car après tout rien de vaut ces tests utilisateurs. Et l'objet du test réalisé cette semaine, un site internet, a été un véritable défi, une séance de "torture", pour Olivier.

Voici en très résumé ce qu'il en ressort :

  • La possibilité de zoom (imaginez jusqu'à 4 ou 5 lettres sur l'écran, ou alors la flèche du curseur sur toute la hauteur de l'écran) est le principal point faible, le fond du problème d'accessibilité. Catapulté en plein milieu du gabarit du site, Olivier ne peut se repérer : quels sont ces trucs (sous menu) qui apparaissent ? où est la navigation ? comment revient-on à l'accueil ? etc.
  • Le choix de certains textes en blanc sur fond bleu est mauvais (comme par hasard, c'est la navigation) : il ne perçoit pas le contraste. Il faudrait du texte blanc sur fond bleu foncé presque bleu-nuit. Que dire de nos textes en gris foncé sur fond gris clair... ?
  • La version ancienne du player flash cumulée à IE 6.0 ont eu raison de nos vidéos. Bug technique que nous aurions pu éviter. Le lien de retranscription, pourtant une idée alternative qu'il a appréciée, n'est pas perçu avant qu'on le désigne.Le lien texte "accessibilité" pourtant placé dès le haut du site n'est jamais perçu car trop situé à l'écart du gabarit de page. Olivier nous a suggéré de placer en plus un repère visuel, sorte de "gros picto" pour l'aider. Mais alors quel logo mettre pour ne pas heurter la sensibilité des différents déficients ? Une personne avec une canne blanche, un fauteuil roulant, un oeil, une main, provoquent respectivement une réaction personnelle touchant l'orgueil même de l'handicap. "Je ne suis pas en fauteuil moi ! je ne distingue juste pas le centre de ma vision !", par exemple.
  • Enfin, au bout de trois quarts d'heure, sur la page d'aide à l'accessibilité définissant les principes de raccourcis-clavier prévus par le site, Olivier s'est arrété à la lecture de la liste des raccourcis sans en lire le mode d'emploi pour son navigateur présenté juste dessous. Il a donc cru que cela ne marchait pas...

Ce qu'il en resort
Un mal-voyant utilisant ZoomText zoome d'abord sur le site avant de chercher un lien "accessibilité". Même si ce lien est placé en tête, le fait de zoomer va lui agrandir une zone différente à 95% de (mal)chance.

Détail : sur la page d'aide à l'accessibilité, il est préférable d'expliquer le mode d'emploi selon les navigateurs en premier lieu, puis de donner les raccourcis ! Sinon, le déficient, désirant constamment gagner du temps pour compenser son handicap, s'arrête aux raccourcis et pense que cela ne marche pas en appuyant sur le pavé numérique...

Et d'une manière générale, il est plus aisé de prévoir l'accessibilité pour des non-voyants que pour des mal-voyants dont les déficiences sont variées.

Extension du domaine de la lutte
Ce qui m'amène à imaginer des réponses globales, autre que l'actuel moyen requis pas les webconcepteurs qu'est la mise en place de CSS multiples pour le maximum des utilisateurs.
Je pense que la solution est du côté des navigateurs web et du W3C avec l'arrivée attendue de l'HTML5. L'idée d'avoir une touche standard (le "tab" ?) sur tous les sites proposant un choix de lecture, une autre touche pour le plan du site, etc. Ou encore la présence d'un logo d'accessibilité (le fauteuil ?), à gauche des boutons flèche précédent/suivant. Bref tout le débat qui s'anime sur la mailing-list Accesstech de Netaccessible. Tristan Nitot, si tu me lis, je te remercie :)

11 commentaires sur cet article De “Test utilisateur avec un mal-voyant : c’est vraiment trop injuste !”

  1. Elie 15 février 2008 à 16 h 38 min

    Tout ce que tu dis me confirme que l’approche standard va devoir être associée par une prise en compte de la réalité du handicap et des pratiques. Là, il faut être prêt à réagir. Selon moi, ce n’est pas injuste, c’est juste normal. L’accessibilité aux personnes handicapées, ce n’est pas qu’une affaire de machines, c’est également une affaire d’usages par des êtres humaines avec leurs pratiques, leurs spécificités, leurs goûts et leurs paradoxes. L’anti « One Size fits all ».

  2. Christophe 15 février 2008 à 16 h 44 min

    Pourtant l’approche ‘One Size fits all’ est le fondement du WCAG…

    Pascal Weber sur la mailing-liste accesstech, propose carrément une touche « accessibilité » sur nos claviers (ou sur nos écrans tactiles). Intéressante idée je trouve également quand on réfléchit à ce qu’il faut prévoir derrière la fonction.

    Sinon, ce qui est injuste c’est le sentiment profond d’avoir prévu au mieux et de se sentir s’enfoncer peu à peu lors du test. Et puis cela m’aide à placer une image de Caliméro sur un site professionnel :)

  3. Stéphane Deschamps 16 février 2008 à 9 h 17 min

    Selon moi, quand on en arrive à un grossissement qui ne restitue plus que 4 ou 5 caractères par écran, on est au-delà de ce qui est admissible avec un zoom.

    J’utilise Jaws assez souvent pour savoir que Eloquence est terrible, mais ton ami peut aussi essayer d’autres synthèses plus agréables. Et baisser le son de son casque ;)

    Blague à part pour ma part si j’en arrive au moment où je ne verrai plus que 5 caractères par écran, je n’utiliserai pas de zoom.

  4. Stéphane Deschamps 16 février 2008 à 9 h 23 min

    PS : les tests que j’ai faits avec Zoomtext me font penser qu’il met le focus sur le coin haut/gauche de la page, sauf quand un crétin croit bon de mettre en Javascript le focus sur un champ texte de la page parce qu’il trouve ça sexy.

    En résumé : d’après mes tests, quand je lance le navigateur Zoomtext suit le focus curseur et pointe (visuellement) vers la barre d’adresse. Ensuite il me suffit de descendre un peu, ou de tabuler une fois pour trouver le premier lien de la page, et donc retomber sur mes pieds avec les liens « accessibilité » ou « sauter au contenu », qui est suivi par Zoomtext.

    Demande-lui d’essayer, avec Zoomtext : Alt+D pointe vers la barre d’adresse. Entrer une URL. Attendre le chargement de la page. Voir si le focus a bougé, sinon tabuler.

  5. goetsu 16 février 2008 à 11 h 31 min

    Il doit également pouvoir utiliser la recherche dans la page (ctrl+F accessibilité)

  6. pascal weber 16 février 2008 à 14 h 32 min

    Juste une ou deux réflexions : ce qui m’étonne, c’est qu’il ait encore besoin qu’on lui donne le mode d’emploi de ses propres outils… C’est une remarque que je fait vraiment en toute naïveté mais ça m’interpelle : on ne devrait avoir à indiquer que les raccourcis claviers disponibles sur le site. Il me semble qu’ensuite, le visiteur est censé savoir comment utiliser ces raccourcis sur le navigateur dont il se sert quotidiennement non ? On n’indique jamais comment un visiteur peut imprimer une page, ou comment la mettre en signet etc… En bref ma remarque est : doit-on réellement mettre sur chaque site le mode d’emploi de tous les navigateurs ou simplement inviter le visiteur à se reporter au mode d’emploi de son navigateur pour savoir comment utiliser les raccourcis ?

  7. Christophe 18 février 2008 à 10 h 13 min

    @Stéphane> bonne idée. Je lui demanderai lors de notre prochain test :) Je suis d’accord aussi sur le fait que zoomer pour n’avoir que 5 lettres semble peu pertinent et sans solution idéale pensée dès la conception. Après, chacun choisit son confort de navigation et se forge ses petites habitudes… d’où l’importance des tests auprès des utilisteurs dans leur propre environnement !

    @Pascal> en effet, mais partant de ce principe on ne devrait pas avoir à expliquer quoi que ce soit alors… Il en va de même avec la personne voyante à qui il faut expliquer comment créer un dossier sur son OS, comment naviguer sur un site marchand, comment retrouver un fichier télécharger sur son poste, etc. Bref ta remarque « naïve » me semble plutôt « utopique ».

    En ce qui concerne le mode d’emploi d’un site, je partage également l’idée que finalement ce n’est pas à chaque webmaster sur chacun des sites de proposer une navigation, aussi généraliste et répandue en usage qu’elle soit. On en revient donc aux standards et à la solution orientée html+navigateur.

  8. bob (mc melun) 18 février 2008 à 16 h 21 min

    @Christophe.

    L’universalité n’est de toute façon pas de mise puisque chaque navigateur et/ou système vient mettre en l’air la belle harmonie. D’où la nécessité d’en ajouter encore et toujours au niveau de la page d’accessibilité.

    Sinon il reste la solution des accesskey mais elle n’est pas non plus exempte de problème, surtout avec des lecteurs vocaux qui utilisent les mêmes commandes pour faire autre chose que ce que l’on veut.

    Et il n’y a toujours pas standard dans les actions correspondant aux valeurs, même si on arrive à peu près à faire tous la même chose mais en n’utilisant que les chiffres.

    J’ai été confronté cette semaine à un handicap, mon cousin ayant été opéré et ne voyant -mal- que d’un oeil. Son ordinateur ayant un clavier différent du mien, je ne pouvais même pas le conseiller quant au positionnement de ses mains !!!

  9. Christophe 18 février 2008 à 16 h 51 min

    @Bob> « D’où la nécessité d’en ajouter encore et toujours au niveau de la page d’accessibilité ».

    Une nécessité de contournement applicable aujourd’hui : oui. Mais on peut optimiser largement cela, j’en suis persuadé, afin d’éviter justement que chacun créent ses propres raccourcis. :)

    En touchant à l’accessibilité des autres on se rend vite compte que cette « accessibilité » est une donne incontournable et tout aussi essentielle pour nous : nous serons tous amenés à être déficients plus tard pendant que « le réseau » poursuivra son évolution. Bon rétablissement à ton cousin !

  10. bob (mc melun) 21 février 2008 à 17 h 08 min

    Je précise que nous devons remplir la page d’accessibilité avec ce qui découle des navigateurs, systèmes et standardisation des accesskey, pas par ce que nous ajoutons de notre propre fait.

    Qui peut le plus peut le moins, je me souviens d’un site déclaré AAA qui ne pouvait pas l’être, comme on le voyait rapidement par quelques tests simples, qui utilisait une technologie spécialisée (depuis abandonnée) pour une navigation particulière pour les handicapés (pas que visuels), je crois me souvenir pas recevable AAA non plus.

    Vivement qu’il y ai un référentiel qu’on sache au moins quoi mettre dans un site « officiel », à charge pour nous de faire encore mieux ensuite.

    Mon cousin va mieux, en une semaine il a réussi à se lever et à marcher loin de sa chambre, puisqu’il m’attendait devant l’hôpital, mais a toujours son problème de vision. Patience maintenant… Merci pour lui.

  11. Christophe 21 février 2008 à 17 h 18 min

    « Je précise que nous devons remplir la page d’accessibilité avec ce qui découle des navigateurs, systèmes et standardisation des accesskey, pas par ce que nous ajoutons de notre propre fait.  »

    En ce qui concerne les accesskey en fait si : le webconcepteur fait ce qui lui plaît en tenant compte ou non des bonnes pratiques en place.

    (content pour ton cousin)

Laisser un commentaire

Votre nom *
Votre mail *
Site internet
Message

Nous contacter

Pour nous (re)joindre

captcha

Coordonnées

NEOMA interactive by Linagora
100 Terrasse Boieldieu
Tour Franklin
92042 Paris - La Défense Cedex
France
(+33) 1 46 96 63 63