Wikipédia:Atelier accessibilité/Méthodologie
La démarche de l'atelier accessibilité s'appuie avant tout sur les directives d'accessibilité des contenus Web (WCAG1). Celles-ci nécessitent cependant le recours à une méthode d'application qui permette notamment :
- d'actualiser les points de WCAG1 temporaires (datant de 1999) et de tenir compte des avancées du projet WCAG2 (qui est presque finalisé)
- de préciser ceux-ci dans le contexte de Wikipédia.
En l'absence d'une méthodologie spécifiquement définie pour Wikipédia, les méthodes indiquées ci-dessous sont indicatives.
La démarche usuelle en accessibilité WCAG consiste à :
- procéder à une évaluation de l'existant, reposant sur l'audit d'un échantillon de pages types des contenus et de pages stratégiques, audit basé sur un référentiel de tests (voir dernière section de cette page)
- déterminer les points faibles à améliorer et les points forts à conserver
- effectuer les corrections et s'assurer de leur pérennité.
Elle vise à atteindre et maintenir un niveau de résultat figé (l'un des niveaux A, AA ou AAA défini par WCAG).
Cette démarche est inadaptée ici, en raison de la multiplicité et de la volatilité des contenus. (Des tentatives d'évaluation en ce sens ont eu lieu, voir Accessibles, les sites web au Québec ? et apparemment Utilisateur:Valérie75 en 2006)
Wikipédia relève plutôt d'une démarche de gestion des risques en continu, où l'évaluation se fait avec une approche de type ATAG (Accessibilité des outils de production de contenu). La démarche consiste alors à :
- identifier et lever les obstacles à la production de contenu accessible aux différents niveaux du projet, c'est-à-dire du CMS et de son usage (faire en sorte que Wikipédia « n'empêche pas » l'accessibilité)
- identifier et développer les moyens par lesquels la production d'un contenu accessible peut être favorisée (Faire en sorte que Wikipédia « encourage » l'accessibilité)
Il ne s'agit pas à proprement parler dans le cadre de cet atelier d'un véritable démarche ATAG, mais plutôt d'une approche intermédiaire entre la démarche habituelle et ATAG : l'accessibilité de l'interface d'édition et plus généralement de mediawiki en tant que CMS n'est par exemple pas totalement traitée.
6 niveaux de risque modifier
L'analyse repose sur l'identification de 6 niveaux de risque pour l'accessibilité. À chaque niveau, il est possible d'identifier des obstacles et/ou des moyens de favoriser l'accessibilité :
| exemples d'impact | |
|---|---|
| Noyau mediawiki |
|
| templates défaut |
|
| Extensions |
|
| paramètres localisés | |
| Modèles |
|
| Contributeurs (éditorial) |
|
Les trois premiers niveaux (noyau mediawiki, templates par défaut, extensions) ne relèvent pas des moyens d'action direct de cet atelier. Il est cependant tout à fait possible d'intervenir via des signalements de bogues et des propositions d'amélioration auprès des développeurs.
Le cas spécifique du risque éditorial modifier
L'accessibilité de Wikipédia ne se réduit pas à des questions techniques dont le traitement serait plus ou moins automatisable. Le travail éditorial (apports et modifications quotidiennes de la part de tous les contributeurs) et l'aspect collaboratif ont un impact majeur sur l'accessibilité du contenu.
| Directive WCAG1.0 | Point de contrôle | Exemple Wikipédia |
|---|---|---|
| 1. Fournir des alternatives équivalentes aux contenus visuels et auditifs | 1.1 Fournir une alternative textuelle aux éléments non textuels | Pertinence des alternatives d'images |
| 2. Ne pas s'en remettre exclusivement aux couleurs | 2.1 Ne pas utiliser uniquement la couleur pour donner accès à l'information | Choix graphiques pour les cartes, schémas, etc. |
| 3. Utiliser le balisage et les feuilles de styles de façon appropriée | 3.5 Utiliser la hiérarchie de titres | Réticence fréquente à descendre à un niveau de titrage suffisant (TOC trop longue) |
| 3.6 Utiliser les éléments de liste de manière appropriée | Préférence pour des listes non structurées pour des raisons de style (exemples) | |
| 5. Créer des tableaux qui se transforment de façon élégante | 5.1 Baliser les en-tête de lignes et de colonnes | Pertinence des libellés d'en-tête |
| 5.5 Donner des informations complémentaires sur les tableaux de donnée | Pertinence des résumés et des titres de tableaux | |
| 13. Fournir des mécanismes de navigation clairs | 13.1 Identifier la destination des liens | Pertinence des libellés de liens |
| 13.3 Fournir des informations sur l'architecture générale du site | Catégorisations obscures | |
| 13.4 Fournir des mécanismes de navigation cohérents | Pertinence des variations à travers les projets (palettes de navigation, etc.) | |
| 13.8 Rédiger les contenus de façon simple, logique et ordonnée | Qualité de la rédaction des articles | |
| 14. S'assurer que les pages sont claires et simples | 14.1 Utiliser un langage clair et simple | Pertinence des liens pour la compréhension du contenu |
| 14.2 Proposer des illustrations visuelles ou sonores | Pertinence des images et illustrations sonores pour la compréhension des contenus | |
| 14.3 Proposer une présentation cohérente sur tout le site | Pertinence des choix graphiques pour l'invariabilité du style de présentation des blocs d'information et de navigation |
Stratégie possible pour l'atelier modifier
Le travail peut concrètement s'organiser avec un ordre de priorité en fonction de l'impact du risque. Par exemple :
- Common.css et Common.js
- Modèles et extensions les plus utilisés (ne pas oublier {{Palette Modèles principaux}}
- Micro-contenus éditoriaux les plus fréquents (exemple : langue, liens, alternatives d'images)
- Projets les plus producteurs de contenus « normalisés » (exemple : Communes de France)
- Articles de qualité et bons articles (dans la mesure où ils définissent la forme retenue comme objectif pour tous les articles)
Outre l'identification précise des points/pages/modèles/etc. à suivre, une première phase du travail initial devrait être la déclinaison d'une des méthodes d'évaluation existante, de manière à l'adapter au cadre de mediawiki. Par exemple :
- adapter les champs d'application des tests pour qu'ils portent sur les syntaxes wiki plutôt que sur le résultat HTML (quand c'est possible et pertinent)
- écarter les éventuels tests non applicables compte-tenu de la nature du site et de ses contenus
- décomposer en rubriques correspondant aux divers besoins, pour en faciliter l'usage (« tester une infobox », « tester une carte cliquable », « tester un script »…)
- faciliter l'utilisation en rédigeant de manière plus pédagogique et directement adaptée aux usages des Wikipédiens
Méthodes d'application de WCAG permettant de tester les contenus Wikipédia modifier
Les évaluations peuvent s'appuyer sur les tests définis par l'une des méthodes suivantes :
- méthode de déploiement française publique RGAA : récent, complet par rapport à WCAG, mais un subset des tests applicables devrait être produit pour simplifier le travail. Le document actuellement disponible à cette adresse n'est pas sa version finale, mais celle-ci peut être disponible par ailleurs.
- méthodologie d'évaluation européenne UWEM 1.2 : récent, ne couvre pas totalement WCAG, même contrainte de produire un subset de tests, sous réserve de la question des droits.
- Guide de la méthode Accessiweb : bientôt réactualisée, ne couvre pas totalement WCAG, ajoute quelques critères supplémentaires, mais a le grand mérite d'être la plus pédagogique. Pas de possibilité cependant de tirer un subset de tests (questions de droits).