Le , par Laurent Denis - Accessibilité
Avertissement : cet article a été publié en 2009. Son contenu n'est peut-être plus d'actualité.
Lors des Ateliers Paris-Web, nous avons abordé, l’ami Gautier Barrère du CTIE Luxembourgeois et moi-même, la prise en compte de l’accessibilité WAI dans une démarche d’ergonomie. Lors d’un second atelier, j’ai évoqué en compagnie de Gilles Chagnon l’Initiative Utilisabilité menée actuellement sur les projets mediaWiki comme Wikipédia. Le rapport entre ces deux ateliers est amusant.
ReNo est une démarche qualité globale, avec comme objectifs majeurs l’ergonomie et l’accessibilité WCAG. Avec Gautier, nous avons un peu manqué de temps lors de l’atelier Reno et WCAG2.0 pour présenter la rencontre de nos visions respectives de l’accessibilité vue par l’ergonome et de l’ergonomie vue par l’expert accessibilité. Elles partent de points de vue différents, mais se rencontrent aisément, se recoupent et finalement collaborent dans la joie et la bonne humeur, ce qui est l’essentiel. Si tout va bien, nous vous en reparlerons dans un prochain article.
Bref, pour ce qui nous occupe ici, un audit accessibilité (ATAG) a mis en évidence un souci d’utilisabilité des fonctionnalités de création de tableaux dans le CMS utilisé dans le cadre ReNo: il ne donne pas d’accès évident à la fenêtre où le rédacteur peut rendre accessible un tableau de données.
!
Ce n’est pas dramatique : c’est détecté et pris en compte, c’est en voie d’amélioration.
L’Utilisability Initiative, elle, est une démarche strictement ergonomique, qui a pour objectif d’améliorer la facilité de contribuer à Wikipédia et aux projets similaires. A ma connaissance, elle n’intègre initialement aucune donnée d’accessibilité. L’absence de rencontre entre ces deux dimensions de la qualité produit hélas des effets potentiellement ravageurs : ce n’est pas évalué, c’est ignoré, ce n’est pas maîtrisé.
- assister le rédacteur dans la saisie de contenus complexes comme les tableaux, via une interface permettant de générer un tableau-type à partir d’une case à cocher et d’un bouton de soumission est une excellente idée d’ergonomie. Le faire avec un script qui, derrière le bouton, oublie de générer une moitié essentielle mais triviale du code nécessaire à l’accessibilité du tableau ainsi produit est une énorme bourde.
! - Dans le même ordre d’idée, limiter un menu d’actions à ce qui est immédiatement utile, en différant ce qui est plus complexe dans un menu déroulant est certainement une démarche intéressante en ergonomie. L’intégrer finalement sous forme de menu full CSS inexploitable au clavier est une énorme bourde.
!
Ce sont de petites choses, me direz-vous. Les corrections seront aisées… mais à condition de ne pas s’y prendre au dernier moment. Sans compter qu’oublier l’utilisabilité pour une partie de la cible (point de vue de l’ergonome) ou l’accessibilité naturellement vécue (point de vue de l’expert accessibilité), c’est tout de même une belle occasion manquée.
Comme quoi, accessibilité et ergonomie sont définitivement dans le même bateau, qu’elles le sachent ou non…