Conduite de l'audit

Réalisation de l'audit

Maintenant que tout est prêt et que l’échantillon est validé, vous pouvez réaliser l’audit de conformité RGAA. Des modèles de documents^[1] sont mis à votre disposition, et notamment une grille d’audit. Cette grille vous propose de fonctionner par onglet : un onglet par page auditée. Tous les critères du RGAA sont repris, avec leur niveau. Selon le niveau de conformité souhaité, certains critères vont pouvoir être directement évalués en non applicable. Par exemple, si vous réalisez un audit du niveau double A (AA), tous les critères triple A (AAA) sont non applicables. Il en va de même pour une évaluation de niveau simple A, les critères double A (AA) et triple A (AAA) deviennent non applicables.

Important : La grille d’audit ne reprend que l’intitulé du critère, vous devez toujours travailler avec le référentiel technique pour vous référer aux tests, notes techniques, cas particuliers et glossaire.

Méthodologie de tests

Il n'existe pas une méthodologie de référence pour mettre à l'épreuve les tests du RGAA. Toutefois, il existe des techniques et outils largement répandus et partagés. Le W3C a d'ailleurs établi une liste d'outils pour l'évaluation^[2].

Vous pourrez trouver des outils automatiques, qui vous aideront dans l'évaluation des critères de présence (par exemple, test 1.1.1 « Test 1.1.1 : Chaque image (balise img) a-t-elle un attribut alt ? »). Néanmoins, la plus grosse partie du travail reste entièrement dépendante de l'évaluation de l'auditeur. Les outils permettent de rendre l'évaluation plus rapide et les conditions d'évaluation optimales. Ce peut être des barres d'outils disponibles dans les navigateurs web, des feuilles CSS personnalisées, des bookmarklets JavaScript…

La DINSIC a produit une méthodologie^[3], qui définit pour chaque critère et test, deux méthodes au moins (selon les capacités des navigateurs et des extensions pour l'évaluation d'un critère donné). Lorsque c'est possible, une méthode est proposée pour chacun des 3 navigateurs les plus populaires : Internet Explorer, Firefox et Chrome.

Éléments communs aux pages

Aujourd’hui, un site web qui n’est pas réalisé avec un outil de gestion de contenu (CMS par exemple) fait exception. Avec cette industrialisation des sites web, les éléments de gabarits (navigation, entête, pied de page…) sont identiques (même code source, même fonctionnement…) sur toutes les pages du site, ou sur un même ensemble de pages. Bien qu’il soit demandé d’évaluer tous les composants d’une page pour la déclarer conforme ou non conforme, il est possible de faire l’économie d’auditer plus de 15 fois le même code (par exemple la navigation), lorsqu’on est assuré qu’il est le même sur toutes les pages.

Vous pouvez relever la non-conformité une seule fois la première fois qu'elle est rencontrée et ne plus auditer cette partie de contenu répété sur les autres pages. Si nécessaire, vous pouvez reporter systématiquement la non-conformité sur toutes les pages directement ou par l'intermédiaire d'une référence, par exemple « voir page x ».

État des pages

Lorsque vous auditez une page, vous devez procéder en plusieurs étapes. En tout premier lieu, vous devez auditer la page dans son état standard, sans activer d’éléments. Ensuite, une fois que vous avez repéré tous les éléments susceptibles d’être interactifs (un menu déroulant, un formulaire, etc.), manipulez-les pour déclencher les actions et évaluer les éventuelles mises à jour de contenu.

Dans le cas des formulaires, une démarche de test pertinente est la suivante :

auditer le formulaire vide ;
soumettre le formulaire vide et constater s’il existe un contrôle de saisie qu’il faudrait évaluer ;
soumettre le formulaire avec des données susceptibles de provoquer des erreurs s’il existe un contrôle de format (par exemple, pour une adresse mail, omettez l’arobase) qu’il faudrait évaluer également ;
enfin, soumettre le formulaire avec des données qui vont vous permettre de réaliser une soumission correcte du formulaire pour constater l’événement déclenché, et auditer les éventuelles mises à jour de contenu.

Preuve de la non-conformité

Aucune obligation n’est faite sur la méthodologie à employer pour évaluer un critère, de même qu'aucune méthodologie ou qu'aucun outil n’a valeur de preuve au regard de l’évaluation d’un critère. Vous êtes libre de choisir les outils et méthodes que vous souhaitez, ce qui importe c’est la délivrance de la preuve de la non conformité ou de la conformité. Vous êtes responsable de la preuve. Cette preuve doit être vérifiable par un tiers et reproductible.

Lors d’un audit, vous documentez généralement exclusivement les cas de non conformité. En tant qu’auditeur, il vous incombe donc d’établir, pour chaque non conformité, la liste des preuves vérifiables et reproductibles. Ce peut être :

un extrait du code source (par exemple pour démontrer l’absence d’attribut alt sur une image) qui pourra être retrouvé facilement par l’administration ;
l’énonciation de la démarche employée (par exemple, pour démontrer un problème à l’agrandissement des caractères vous décrirez la méthode employée afin que l’administration puisse la reproduire et constater la même non conformité) ;
une capture d'écran.

Selon le principe d’une approche fondée sur la preuve, les critères de pertinence du référentiel technique du RGAA ne peuvent être invalidés que lorsqu’il est prouvé que cela pose un problème réel en matière d’accès à l’information, aux contenus, aux fonctionnalités ou à leur bonne compréhension.

Ces preuves de non-conformité sont à reporter dans la grille d’audit, dans la colonne « Commentaires » en regard du critère incriminé.

En cas de doute sur un test, la méthodologie associée au RGAA peut faire référence. Par exemple, dans le cas où un outil considère que tel test est non conforme et que l'application de la méthodologie vous conduit à considérer qu'il est conforme.

Un exemple et une proposition de correction

Pour chaque critère non conforme, vous devez donner au moins un exemple de non conformité, mais vous n’êtes pas tenu de citer toutes les occurrences d’une non conformité, sous réserve d’avertir l’administration dans votre relevé qu’il existe d’autres occurrences, et de lui fournir un moyen de repérer les autres occurrences.

Par exemple, pour le critère 13.2 « Dans chaque page web, pour chaque ouverture de nouvelle fenêtre, l’utilisateur est-il averti ? ». Si vous détectez 50 liens qui ouvrent des nouvelles fenêtres, vous indiquerez dans votre relevé des non conformités un seul exemple (code source d’un des liens en défaut). Vous indiquerez qu’il existe d’autres liens qui présentent la même erreur, comment les détecter et comment les réparer.

Exemple de commentaire pour une non-conformité pour le critère 13.2 :

On trouve dans la page des liens qui ouvrent des nouvelles fenêtres. Par exemple :

<a href="url.html" target="_blank">Site du gouvernement</a>

Pour tous les liens qui ouvrent une nouvelle fenêtre (liens possédant la propriété target avec une valeur différente de _self ou _parent, ou liens gérés par JavaScript qui déclenchent l'ouverture de nouvelles fenêtres), vous devez avertir l’utilisateur, par exemple, en implémentant un titre de lien (attribut title) sur le modèle :

<a href="url.html" target="_blank" title="site du gouvernement nouvelle fenêtre">Site du gouvernement</a>