Jour 85 - L'audit d'accessibilité (partie 1)

Pourquoi et comment faire un audit ? Focus sur l’audit de conformité.

Ce que j’ai fait :

Ce que j’ai appris

Pourquoi faire un audit ?

Un audit d’accessibilité permet d’évaluer le niveau d’accessibilité d’un objet (site, application, document…) par rapport à un référentiel donné. Les audits se basent généralement sur un échantillon représentatif de pages et permettent de prioriser les actions à mener pour améliorer l’accessibilité. Cet audit est valable à un instant T, il peut être remis en question dès lors qu’une mise à jour des contenus est effectuée.

On peut vouloir réaliser un audit pour différentes raisons :

  • lors de la refonte ou de la mise à jour d’un site, pour connaître les actions à mettre en oeuvre pour intégrer l’accessibilité

  • en vue d’une demande de labellisation (obtenir un label AccessiWeb par exemple)

  • pour connaître le niveau de conformité d’un site d’un site

  • pour établir une déclaration d’accessibilité

L’article 47 de la Loi n° 2005-102 du 11 février 2005(lien externe) impose aux organismes publics et à certaines entreprises (celles délégataires d’une mission de service public et celles dont le chiffre d’affaires est supérieur à 250 millions d’euros réalisés en France) de publier un certain nombre de documents sur leur site web :

  • une mention du niveau d’accessibilité sur la page d’accueil, précisant si le site est conforme ou non

  • une déclaration d’accessibilité : c’est le résultat de l’audit d’accessibilité, elle présente l’état de conformité du site, liste les contenus non accessibles et fournit des moyens d’assistance et de contact

  • un schéma pluri-annuel de mise en accessibilité décliné en plans d’actions annuels, et dont la durée ne peut être supérieure à trois ans

Afin déterminer la conformité ou non d’un site contenue dans la déclaration d’accessibilité, il faut réaliser un audit de conformité.

L’audit de conformité

Il faut tout d’abord choisir le référentiel sur lequel se base l’audit, ainsi que le niveau de conformité. Actuellement en France, c’est le RGAA 4 (Référentiel Général d’Amélioration de l’Accessibilité) qui est la référence et il liste désormais indistinctement critères de niveau A et AA. C’est donc sur celui-ci que je m’appuie pour étudier la mise en oeuvre d’un audit de conformité. Il est néanmoins possible de réaliser des audits basés sur le référentiel WCAG (Web Content Accessibility Guidelines) ou AccessiWeb par exemple.

Note : suite à une remarque de Julie Moynat, il est important de préciser que le référentiel AccessiWeb se base encore sur la version 2.0 des WCAG et n’est donc pas à jour. Réaliser un audit basé sur ce référentiel ne serait donc pas conforme aux obligations imposées par la Directive européenne.

Tester la conformité au RGAA

Le RGAA comporte 13 thématiques, divisées en 106 critères dans lesquels se répartissent 257 tests. Pour valider un critère, il faut donc vérifier tous les tests associés à ce critère. Par exemple :

Critère 8.1. Chaque page web est-elle définie par un type de document ?

Test 8.1.1 :
Pour chaque page web, le type de document (balise doctype) est-il présent ?

Test 8.1.2 :
Pour chaque page web, le type de document (balise doctype) est-il valide ?

Test 8.1.3 :
Pour chaque page web possédant une déclaration de type de document, celle-ci est-elle située avant la balise <html> dans le code source ?

On peut ensuite attribuer 3 statuts à ces tests :

  • conforme
  • non conforme
  • non applicable (le contenu testé n’est pas concerné par ce test)

Note : un test peut également être dit “non testé”. Il ne s’agit pas d’un statut en tant que tel mais d’un moyen pour l’auditeur ou l’auditrice de marquer l’avancement de son audit.

Un critère est considéré non conforme dès lors qu’au moins un des tests est non conforme.

Un critère est considéré conforme si tous les tests sont conformes ou qu’il y a a minima un test conforme et des tests non applicables.

Conditions de l’audit

L’audit porte sur un échantillon représentatif de pages. Certaines pages sont obligatoires, comme la page d’accueil, la page de contact ou encore la page “plan du site” (lorsqu’elles existent). S’ajoutent également des pages constituant un processus (comme un formulaire de saisie), une page pertinente pour chaque type de service fourni, ainsi que des pages sélectionnées au hasard. Vous pouvez retrouver la liste des pages recommandées dans la section Obligations d’accessibilité(lien externe) du RGAA.

Il faut également définir une base de référence, c’est-à-dire un environnement de test. Selon le RGAA :

Par défaut, il est composé des technologies d’assistance majoritairement utilisées par les personnes en situation de handicap combinées avec les navigateurs et systèmes d’exploitation pour lesquels elles sont optimisées. Cet environnement de test minimal peut être complété, le cas échéant, par des solutions libres et gratuites disponibles ou par des technologies plus anciennes, en fonction de l’usage du service de communication au public en ligne.

Le RGAA présente ainsi dans sa section Environnement de test(lien externe) les combinaisons (technologie d’assistance, système d’exploitation, navigateur) à tester.

A noter que lorsque le site ou l’application est destiné à être diffusé dans un environnement spécifique, l’environnement de test est à adapter. Par exemple, lorsque le site web est exclusivement diffusé dans un environnement GNU/Linux, les tests doivent être réalisés uniquement sur les navigateurs et les technologies d’assistance utilisés sur cette plateforme.

Qui peut réaliser un audit ?

L’audit peut être effectué par l’organisme concerné lui-même (il s’agit alors d’une auto-évaluation) ou par un tiers. Dans tous les cas, l’audit doit être mené par des personnes formées. Il n’existe pas de titre ou diplôme officiel “Auditeur ou auditrice d’accessibilité web”, néanmoins de nombreuses formations permettent d’acquérir les compétences nécessaires :