La deuxième journée Accessiweb organisée par Braillenet lundi 3 mai dernier à la Cité des Sciences et de l’Industrie de la Villette s’est comme la première fois déroulée trop vite. On ne saurait trop remercier les instigateurs de cette journée, l’équipe de Dominique Burger et Pierre Guillou, tant pour la qualité de l’organisation que pour celle des interventions.
Axes de travail de Braillenet
Il a d’abord été question notamment de l’accessibilité de l’administration électronique, des services de banques, de commerce, d’information, d’éducation et d’accès à la culture [1]. Dans l’ensemble, les sites publics ne sont pas utilisables par les handicapés.
En rédigeant ces lignes je réalise (si ce n’était pas déja fait) qu’ils ne sont pas forcément beaucoup plus utilisables par les valides, pour un certain nombre de raisons, dont, j’en suis sûr, le fait qu’ils sont très souvent organisés comme la structure administrative qu’ils représentent, là où il serait plus profitable de les penser en fonction des besoins du visiteur. Mais cette démarche implique un recul qui met et mettra encore un certain temps à faire son chemin.
Retours d’expériences : la douche froide du développeur consciencieux
À travers l’expérience des différents intervenants de cette journée plus orientée vers les usages que vers les technologies [2], nous avons pu constater que le web ne diffère en rien ou presque du reste de l’expérience quotidienne des handicapés : tout est pénible, tout est laborieux. L’apparition du virus du jour (Sasser) a été fatale à la démonstration de Julien Perben : les premières applications impactées furent le synthétiseur vocal et l’interpréteur Braille. Un utilisateur pourtant aguerri réduit à l’impuissance complète en une seconde !
En tout, cette démonstration et les suivantes nous ont vraiment fait prendre conscience de véritables problèmes liés à l’accessibilité, qui vont bien au-delà des simples règles qu’on se fixe au quotidien en tant que concepteurs web, comme le respect des textes alternatifs sur les images ou la structuration la plus sémantique possible du contenu. Ce qui semble une bonne idée pour un handicap peut se révéler plus ou moins radicalement bloquant pour un autre.
La bonne nouvelle c’est que ces démonstrations nous font comprendre certaines recommandations un peu abstruses des WCAG. Par exemple, pourquoi s’efforcer de mettre un texte unique sur chaque lien ? La réponse, qui ne m’était jamais apparue jusque-là, est qu’un handicapé moteur qui pilote son navigateur à la voix (par exemple avec Dragon NaturallySpeaking) peut accéder directement à la page liée en lisant le lien. Répéter dix fois "lire la suite" sur une page rend les liens moins maniables.
Quelques points qu’on a pu noter :
- Pour les aveugles, faire des pages plus claires, structurées et concises
- Pour les handicapés moteurs mettre des liens vers le haut de la page (faire défiler la page est un véritable calvaire quand la trackball est manipulée avec le menton)
- Mettre un texte différent sur chaque lien (voir ci-dessus)
- Réfléchir à d’autres moyens de mettre en évidence des champs de formulaire en erreur que ce qui se fait habituellement (un peu de dhtml et une boîte d’alerte ne suffisent plus)
Rencontres
Surtout, les journées de Braillenet sont l’endroit idéal pour faire des rencontres. La première fois c’est Tristan qui m’a fait l’honneur de papoter à bâtons rompus, sans oublier Elie Sloïm, Monsieur Veille (depuis dix ans, nous apprend Denis). Cette fois-ci, je suis assis à côté d’une dame sage et discrète qui, au détour d’une intervention micro, se révèle être rien moins que Monique Brunel, un des piliers de webmaster-hub !
Nous avons pu en cours de route rencontrer Matthieu Faure, Mathieu Froidure, d’Urbilog (société qui travaille sur un validateur d’accessibilité des sites, Ocawa, prometteur mais encore balbutiant), et quelques ergonomes très intéressants de FTRD, sans oublier le charmant et démonstratif anglais Jon Dodd de Bunnyfoot.
Nous sommes des éternels débutants
Comme la première fois, on ressort très humble de ce genre de manifestation : tout reste à faire, nous ne sommes qu’au tout début de la mise en conformité de nos sites (dans ma boîte comme dans toutes les autres) ; chaque handicap pose des questions particulières et de nouvelles solutions restent encore à trouver... Une double conclusion qui s’impose, conclusion que j’ai tentée de résumer au micro mais dont j’ai oublié le deuxième point [3] :
- On ne peut pas reprocher à un site d’être plus ou moins inaccessible [4] sans connaître les tenants et les aboutissants techniques. Souvent un site n’est que la partie émergée (et pas forcément prioritaire) d’un système informatique complexe et hétérogène.
- Que faire pour être accessible quand certaines recommandations favorisant un handicap en pénalisent un autre au passage ? Simplement, il faut faire preuve de bon sens. Tester, encore et toujours. Et trouver la moyenne mesure la plus satisfaisante (la "moins pire", comme on dit chez nous).
Comme d’habitude, c’est une affaire de mesure. On ne le répétera jamais assez : faire du code valide, c’est déjà le rendre à 50% accessible. Pour le reste, ne jamais, jamais se reposer sur ses lauriers. Encore aujourd’hui, malgré son apparente maturité, le web s’invente au jour le jour.
