Plan de site Navigation
Blog & Blues Techniques et Standards de la Qualité Web

Accueil > weblog


- Lire le billet précédent - Lire le billet suivant -

Eclairage sur le RGAA: la logique des tests unitaires

Par Laurent Denis, le 15 mai 2007.

Avertissement: la migration du RGAA vers un nouveau site pour la publication de sa version finale étant en cours, les liens ci-dessous ne sont plus disponibles. Vous pouvez cependant vous reporter à la version de l'appel à commentaire au format PDF.

Un aspect des tests d'accessibilité du Référentiel Général d'Accessibilité pour les Administrations (RGAA) qui peut parfois paraître déroutant au premier abord est leur caractère unitaire. Il peut donc être utile d'apporter ici quelques précisions rapides à ce sujet.

Prenons l'exemple des tests portant sur la présence et la pertinence de l'alternative textuelle des images HTML. Un premier test (RGAA 1.1.1) vérifie, en toute rigueur, la simple présence de l'attribut alt des éléments img :

  1. 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é.
  2. Si l'élément possède un attribut alt, le test est validé, sinon le test invalidé.

Comme tous les tests du RGAA, celui-ci est décomposé en étapes logiques pour permettre un traitement point par point :

  1. L'étape 1 permet de valider immédiatement une page ne comportant aucun élément img (ni aucun autre élément du champ d'application de ce test).
  2. L'étape 2 permet d'invalider immédiatement une page comportant au moins un élément img (ou autre élément du champ d'application) dénué d'attribut alt.

Un second test (RGAA 1.1.2) s'attache ensuite uniquement aux images dites "décoratives", c'est à dire qui n'apportent pas d'information nécessaire à la compréhension ou à l'utilisation de la page. Ces images doivent recevoir une alternative textuelle vide :

  1. 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é.
  2. Si l'élément possède un attribut alt vide, poursuivre le test, sinon le test est validé.
  3. Si l'élément est uniquement décoratif, le test est validé, sinon le test est invalidé.

Le test procède à nouveau point par point :

  1. L'étape 1 permet à nouveau de valider immédiatement une page ne comportant aucun élément img (ni aucun autre élément du champ d'application de ce test).
  2. L'étape 2 "sélectionne" les éléments dotés d'une alternative vide.
  3. L'étape 3 permet de valider une page où chaque alternative vide correspond effectivement à un élément décoratif, et de l'invalider dans le cas contraire.

Cependant, la seconde étape de ce test peut aussi conduire à un résultat apparemment surprenant : si ma page comporte une image dénuée d'alternative textuelle, ce qui est un défaut rédhibitoire, elle sera considérée ici comme valide.

Naturellement, il ne s'agit pas, à ce stade précis, de validité du point de vue de l'accessibilité. Mais simplement du mécanisme des tests unitaires :

  • La validation d'accessibilité pour la présence des alternatives textuelles alt est traitée par le test 1.1.1, et par lui seul.
  • Dès lors, aucun autre test ne doit faire "remonter" un résultat invalidant la page pour le même motif : lorsque j'examine dans le test 1.1.2 la pertinence des alternatives vides, je ne prends donc plus en compte les erreurs d'accessibilité dues à des absences d'attributs alt.

Le terme "valide" est donc à prendre, dans ces tests, en gardant à l'esprit ce mécanisme :

  • La ou les étapes initiales d'un test concernent son applicabilité, et "valide" ne signifie pas nécessairement "valide pour l'accessibilité". Un test non applicable sera dit valide à ce stade.
  • La ou les étapes finales d'un test concernent son accessibilité, et "valide" y est le résultat d'accessibilité.

L'intérêt majeur de cette démarche est d'obtenir, au terme des tests, un résultat parfaitement significatif, où chaque item dit "invalidé" correspondra effectivement à un type d'erreur unique, donnant ainsi une image chiffrée exacte des problèmes rencontrés.

Trackbacks

Les trackbacks pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.

Commentaires

Monique, le 15 mai 2007

Bonjour,

En fait je pense que cette logique déroute surtout tous ceux qui sont habitués à utiliser des outils tels que le validateur HTML du W3C, qui déclare l'ensemble d'une page valide ou pas.

Mais il a certainement fallu une grande rigueur dans l'élaboration des tests pour que, au final, rien n'ait été oublié dans les multiples procédures de test.

Amicalement,
Monique

tetue, le 16 mai 2007

C'est vrai que cette procédure de test et de validation n'est pas des plus intuitive, et qu'il m'a fallu en référer à ce que je connais déjà d'autres référentiels pour être certaine de bien comprendre.

aurélien, le 16 mai 2007

arf déjà ton deusième billet sur le sujet, tu m'en laisse un peu pour mon retour de congé smiley clin d'oeil

Les commentaires pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.