Je commence à réfléchir depuis un bon moment à l'intégration des notions d'accessibilité dans les projets web.
J'ai donc commencé à chercher quelle base de travail utiliser, et mon choix s'est porté sur le Référentiel Général d’Accessibilité pour les Administrations (RGAA) pour plusieurs raisons :
- Le jour où un décret d'application de la loi n°2005-102 de février 2005 sera mis en place pour rendre obligatoire l'accessibilité des sites web du secteur public, c'est vraisemblablement ce document qui sera pris en référence, et qui devra être suivi par les agences web qui réaliseront les sites web du secteur public. Donc, utiliser déjà le RGAA, c'est anticiper le futur, et pouvoir assurer à ses clients qu'ils n'auront pas à complètement refondre leur site quand le décret sera adopté, même si le RGAA aura peut être évolué d'ici là.
- Le document prend comme référence le WCAG 1.0, et donc suivre le RGAA c'est suivre les recommandations du W3C en terme d'accessibilité.
- Il s'agit du document le plus récent à ce jour (par rapport aux critères AccessiWeb) et il prend en compte d'autres recommandations que WCAG : UWEM et AERT.
- Le document fourni des explications et des exemples pour aider à la bonne compréhension des directives.
Le champ d'application comme filtre
Les tests proposés dans le RGAA ont la particularité d'indiquer clairement le champ d'application du test. Pour le test 1.1.1 Présence de l'attribut alt par exemple, il est indiqué que le champ d'application se limite aux éléments img, area, input type='image' et applet.
Je me suis rendu compte qu'un champ d'application pouvait être commun à plusieurs tests.
Si nous prenons par exemple l'élément fieldset, il fait partie du champ d'application du test 3.3.2, du test 12.3.2 et du test 12.3.3.
Donc, j'ai eu l'idée de filtrer tous les tests, pour obtenir une fiche par élément, ce qui permettrait de faire en une fois tous les tests correspondants à cet élément.
Ainsi, j'ai crée chacune de ses fiches sous ce modèle :
La colonne WCAG indique le niveau WCAG du test :
- A : Ce qui doit être fait
- AA : Ce qui devrait être fait
- AAA : Ce qui pourrait être fait
La colonne Priorité donne des indications sur le caractère prioritaire du test dans le cadre d'un déploiement dans le temps du RGAA :
- Priorité 1 :
- année N : Obligatoire
- année N+1 : Obligatoire
- année N+2 : Obligatoire
- Priorité 2 :
- année N : Recommandé
- année N+1 : Obligatoire
- année N+2 : Obligatoire
- Priorité 3 :
- année N : Recommandé
- année N+1 : Recommandé
- année N+2 : Obligatoire
- Priorité 4 :
- année N : Recommandé
- année N+1 : Recommandé
- année N+2 : Recommandé
La colonne Points de contrôle indique le numéro du point le contrôle auquel est lié le test. Un lien hypertexte renvoie vers la page web de la fiche RGAA du point de contrôle.
Il est très utile, voire indispensable de consulter cette fiche pour mieux comprendre, par l'explication et les exemples fournis, comment faire le test.
La colonne Tests donne le titre du test. Un lien hypertexte renvoie vers la page web de la fiche RGAA du test.
La colonne champ d'application indique le champ d'application du test, que j'ai élargi en indiquant si cela concernait le code html ou le code css, et en donnant des précisions supplémentaires. Un lien hypertexte sur le mot champ d'application renvoie vers la première feuille du classeur Excel, qui forme la liste de tous les éléments à tester.
La colonne vérification fait apparaître la vérification qui doit être faite à travers le test. J'ai modifié sensiblement le texte à chaque fois pour préciser le champ d'application, ainsi j'ai par exemple remplacé le texte "Si l'un des éléments mentionnés dans le champ d'application est présent dans la page, poursuivre le test, sinon le test est validé" par le texte "Si la balise <fieldset></fieldset> est présente dans la page, poursuivre le test, sinon le test est validé."
Je me suis donc retrouvé avec une feuille par élément. Pour pouvoir facilement consulter les feuilles j'ai crée une feuille qui se trouve au début du classeur avec un tableau qui liste l'ensemble des éléments sous cette forme :
Un lien hypertexte sur chacun des éléments renvoie vers la feuille du classeur Excel qui liste tous les tests à effectuer pour l'élément concerné.
Pour ne pas surcharger un seul classeur, j'ai crée 3 classeurs :
- 1-html-checklist.xls qui regroupe tous les éléments à tester trouvables dans un document html,
- 2-css-checklist.xls qui regroupe tous les éléments à tester trouvables dans un document css,
- 3-divers-checklist.xls qui regroupe tous les éléments à tester que je n'ai pas pu classer dans les 2 précédents classeurs.
Les versions Excel et OpenOffice se trouve dans ce dossier. Les versions OpenOffice sont justes des conversions des versions Excel mais elles fonctionnent.
Pourquoi ai-je voulu réorganiser les tests du RGAA par champ d'application ?
Je veux pouvoir faire en sorte que les tests sur un site web puisse se faire de manière linéaire, ligne à ligne, effectuer les tests sans avoir ensuite à revenir en arrière dans le code pour faire les autres tests.
C'est une vision peut être trop orienté code des tests du RGAA, j'en ai conscience.
Pour finir, je tiens à préciser que tout ce que je viens de présenter ici n'a rien d'officiel ni de définitif, et qu'il y a peut-être des inexactitudes dans mes tableaux. Il s'agit avant tout de travaux en cours issus de réflexions personnelles sur le RGAA, réflexions non achevées 
Si vous avez des remarques sur ma démarche, je suis tout ouïe 
