Wikipédia, un terrain d'expérience précieux pour l'accessibilité (1) : le CMS et son contexte

Avertissement : cet article a été publié en 2009. Son contenu n'est peut-être plus d'actualité.

Je m’intéresse depuis longtemps à l’encyclopédie Wikipédia pour une raison bien particulière : elle constitue un champ d’observation et d’expérience particulièrement riche en matière d’accessibilité. En effet, le principe des contenus éditables par tous les internautes fait des sites Wikipédia une sorte de gigantesque loupe sur les questions d’accessibilité éditoriales, qui sont l’une des clés de la gestion suivie des risques en la matière : au royaume de Wikipédia, le rédacteur est roi. Nous allons donc tenter de saisir son impact sur l’accessibilité.

! Pour poser le décor, voyons tout d’abord dans ce premier billet (et à grand traits) comment se présente le CMS Mediawiki en matière d’accessibilité. Comme il s’agit d’une application complexe, nous allons “peler l’oignon” en distinguant plusieurs couches fonctionnelles (et en nous limitant à sa capacité à produire un contenu accessible, l’accessibilité de l’interface d’édition étant une toute autre question, tout particulièrement importante pour Wikipédia, mais que nous aborderons peut-être plus tard dans d’autres billets).

Mediawiki proprement dit

En premier lieu, Mediawiki proprement dit bénéficie d’une démarche de séparation des contenus structurés et de leur mise en forme CSS. Si les templates actuels des pages de l’encyclopédie ne peuvent être qualifiés d’accessibles (au niveau A), les corrections nécessaires seraient cependant aisées : elles relèvent, pour le plus immédiat, de la cohérence de l’ordre linéaire du contenu ou de celle de l’ordre de tabulation, ainsi que du respect de la stricte hiérarchie de la structure de titrage, ou encore des pseudos-contenus CSS. Autant de défauts dont la correction serait immédiate, puisqu’il s’agit uniquement de corriger des détails de code dans un template. D’autres soucis autrement plus importants ne se situent pas dans les templates du contenu, mais plutôt dans la génération de certaines pages spéciales liées à l’interface d’édition, que nous ne traiterons pas ici. Retenons qu’il est relativement aisé de faire de mediawiki un outil générant son contenu final dans une interface de consultation accessible, ce qui n’est pas le moindre de ses mérites, mais que ce serait plus délicat s’il s’agisait de son interface d’édition.

D’autre part, le CMS permet par défaut de produire la plupart des éléments sémantiques HTML essentiels pour l’accessibilité des contenus textuels et graphiques (alternatives textuelles des images, titrage hiérarchique, listes, blocs de citation, attributs de changement de langue, etc.) Seuls manquent à l’appel quelques éléments isolés (élément Q pour les citations en ligne, éléments ABBR et ACRONYM, attribut LONGDESC des images).

Enfin, certains choix fondamentaux posent en revanche de redoutables problèmes d’accessibilité. C’est en particulier le cas avec :

• l’absence de contrôle éditorial sur les TITLE de liens, automatiquement générés par l’outil, qui laisse pendante la question des libellés de liens non explicites en contexte (au niveau A de WCAG2.0) ou hors contexte (au niveau AAA).
• surtout, la gestion très particulière des images de contenu qui, pour donner accès à la mention de leur licence et de leur auteur, sont obligatoirement des images liens vers leur propre page Wiki : rédiger l’alternative textuelle d’une image-lien est une toute autre affaire que s’il s’agit d’une image simple, et le fait que rien ne justifie éditorialement que chaque image de contenu soit un lien complique singulièrement les choses pour les rédacteurs. Mediawiki rend donc actuellement particulièrement difficile la gestion des alternatives textuelles par ses contributeurs.

Le noyau Mediawiki a donc un potentiel important à permettre la production de contenus accessibles, mais celui-ci reste à réaliser. Surtout, nous allons voir qu’il est loin d’être seul décisif.

Les extensions

Une part non négligeable de l’accessibilité des contenus produits par mediawiki dépend également d’une autre couche fonctionnelle: celle des extensions du CMS. Certaines de ces extensions étendent en effet la palette de contenu qui peuvent être insérés dans les articles, en y ajoutant par exemple:

• des “timeline”, c’est à dire des schémas du type frise cholonogiques ou histogrammes dont le rendu graphique est généré en ligne à partir de la saisie des données par les contributeurs sous forme textuelle.
• des images cliquables (images MAP) générées selon le même principe.
• ou encore des notes en fin d’articles, avec un jeu de liens internes dans la page permettant d’accéder à une note depuis son appel dans le texte, puis de revenir au point où se poursuit la lecture du texte.

Or, selon l’intérêt porté à l’accessibilité par leurs concepteurs respectifs, les extensions de mediawiki peuvent avoir des effets très divers mais décisifs sur celle-ci. Ainsi :

• “imagemap” permet de produire des images cliquables accessibles (où chaque zone réactive est dotée d’une alternative textuelle pertinente et où l’image globale est elle-même dotée d’une alternative pertinente)
• “cite”, l’extension utilisée pour les notes, a le potentiel nécessaire pour produire des liens explicites, bien que celui-ci ne soit généralement pas exploité et que l’accessibilité laisse sur ce point à désirer.
• en revanche, “timeline” ignore la notion d’alternative textuelle.

Les extensions posent à l’évidence, dans le cadre d’un projet Opensource tel que mediawiki, l’intéressant problème de la sensibilisation des développeurs bénévoles à l’accessibilité, et, du coup, du contrôle qualité par le projet lui-même.

Une couche de scripts

La couche suivante est une autre forme d’extension, constituée par des scripts qu’une décision communautaire va conduire à intégrer par défaut dans tout ou partie des occurences de Wikipédia. Ainsi, un jeu de scripts AJAX ajoute aujourd’hui à certains articles un système de cartographie appelé WikiAtlas, dont le détail de code pose d’importantes difficultés d’accessibilité, et notamment :

• la génération d’un code HTML en lui-même non conforme (iframe dénuée de TITLE, absence d’alternatives pertinentes aux images, etc.)
• les difficultés d’accès clavier.

De la même manière, on peut citer également un script insérant dans les menus de chaque article une série de liens et de fonctionnalités de génération d’un PDF, ou encore un script adopté sur la wikipédia francophone permettant de commander auprès d’un imprimeur une version “poster” de certaines images.

Nous sommes ici dans une problématique similaire à celle des extensions: une culture de l’accessibilité à développer et à transformer dans les faits.

Styles, scripts et modèles locaux

Nous allons à présent aborder d’autres couches fonctionnelles qui donnent la main à chaque communauté, uniquement le cadre de “sa” Wikipédia (l’exemple pris sera celui de la Wikipédia francophone).

Chaque communauté peut en effet influer de manière décisive l’acessibilité des contenus qu’elle produit à travers trois outils clés :

• la personnalisation d’un jeu de feuille de style
• la personnalisation d’un jeu de javascripts
• des modèles de contenu qui peuvent être utilisés dans les articles

La personnalisation des styles et des scripts est théoriquement ouverte à chaque contributeur, mais elle est en pratique soumise à un filtrage de fait : seul les administrateurs ont la possibilité de modifier les feuilles de style et les fichiers de scripts en question, le cas échéant suite à une demande des contributeurs. Ces administrateurs sont des contributeurs élus, pour partie sur leur connaissance immédiate de l’outil, mais sans compétences particulières dans les domaines de la publication Web et moins encore quand il s’agit de problématiques spécifiques comme celle de l’accessibilité.

En revanche, les modèles peuvent être créés par n’importe quel contributeur (les modèles les plus utilisés peuvent être protégés, et se retrouvent dans le même cas que les CSS et les JS).

Ces trois types de personnalisation ont un impact majeur sur l’accessibilité des contenus. A titre d’exemple :

• le système de cache: un script ajoute à chaque lien externe vers une référence utilisée pour étayer le contenu de l’article un second lien vers une archive Web de cette ressource. Le service d’archives et le script associé sont le produit d’un prestataire externe. Il a été possible, grâce à la collaboration avec celui-ci, de veiller à ce que ce script et le contenu qu’il génère respecte les normes d’accessibilité (script non intrusif, génération de liens explicites, etc.)
• A l’inverse, une demande récurrente des contributeurs porte sur l’ajout d’un javascript de redirection automatique, qui poserait inévitablement d’importants problèmes d’accessibilité.
• Du côté CSS, les contrastes de couleurs doivent faire l’objet d’un suivi constant, la plupart des contributeurs y étant, disons, peu attentifs.

Ce niveau de gestion des contenus pose un problème nouveau : on ne peut à l’évidence aborder une communauté entière de rédacteurs comme on l’aura fait pour les décideurs et les intervenants des couches précédentes.

Conclusion

Cette analyse fonctionnelle rapide illustre plusieurs questions fréquentes de la problématique d’accessibilité dépendante du CMS :

• la capacité de l’outil à produire automatiquement le balisage nécessaire à l’accessibilité des contenus : dans le cas de Mediawiki, elle est certaine, mais à confirmer au prix de quelques améliorations qui ne posent pas de difficultés majeures sur le principe. Elles demandent en revanche une sensibilisation ou une formation des décideurs du projet Mediawiki à la problématique de l’accessibilité.
• la capacité de l’outil à donner la main en dernier ressort au contributeur sur chaque contenu consultable, même lorsqu’il est produit automatiquement (les liens et leur TITLE) : c’est un des soucis majeurs de mediawiki à l’heure actuelle, mais malgré cet impact plus important, la problématique est similaire à la précédente.
• la prise en compte de l’accessibilité dans des services tiers inclus dans les contenus (scripts spécifiques et extensions qui peuvent être considérés comme des services tiers) : tout est à faire pour aller au-delà des succès accidentels et des échecs fréquents d’aujourd’hui.
• le “pouvoir” donné aux rédacteurs d’influer massivement l’accessibilité des contenus via des modèles ayant un impact sur de très nombreuses pages : constitutif du projet, cet aspect va nous occuper au premier chef.

Finalement, au-delà de ces éléments fonctionnels pourtants déterminants à première vue, ce sont également les choix de contenu qui vont s’avérer essentiels : la forme principalement textuelle des contenus actuels lève en effet de nombreuses difficultés potentielles, mais chaque enrichissement en contenu graphique ou interactif fait peser de nouvelles hypothèques sur l’accessibilité de l’encyclopédie. Et… Devinez dans quel sens poussent les rédacteurs avides de nouvelles fonctionnalités ?

Sinon, à l’inévitable question: “Wikipédia est-elle accessible ?” nous n’avons aucune réponse immédiate et simple à donner, si ce n’est que poser ainsi la question est le meilleur moyen de ne pas pouvoir y répondre. Dans le cas d’un contenu particulièrement mouvant dont l’accessibilité est en question à chaque instant où un contributeur édite un article, il s’agit plus que jamais de réfléchir en terme de risques de non accessibilité et de moyens de gérer ceux-ci, et non en termes d’évaluation à l’instant “T”. Pour qui tiendrait à avoir un embryon de piste de réponse, nous dirons seulement que le potentiel de l’application laisse entrevoir la possibilité d’une accessibilité au cas par cas, article par article, quelque-part au-delà du niveau A, parfois jusqu’au niveau AA. Mais cette estimation n’a qu’un intérêt opérationnel extrêment ténu : l’opérationnel est le contributeur en action, bien plus que l’application.

Dans le second billet de cette série, nous allons donc nous intéresser plus particulièrement à l’action des rédacteurs et au rôle central des modèles de contenu qu’ils peuvent mettre en place.