RGAA - check-list basé sur le champ d'application

Bonjour,

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 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 :

http://img514.imageshack.us/img514/5572/01mr2.th.gif

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 :

http://img155.imageshack.us/img155/9306/02br1.th.gif

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
Modifié par buh31 (26 Oct 2007 - 23:14)

Hello,

Joli boulot.

Pour la question de la pertinence de cet outil et de la démarche plus ou moins induite (tu dis: «C'est une vision peut être trop orienté "code" des tests du RGAA, j'en ai conscience»), je ne me prononce par, car à vrai dire je n'y connais rien.

Oui, joli boulot

C'est une bonne idée, qui peut aider justement à la réalisation d'outils d'aide. Sur de gros projets, avoir à ne parcourir qu'une seule fois, semi-automatiquement ou entièrement manuellement, chaque page ne peut que faire gagner en productivité.

N'oublie pas qu'il va falloir le revoir en partie, car le RGAA actuellement publié n'est que la version de travail, celle qui a été soumise à l'appel à commentaires, et que la version définitive sera forcément différente...

Bonjour,

Beau travail en effet.

Maintenant, il y a quelques réserves à faire, dont une essentielle parce qu'elle touche au fond de la démarche du RGAA.

Le RGAA, tel qu'il se présente au public à ce jour, est une version de travail. Avec trois aspects à souligner ici:
- les tests actuellement en ligne ne sont pas les tests définitifs qui ont été finalement arrêtés (cf Gilles ci-dessus)
- les modes d'entrées transversaux dans le référentiel ne sont pas encore en place (cf Aurélien ci-dessus)
- surtout, sur le fond: pour travailler la démarche de déploiement progressif, nous avons dû privilégier dans un premier temps une présentation du RGAA qui peut induire en erreur sur un point-clé, celui des années de déploiement.

Je m'explique sur ce problème des années, car le travail (très intéressant) de buh31 comporte une erreur majeure :
- Dans le cadre régleenttaire, le déploiement est progressif, mais surtout élastique: 3 ans, 2 ans, 1 an.
- Hors du cadre réglementaire, c'est à dire pour des sites d'entitées privées, le RGAA permet potentiellement un déploiement encore plus élastique, c'est à dire en fait un véritable suivi de l'accessibilité sans notion de délai de déploiement global.

Il ne faut donc surtout pas définir des "priorités 1 2 3 4" comme expliqué ci-dessus :
- D'une part, le terme "priorité" doit être réservé à son sens propre en accessibilité WCAG (priorité 1 2 3, c'est à dire niveaux A AA AAA).
- D'autre part, ces priorités 1 2 3 4 n'ont pas de sens en dehors du cas spécifique d'un déploiement sur 3 ans.
- Enfin, elles conduisent à donner aux tests "recommandés en dernièe année" une priorité moindre qui n'existe pas dans le RGAA.

Je rappelle à cet égard que ce statut "recommandé en dernier année" ne correspond pas à des tests dont le bénéfice est plus limité que d'autres, ni à une notion de moindre besoin. Il n'est que la reconnaissance de difficultés de déploiement, qui peuvent, dans certains cas, et si l'on peut y apporter des motifs solides d'ordre notamment technique ou financier, conduire à ne pas valider un test.

Le sens de "recommandé" en dernière année est similaire au fameux "SHOULD NOT" souvent évoqué à propos d'XHTML. Ces tests ne doivent pas être ignorés. Ils doivent systématiquement être pris en compte. Ils peuvent mettre en évidence des cas où il est actuellement impossible de respecter WCAG dans un contexte donné. Mais ces cas doivent être spécifiquement identifiés, analysés et justifiés.

Le RGAA "colle" strictement à WCAG, et ne doit pas être interprété comme la création de "nouveaux niveaux", ce qui est hélas le cas ici.

Mais encore une fois, cela tient au fait que tu es parti de la version de travail actuellement en ligne, qui prête à confusion sur ce point. Et également au fait que, dans le cadre des référentiels publics, nous étions contraints d'utiliser ce terme "recommandé" qui prête également à confusion à la première lecture. Et enfin au fait que la notion de suivi d'accessibilité, dans la logique de la qualité Web, est encore à faire découvrir au public
Modifié par Laurent Denis (27 Oct 2007 - 08:42)