Préparation de l'audit

Avant de démarrer un audit, vous devez définir un certain nombre d'éléments :

  • le contexte de l’audit ;
  • le niveau de conformité à confronter ;
  • la base de référence pour réaliser les tests de restitution ;
  • l’échantillon de pages qui sera testé.

Contexte

Un audit peut intervenir à diverses occasions :

  • Préparation à une labellisation ou à la rédaction et publication d'une déclaration de conformité ;
  • Réalisation d'un état de l'existant généralement pour trancher sur une question de refonte ;
  • Suivi d'un site en développement ;
  • Audit de contrôle…

Préciser le contexte de l'audit va vous permettre d'adapter la préparation de l'échantillon ainsi que les recommandations que vous ferez.

On peut classer les audits et les recettes en deux grandes familles :

Les audits destinés à préparer et accompagner la mise en accessibilité des contenus.

Dans ces types d'audits, il s'agit de relever les non-conformités et de proposer des solutions de corrections. Ces audits peuvent également servir de base à la priorisation des problématiques rencontrées afin de prendre en compte les contraintes du projet.

Ces audits sont les plus longs à mener, ils doivent être les plus complets possible car ils seront le socle technique du projet d'accessibilité.

Audits d'évaluation et de certification.

Les audits d'évaluation vont permettre d'obtenir une vue instantanée du niveau de conformité d'un site, ils s'effectuent le plus souvent sur un échantillon de critères représentatifs et un échantillon de pages réduit. Ils ne comportent généralement pas de préconisation de correction.

Les audits de certification ont pour vocation d'attester, lors d'une procédure de certification ou de déclaration légale, le niveau de conformité atteint par le site ou l'application.

Ces audits ne comportent généralement pas de préconisation de correction, ce n'est pas le but recherché, il s'agit de fournir un relevé des non-conformités qui sera le socle technique de la mesure de conformité.

Ils doivent être menés avec beaucoup de rigueur et dans le cas d'une labellisation par exemple, selon une procédure établie qui peut comporter des différences notables avec l'audit classique. Par exemple, le label e-accessible propose des niveaux différents de ceux du RGAA.

Dans les deux cas, la procédure de mise en place et de préparation est identique.

Niveau de conformité

Vous devez définir en accord avec l'administration, le niveau de conformité à évaluer.

Afin de répondre aux besoins de divers groupes et de différents contextes, trois niveaux de conformité ont été définis : A (le plus bas), AA et AAA (le plus élevé)[1].

Les critères de succès sont associés à l’un des niveaux A, AA et AAA sur la base de divers facteurs[2].

Par ailleurs, le niveau AAA possède la particularité de ne pas s’appliquer à tous les contenus ou dans tous les contextes :

Il n’est pas recommandé de se fixer le niveau AAA comme objectif à l’échelle de sites entiers car il n’est pas possible de satisfaire à tous les critères de succès du niveau AAA pour certains contenus[3].

Le niveau recommandé par l’Union européenne est le niveau double A (AA) [4]. C’est également le niveau attendu pour les sites concernés par le RGAA. À ce titre, pour être conforme au RGAA, il est nécessaire de valider l’ensemble des critères ayant un niveau WCAG déduit A et AA. Les critères de succès associés au niveau AAA peuvent être pris en compte dans certains contextes, lorsque cela est possible et pertinent.

Selon le contexte et la demande de l’administration, vous devez donc spécifier, avant de réaliser l’audit, le niveau à évaluer et donc les critères à évaluer. Ceci dit, compte tenu du contexte juridique, il est très souvent souhaitable de réaliser un audit de niveau AA.

Base de référence

Plusieurs critères RGAA font référence à des tests de restitution à effectuer sur un ensemble de technologies d’assistance (TA), de navigateurs et de systèmes d’exploitation. Vous devez définir cette base de référence avant de commencer l’audit.

Il s'agit essentiellement de tests à réaliser sur des composants développés avec l'API ARIA afin de s'assurer que les restitutions sont correctes.

La base de référence est constituée des configurations (technologie d’assistance, système d’exploitation, navigateur) qui permettent de déclarer qu’un dispositif est « compatible avec l’accessibilité » :

Un contenu ou une fonctionnalité doit être compatible avec les technologies d’assistance des utilisateurs ainsi qu’avec les fonctions d’accessibilité des navigateurs et des autres agents utilisateurs via une API d’accessibilité[5].

Toutefois, ni WCAG ni le W3C ne spécifient quelles technologies ou encore combien de ces technologies doivent être évaluées pour qu’un composant puisse être déclaré conforme.

Ainsi, le RGAA a décrit une base de référence établie par consensus à partir de la liste des technologies d’assistance dont l’usage est suffisamment répandu, ou dans certains cas lorsqu’elle est fournie de manière native et constitue le moyen privilégié d’accès à l’information et aux fonctionnalités.

La base de référence permettant de couvrir la proportion la plus large des usages est constituée de combinaisons associant des technologies d’assistance d’usage suffisamment répandu, les deux systèmes d’exploitation Windows XP+ et OSX/macOS et les trois navigateurs IE9+, Firefox et Safari.

Pour qu’un dispositif HTML5/ARIA ou son alternative soit considéré comme compatible avec l’accessibilité, il faut qu’il soit pleinement fonctionnel, en matière de de restitution et de fonctionnalités, sur au moins une des combinaisons décrites dans la base de référence du référentiel technique[6]. À moins d’être dans un environnement maîtrisé, c’est avec l’une de ces combinaisons que vous devez tester les composants identifiés. La DINSIC met à disposition un guide pour évaluer l'accessibilité des composants à l'aide des lecteurs d'écrans [7].

Environnement maîtrisé

Lorsque le site web est destiné à être diffusé et utilisé dans un environnement maîtrisé, la base de référence est constituée des configurations (technologie d’assistance, système d’exploitation, navigateur) effectivement utilisées dans l’environnement maîtrisé.

Par exemple, lorsque le site web est exclusivement diffusé dans un environnement GNU/Linux, les tests devront être réalisés uniquement sur les navigateurs et les technologies d’assistance utilisés par les agents sur cette plateforme. Cette base de référence se substitue à la base de référence utilisée en environnement non maîtrisé.

Un environnement est maîtrisé si l’accès à l’information, les technologies, les conditions d’utilisation et le profil des utilisateurs peuvent être connus a priori et donc maîtrisés. Les principaux éléments dont la maîtrise est essentielle sont :

  • Le type et la version des navigateurs ;
  • Les technologies supportées, leur version et leur activation (JavaScript, WAI-ARIA, Flash, Silverlight…) ;
  • Les technologies d’assistance et tout dispositif utilisé de manière spécifique par les utilisateurs handicapés ;
  • Les systèmes d’exploitation et les APIs d’accessibilité supportées ;
  • La formation des utilisateurs de technologies d’assistance à l’utilisation de tout dispositif particulier (interface, application en ligne…).

Les auteurs et les administrateurs doivent garantir la compatibilité des technologies utilisées et de leurs usages par les utilisateurs et leurs technologies (y compris les technologies d’assistance). Les services d’information ou les sites web, quel que soit leur statut, qui offrent un accès public ne peuvent pas être considérés comme des environnements maîtrisés.

Adaptation de la base de référence.

La base de référence proposée par le RGAA n'est qu'un socle de base. Si nécessaire, elle peut être adaptée et étendue à des technologies d'assistances ou des contextes de consultation différents.

Cela peut-être le cas par exemple en enrichissant la base de référence des technologies d'assistance pour mobile comme Voice Over pour iOS ou de Talkback pour Android pour citer les deux cas les plus couramment rencontrés.

En dehors du cas spécifique des environnements maîtrisés, les technologies d'assistance proposées dans la base de référence du RGAA devraient être systématiquement conservées.

  1. Source : traduction française agréée des WCAG 2.0, chapitre « Les exigences de conformité » (retour au texte)
  2. Source : traduction française agréée des WCAG 2.0, chapitre « Comprendre les niveaux de conformité » (retour au texte)
  3. Source : traduction française agréée des WCAG 2.0, chapitre « Les exigences de conformité » (retour au texte)
  4. Le point 31 de la résolution du Parlement européen du 13 juin 2002 précise que tous les sites publics européens doivent avoir le niveau double A (AA) du W3C/WAI (retour au texte)
  5. Définition « Compatible avec les technologies d’assistance » issue du glossaire du RGAA 3 (retour au texte)
  6. Base de référence du RGAA 3 (retour au texte)
  7. Guide sur les lecteurs d'écran (retour au texte)