5. Modalités d'application du RGAA

L’objectif du RGAA est de donner aux responsables de services de communication publique en ligne désirant se lancer dans une démarche de mise en accessibilité ou de création d’un nouveau service en ligne, les moyens de pouvoir le faire dans les meilleures conditions possibles. L’opportunité est ainsi offerte d’inclure l’accessibilité numérique dans les cahiers des charges d’appels d’offres et de mettre à la disposition des services concernés un outil d’évaluation adapté.

L’appropriation progressive du RGAA se concrétisera ainsi par une démarche volontaire d’évolution de l’accessibilité de chaque service de communication publique en ligne. Elle repose sur une procédure d'auto-évaluation (ou d'évaluation par un tiers selon les compétences disponibles localement) et sur une démarche de mise en accessibilité qui devra s’adapter au type de projet (création d’un nouveau contenu Web, refonte d’un site existant, amélioration continue, échantillonnage).

Retourner en haut de la page

5.1 Niveaux de conformité à l’accessibilité

La traduction française agrée des WCAG 2.0 indique : « 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é). »

Les critères de succès ont donc été associés à l’un des niveaux A, AA et AAA sur la base de divers facteurs dont la liste est proposée (en anglais) à l’adresse suivante :
http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head

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. »
http://www.w3.org/Translations/WCAG20-fr/#conformance-reqs

Le niveau recommandé par l’Union Européenne est le niveau AA. C’est également le niveau attendu pour les sites concernés par le RGAA et à ce titre, pour être conforme au RGAA, il est nécessaire de valider l’ensemble des tests 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.

Retourner en haut de la page

5.2 Démarche de mise en accessibilité

L’objectif du RGAA est d’accompagner les démarches de mise en accessibilité par la fourniture des critères techniques à mettre en oeuvre et des tests correspondants. En fonction du projet de mise en accessibilité, des objectifs d’accessibilité et des différentes phases du projet, le RGAA doit servir de référent en répondant aux questions d’accessibilité qui se posent dans différents contextes.

Le RGAA pourra notamment être utilisé dans les contextes suivants:

• la mise en oeuvre d’un nouveau site (refonte)

Cette approche consiste à prendre en compte les recommandations du RGAA du début à la fin du projet de création du site (analyse, production, mise en ligne, maintenance, vie du site).

• l’amélioration d’un site existant et la réalisation de l’attestation de conformité

Cette approche consiste à évaluer l’accessibilité d’un site déjà en Production, de façon à extraire des indicateurs, des résultats globaux, des recommandations opérationnelles, et éventuellement des résultats pour le site et pour ses pages.

Retourner en haut de la page

5.2.1 Mise en oeuvre d’un nouveau site (ou refonte d’un site existant)

Cette approche consiste à intégrer les recommandations du RGAA dès les premiers travaux de mise en oeuvre ou de refonte globale du site et tout au long des différentes étapes jusqu’à la mise en Production du site internet. Cette prise en compte en amont permettra d’assurer l’accessibilité du futur site en intégrant des vérifications tout au long du processus de création.

Voici quelques phases fondamentales de la vie d’un site Internet au cours desquelles le RGAA peut être mise en application. Attention, suivant l’étendue et le contexte du projet, ces phases ne sont pas toujours effectuées ou déroulées dans l’ordre présenté ci-dessous. Ces étapes reflètent le cas général.

• Analyse des besoins

L’analyse des besoins consiste va permettre de répondre à des questions telles que :

• Quels sont les objectifs du site ?
• Quelle est la teneur des contenus ?
• Quelles sont les problématiques à résoudre ?
• Quelle est la cible ?
• Etc…

Cette étape ne nécessite pas formellement l’utilisation du RGAA mais il est à noter qu’elle correspond au moment ou l’on définit la cible et les contenus, et par conséquent aux premières réflexions sur l’accessibilité des contenus du futur site.

• Rédaction du cahier des charges

Les critères de succès et tests du RGAA doivent être mentionnés, signalés et expliqués (en annexant le RGAA par exemple) de façon à :

• formaliser les exigences,
• mesurer les implications techniques,
• communiquer les règles aux maîtrises d’oeuvre,
• faciliter les recettes aux différents stades de production du site.

• Ergonomie et design

Cette étape consiste à définir, à partir de l’architecture :
ol’ergonomie générale du site internet : les différentes rubriques du site, les principes de navigation, l’organisation des contenus, L’ergonomie générale du site est souvent validée par l’intermédiaire de prototypes semi-fonctionnels (story-boards, wireframes…). Le RGAA doit servir à valider ces prototypes en matière d’accessibilité
ole design du site : la charte graphique, les codes couleurs, les polices de caractères utilisées, le logo, etc… Le RGAA peut servir à valider les maquettes graphiques sur le plan des contrastes, de la présence d’éléments fondamentaux, etc…

• Intégration (production de gabarits)

Cette étape est essentiellement pratiquée dans le cas général où le site sera développé sur la base d’un CMS (système de gestion de contenus). Il s’agit de réaliser l’intégration des principaux modèles de pages du site. Le RGAA doit servir à vérifier l’accessibilité des gabarits produits, notamment en termes de conformité et de fonctionnement dans divers outils de restitution. Il peut également servir de guide pour les intégrateurs, ou encore de support de formation pour ces mêmes publics.

• Développement du site

Cette étape consiste à développer l’ensemble des fonctionnalités du site internet. Le RGAA doit servir à contrôler le site en cours de développement.

• Intégration des contenus

Il s’agit soit pour le maître d’ouvrage, soit pour le maître d’oeuvre de saisir les contenus du futur site Internet. Le RGAA peut servir à former les contributeurs, et également à les guider dans leur saisie.

• Tests / Recette

Cette étape consiste à tester l’ensemble des fonctionnalités du site internet mais également de tester les aspects « techniques » du site : résistance à la montée en charge, compatibilité avec les différents supports et navigateurs, temps de chargement, etc…
Lors de cette étape, les tests de conformités du RGAA vont permettre de contrôler le niveau d’accessibilité du site, en vue notamment d’améliorations, mais également en vue de la réalisation de l’attestation de conformité.
·Cas spécifique 1 :
Le RGAA doit servir aux créateurs d’une application en ligne (CMS, ERP web, etc..) à valider et à améliorer les pages produites par leur application. Ces créateurs d’application auront intérêt à respecter les standards internationaux concernant les outils de production de contenu (ATAG – Authoring Tools Accessibility Guidelines) produits par la Web Accessibility Initiative au W3C.

Retourner en haut de la page

5.2.2 Amélioration d’un site

Dans certains cas, la refonte totale d’un site n’est pas pertinente ou possible immédiatement. Certains acteurs publics ont en effet des budgets limités, et il arrive également qu’une refonte importante dure plusieurs mois, voire années. Quelquefois une refonte va donc nécessiter un délai tel que des actions devront absolument être menées en parallèle sur l’accessibilité des contenus de la version du site en production. Dans ce cas, puisqu’il est trop tard pour tenir compte des règles d’accessibilité pendant la production, il faudra travailler sur des défauts d’accessibilité des contenus en production. Ces défauts peuvent être dus à différentes causes, dont voici les plus fréquentes :

• Ergonomie et architecture de l’information
  • manque de pages d’éléments pertinents pour l’accessibilité,
  • défauts d’architecture ou de navigation.
• Design
  • contrastes insuffisants,
  • technologies traitées de manière inaccessible à la création (flash, JS, Ajax…).
• Technique
  • système de gestion de contenus difficile à utiliser pour produire des contenus accessibles,
  • Gabarits de pages non conformes ou non compatibles avec certains outils ou navigateurs,
  • Encapsulation de solutions externes non accessibles.
• Contenus
  • affichage de contenus syndiqués non accessibles,
  • gestion d’une quantité importante de contenus et de pages,
  • gestion de contenus multimédia en quantité importante,
  • difficultés sur les processus transactionnels (téléprocédures, par exemple).

Dans tous ces cas présentés ci-dessus, le RGAA devra servir à vérifier à améliorer progressivement la conformité des contenus et des services proposés. La méthodologie proposée est la suivante :

1. Vérification de conformité sur tout ou partie des contenus concernés et détermination des points défaillants en listant les défauts présents sur les contenus en production ;
2. Classement des points défaillants par ordre de priorité et de criticité : par exemple, un défaut sur un processus transactionnel sera plus critique qu’un défaut sur un article ;
3. Détermination de la charge associée à chaque point défaillant : certains points peuvent être traités en interne, d’autres impliquent un prestataire, d’autres un partenaire. Dans tous les cas, la charge doit être évaluée ;
4. Arbitrage de faisabilité : au vu de la charge, certains défauts peuvent ou doivent (points critiques) être traités, d’autres mobiliseraient un temps ou une charge de travail susceptible de provoquer de la surqualité (cette notion de surqualité ne devrait pas concerner les points critiques) ;
5. Planification et réalisation des améliorations : la résolution des problèmes nécessite d’identifier l’interlocuteur, de prévoir et de réaliser les améliorations ;
6. Vérification de conformité des points traités : la vérification peut avoir lieu en cours d’amélioration ou en fin de processus ;
7. Retour à l’étape 1.

Pour faciliter l’utilisation du RGAA dans un contexte d’amélioration progressive d’un site existant (et non dans le cas d’une refonte), la première version du RGAA proposait un classement des tests par année de déploiement. Ce classement en années N, N+1, N+2 n’a pas été repris dans la version actuelle du RGAA, chaque scénario de mise en accessibilité étant spécifique à chaque projet. En revanche, il est toujours possible pour un administrateur qui se trouve dans l’impossibilité de refondre directement son site, de procéder de manière progressive.
Pour ceci, l’administrateur du service en ligne peut utiliser les classements de tests proposés dans le RGAA :

• Tests automatisables, semi-automatisables, manuels
• Niveau de difficulté facile, moyenne, ou difficile
• Niveau WCAG déduit A, AA ou AAA

Retourner en haut de la page

5.3 Accessibilité totale et surqualité

Les standards WCAG 2.0 sont des recommandations. Ils contiennent notamment un certain nombre de règles techniques très précises qui peuvent être déployées facilement et même quelquefois être testées automatiquement. Ils contiennent par ailleurs des recommandations d’ordre général, bien plus difficiles à déployer et à vérifier, eu égard à leur caractère subjectif. C’est par exemple le cas des recommandations de pertinence, dont la vérification de conformité est fortement dépendante de l’observateur.

Ces deux types de recommandations doivent en théorie se déployer sur toutes les pages d’un site. En pratique, il est difficile et extrêmement chronophage de tester l’intégralité des contenus au regard de l’intégralité des règles WCAG 2.0. Outre les difficultés liées à la subjectivité du jugement de l’évaluateur, dans certains cas, la volonté de rendre un site totalement accessible sur l’intégralité de ses pages et pour l’intégralité des critères peut conduire à une débauche d’énergie qui peut s’avérer contre-productive.
Il va donc être nécessaire :

• de fixer des limites (analyser un échantillon de pages représentatives et non l’intégralité du site),
• d’effectuer des arbitrages (décider dans quel cas une amélioration s’avère trop lourde ou contre-productive,
• de planifier les opérations de façon à faire de l’accessibilité une démarche d’amélioration continue.

Il est utile de rappeler que l’accessibilité absolue n’est pas forcément une attente immédiate des personnes handicapées. La première attente fondamentale est que les contenus des sites publics soient accessibles. Pour résumer, de nombreuses personnes handicapées préféreraient que 100% des sites soient accessibles à 80%, plutôt que 20% des sites publics soient accessibles à 100%.

Retourner en haut de la page

5.4 Attestation de conformité

5.4.1 Principe

L’ « attestation de conformité » est l'étape finale de la vérification de la conformité au RGAA ; elle est réalisée préalablement à la mise à disposition du service en ligne et correspond à un engagement sur l’honneur de satisfaire à l’ensemble des tests (sauf dérogation dûment justifiée) ayant un niveau WCAG déduit A et AA dans la version du RGAA en vigueur.

Elle peut donc comporter des écarts en nombre limité au regard des tests du RGAA. Dans certains cas, l'administrateur du site sera dans l'impossibilité matérielle de mettre en oeuvre une partie des critères. Il sera alors possible de signaler les contenus correspondant comme non-accessibles.
En tout état de cause, les écarts devront être justifiés et expliqués suivant le principe de la dérogation (cf. 8.5).

La mise en oeuvre de ce principe de dérogation ne remet pas en question l’objectif de conformité totale aux tests du RGAA, mais elle permet aux administrateurs :

• de démontrer les avancées de leur démarche de mise en conformité,
• de signaler les futures améliorations du site,
• de montrer aux utilisateurs que les problèmes sont connus et anticipés,
• de faire remonter au Ministère chargé des personnes handicapées les problèmes de mise en oeuvre sur le terrain,
• de faciliter l'ajustement ou la mise en oeuvre des actions de formation, de sensibilisation ou de mise à disposition d'outils.

Retourner en haut de la page

5.4.2 Contenu de l’attestation

L’attestation de conformité porte au minimum sur la liste de pages suivantes du site, lorsqu’elles existent :

• Page d'accueil (page constituant le point d'entrée principale du service de communication publique en ligne elle est généralement accessible par une adresse de la forme http://www.urldusite.extension )
• Page contact (page contenant les informations de contact ou le ou les formulaires permettant de contacter directement le ou les responsables du service de communication publique en ligne)
• Page mentions légales
• Page politique d'accessibilité : outre les informations relatives à l’évolution globale de l’accessibilité du site, cette page contiendra les renseignements relatifs à l’attestation de conformité dont la liste des pages ou secteurs du service dérogeant aux exigences d’accessibilité, leur type de contenu et les solutions alternatives pour y accéder.
• Page aide (page contenant les informations facilitant l'utilisation du site, raccourcis claviers, éventuels, logiciels/plug-in nécessaires à la consultation du site)
• Page plan du site (page récapitulant l'arborescence du site ou permettant plus largement une navigation au sein des différentes pages composant le services de communication publique en ligne)
• Page recherche (page dont l'objet principal est la mise à disposition d'un formulaire de recherche ou des résultats d'une recherche)
• Toutes les pages composant le processus d'un service en ligne (un formulaire ou une transaction sur plusieurs pages)

S'ajoute à ces pages impératives un certain nombre de pages dans la liste suivante :

• Pages d'accès aux contenus ou fonctionnalités principaux (ex : rubriques de 1er niveau dans l'arborescence ou page représentative de la nature
• Pages représentatives des types de contenus disponibles sur le site (ex. : page contenant des tableaux de données, des éléments multimédia, des illustrations, des formulaires, etc.)
• Pages ayant le plus grand nombre de visiteurs

Le choix exact des pages dans cette liste complémentaire et leur nombre nécessitent une appréciation humaine. Cette appréciation dépend des contenus et services, et de la capacité à mettre en oeuvre le RGAA, dans votre environnement technique, en fonction de vos compétences et de vos ressources.
Elle fait la distinction entre :

• les contenus pour lesquels le service s’engage dès maintenant sur leur accessibilité,
• les contenus pour lesquels le service s’engage sur un calendrier de travail,
• les raisons pour lesquelles certains tests ou certains contenus ne sont pas accessibles doivent être justifiées par l’administrateur du site dans son attestation.

Le RGAA ne fournit pas de format spécifique pour l’attestation de conformité mais précise les informations minimums à faire figurer :

• date de réalisation,
• version du RGAA de référence,
• nom et adresse email du déclarant,
• technologies utilisées sur le site,
• liste des agents utilisateurs et technologies d’assistance utilisées pour vérifier l’accessibilité des contenus,
• liste des pages du site ayant fait l’objet de la vérification de conformité,
• résultat des tests et justification des dérogations.

Retourner en haut de la page

5.4.3 Qui vérifie la conformité ?

Il faut distinguer la vérification effectuée par le créateur du contenu Web et qui peut être effectuée tout au long de la mise en oeuvre des contenus de la vérification effectuée par l’administration sur la base ou non d’une attestation de conformité et dont l’objectif est de contrôler le respect du RGAA.

Selon le décret n° 2009-546 du 14 mai 2009, la vérification de la conformité au RGAA est assurée par le ministère chargé des personnes handicapées, qui mettra en oeuvre d’ici la fin 2010 un dispositif de veille et de contrôle. C’est ce principe de vérification qui est décrit ici. C’est également ce principe qui peut être retenu pour vérifier le site lors de sa production ou dans le cadre d’une démarche d’amélioration d’un site existant.

Retourner en haut de la page 

5.4.4 Que vérifie-t-on ?

Il est le plus souvent impossible de vérifier l’intégralité des critères du RGAA sur l’intégralité des pages d’un site (qu’il vienne d’être refondu ou qu’il soit en cours d’amélioration). C’est pourquoi l’administrateur du site va devoir déterminer un échantillon de pages représentatives dont certaines seront obligatoires au regard de l’attestation de conformité (cf 5.5.2). La taille de cet échantillon peut varier suivant le nombre de pages, les contenus proposés, le nombre de formulaires, les processus transactionnels, etc…
L’administrateur de site aura intérêt à choisir un échantillon de pages le plus étendu et le plus représentatif possible, tout en veillant à ne pas provoquer une masse de travail exagérée pour la vérification.

Retourner en haut de la page

5.4.5 Comment vérifie-t-on ?

Les actions à effectuer par le responsable de la vérification de la conformité au RGAA sont :

• Identification des pages composant l’échantillon : ce choix relèvera le plus souvent de décisions locales eu égard à la disparité des contextes et donc de la politique d’accessibilité définie. L’échantillon contient au minimum l’ensemble des pages obligatoires

• Réalisation des tests sur chacune des pages de l’échantillon :
  • A partir du code source : bien que cela représente un travail fastidieux, il est techniquement possible de réaliser une grande partie des tests de l’annexe 2 en contrôlant le code source du contenu Web dont on souhaite mesurer la conformité au RGAA.
  • A l’aide d’outils: pour faciliter la réalisation des tests de l’annexe 2, des travaux sont actuellement en cours pour mettre à disposition un outil permettant d’automatiser une partie des tests de l’annexe 2 et de se comporter comme un aide à la réalisation pour les tests non automatisables.
    Les modalités d’accès et d’utilisation seront définies par les services du ministre chargé des personnes handicapées.

Retourner en haut de la page

5.4.6 Mise en ligne de l’attestation

L’attestation sera accessible sur le service de communication publique en ligne via une page dédiée ou au sein d'une autre page (aide/politique d'accessibilité/mention légale). Cette page devrait être accessible depuis n'importe quelle autre page du service de communication publique en ligne.

Retourner en haut de la page

5.4.7 Validité de l'attestation

L’attestation de conformité est considérée comme valide pour la version en cours du RGAA à la date de sa mise en ligne. Dès qu’une nouvelle version du RGAA sera publiée, l’attestation liée à une version antérieure du RGAA ne sera plus valide.
Il est à noter toutefois qu'une attestation de conformité pour être mises à jour à plusieurs reprises pour un même site et une même version du RGAA, afin de mettre en évidence les efforts de mise en accessibilité et de mettre à jour le niveau atteint.

Retourner en haut de la page

5.5 Dérogations au principe d’accessibilité totale d’un site

Dans certains cas, le responsable du service de communication publique en ligne peut être dans l’incapacité de mettre en oeuvre tout ou partie du RGAA. Il est alors nécessaire de définir les choix et priorités de mise en oeuvre et de les consigner dans un document de politique d’accessibilité.
Les principales raisons pouvant conduire à déroger au principe d’accessibilité total du site sont notamment :

• un volume trop important : le nombre de pages concernées par la mise en accessibilité est tel qu'une dérogation est inévitable pendant une durée définie permettant la mise en conformité totale.

Exemple : un service ayant mis en ligne des centaines ou des milliers de pages avant l'entrée en vigueur du RGAA et pour lesquelles la mise en accessibilité implique un travail anormalement conséquent et techniquement irréalisable dans les délais prévus au Référentiel.

• Une obsolescence des contenus : les contenus relevant de la mission de sauvegarde à titre patrimonial de l’internet par les acteurs publics désignés par la loi.

Exemple : un service proposant des archives de contenu. Voir notamment, concernant les archives, les articles 221-1 et suivants du Code du patrimoine, et concernant le dépôt légal, l’article L132-2-1 du Code du patrimoine, ajouté par l’article IV de la loi n°2006- 961 du 1er août 2006 sur le Droit d’auteur et les droits voisins dans la société de l’information, qui charge La Bibliothèque nationale de France (BNF) et l’Institut national de l’audiovisuel (INA) d’effectuer le dépôt légal des oeuvres sous forme numérique (http://www.legifrance.gouv.fr/WAspad/UnTexteDeJorf?numjo=MCCX0300082L)

• un contenu tierce partie : dans le cas d’un site hébergeant des forums publics, zones de commentaires publiques ou mettant en forme l’agrégation de différents contenus externes, le propriétaire du service de communication publique n’est pas l’auteur des contenus et ne peut donc pas avoir la garantie qu’il est et reste accessible en permanence.

Exemple : un wiki, un forum, l’espace collaboratif d’une communauté de pratiques

Dans tous ces cas :

• Les contenus non accessibles doivent être signalés à l'utilisateur pour qu'il soit informé de la proportion des pages concernées et de leur localisation dans les rubriques du site.
• Les dérogations en matière d’accessibilité doivent être expliquées et motivées dans le cadre de l’attestation de conformité
• Il est nécessaire de prévoir un canal permettant aux personnes handicapées ou qui détectent un problème dans ce domaine de pouvoir le signaler aux administrateurs du service en ligne.

De plus, il est important de rappeler qu’en vertu de l’article 11 de la loi de février 2005 « la personne handicapée a droit à la compensation des conséquences de son handicap quels que soient l’origine et la nature de sa déficience, son âge ou son mode de vie ». De ce fait, chaque organisme devra prendre les moyens nécessaires afin de donner accès aux informations recherchés par la personne handicapé.

Retourner en haut de la page

Télécharger la version PDF

RGAA-v2.2_GuideAccompagnement.pdf

RGAA_v2.2.1.pdf

RGAA-v2.2_Annexe1-Criteres.pdf

RGAA-v2.2_Annexe2-Tests.pdf

RGAA-v2.2_Annexe3-Grilles.pdf

Autour du RGAA