Le nouveau Modèle de charte d’accessibilité de service en ligne est disponible en téléchargement sur le Cloud.

Par cette charte, un Éditeur affirme son engagement à rendre accessible l’ensemble de ses services en ligne. Dans le cadre de cet engagement, l’Éditeur a élaboré et met actuellement en œuvre son schéma pluriannuel d’accessibilité. Cela inclut des efforts continus pour assurer la conformité de ses projets numériques. Cette déclaration d’accessibilité concerne spécifiquement le service en ligne accessible à partir du nom de domaine : ……………..  (ci-après « Le Site ». 

CHARTE D’ACCESSIBILITÉ DE SERVICE EN LIGNE

DÉCLARATION D’ACCESSIBILITÉ Version …. Date …. 

L’Éditeur affirme son engagement à rendre accessible l’ensemble de ses services en ligne. Dans le cadre de cet engagement, l’Éditeur a élaboré et met actuellement en œuvre son schéma pluriannuel d’accessibilité. Cela inclut des efforts continus pour assurer la conformité de ses projets numériques. Cette déclaration d’accessibilité concerne spécifiquement le service en ligne accessible à partir du nom de domaine : ……………..  (ci-après « Le Site ». 

État de conformité

Le Site atteint une conformité partielle avec le Référentiel Général d’Amélioration de l’Accessibilité (RGAA) version 1.0. Cette situation est due aux diverses non-conformités détaillées ci-après, dans la section « Résultats des tests ».

Résultats des tests

Un audit réalisé par la société ….  le …. a révélé une conformité initiale de 56,9% selon le RGAA version 1.0. Suite aux corrections préalables à la publication en ligne, ce taux a été amélioré pour atteindre 77,6%. L’audit a couvert un échantillon représentatif des pages du site, incluant :

• Recherches transversales et spécifiques 
• Fonctionnalités de recherche avancée
• Documentation

Contenus inaccessibles

Non-conformités

• Des scripts nécessitant des ajustements pour la navigation au clavier et la lecture écran.
• Des pages présentant un code source non valide, comme celles des mentions légales.
• Des difficultés d’utilisation du menu en raison de contenus s’affichant au survol.
• Des problèmes d’ordre de présentation et de tabulation sur certaines pages.
• Des formulaires avec des champs mal étiquetés et des boutons non explicites.

Dérogations

Contenu tiers

L’outil tiers permettant les retours d’utilisateurs n’est pas accessible aux personnes utilisant exclusivement le clavier ou des lecteurs d’écran.Charge disproportionnée

Des contenus anciens ou fournis par des tiers restent inaccessibles, notamment des archives PDF.

Technologies utilisées

• HTML5
• CSS
• JavaScript
• eZ Platform pour la gestion de contenu

Agents utilisateurs et technologies d’assistance

Les tests ont été effectués avec diverses combinaisons d’agents utilisateurs et de technologies d’assistance, notamment Firefox avec NVDA, Internet Explorer avec JAWS, et Safari avec VoiceOver.

Retour d’information et contact

L’Éditeur s’engage à fournir, sur demande, les informations et fonctionnalités recherchées par les personnes handicapées, dans un délai raisonnable. Les utilisateurs rencontrant des difficultés sont invités à nous contacter pour obtenir assistance et informations adaptées.

Voies de recours

Si vous rencontrez un défaut d’accessibilité non résolu malgré votre signalement, vous pouvez nous contacter via divers moyens : formulaire de contact, téléphone au ….. , ou par courrier (sans affranchissement) à l’adresse suivante :…. 

Référentiel Général d’Amélioration de l’Accessibilité (RGAA)

ARTICLE 1 : ENGAGEMENTS DE L’ÉDITEUR 

L’Éditeur s’engage sur l’Accessibilité numérique de ses services en ligne. 

Au sens des présentes, le handicap est défini comme toute limitation d’activité ou restriction de participation à la vie en société subie dans son environnement par une personne en raison d’une altération substantielle, durable ou définitive d’une ou plusieurs fonctions physiques, sensorielles, mentales, cognitives ou psychiques, d’un polyhandicap ou d’un trouble de santé invalidant (article L. 114 du code de l’action sociale et des familles).

L’accessibilité numérique consiste à rendre les services de communication au public en ligne accessibles aux personnes handicapées, c’est-à-dire :

Perceptibles : par exemple, faciliter la perception visuelle et auditive du contenu par l’utilisateur ; proposer des équivalents textuels à tout contenu non textuel ; créer un contenu qui puisse être présenté de différentes manières sans perte d’information ni de structure (par exemple avec une mise en page simplifiée) ;

Utilisables : par exemple, fournir à l’utilisateur des éléments d’orientation pour naviguer, trouver le contenu ; rendre toutes les fonctionnalités accessibles au clavier ; laisser à l’utilisateur suffisamment de temps pour lire et 

utiliser le contenu ; ne pas concevoir de contenu susceptible de provoquer des crises d’épilepsie ;

Compréhensibles : par exemple, faire en sorte que les pages fonctionnent de manière prévisible ; aider l’utilisateur à corriger les erreurs de saisie.

Robustes : par exemple, optimiser la compatibilité avec les utilisations actuelles et futures, y compris avec les technologies d’assistance.

Les services de communication au public en ligne sont définis comme toute mise à disposition du public ou de catégories de public, par un procédé de communication électronique, de signes, de signaux, d’écrits, d’images, de sons ou de messages de toute nature qui n’ont pas le caractère d’une correspondance privée (article 1er de la loi n° 2004-575 du 21 juin 2004 pour la confiance dans l’économie numérique). Conformément au II de l’article 47 de la loi du 11 février 2005 précitée, ils comprennent notamment :

les sites internet, intranet, extranet ; les progiciels, dès lors qu’ils constituent des applications utilisées au travers d’un navigateur web ou d’une application mobile ;

les applications mobiles qui sont définies comme tout logiciel d’application conçu et développé en vue d’être utilisé sur des appareils mobiles, tels que des téléphones intelligents (smartphones) et des tablettes, hors système d’exploitation ou matériel ;

le mobilier urbain numérique, pour leur partie applicative ou interactive, hors système d’exploitation ou matériel.

ARTICLE 2 : PÉRIMÈTRE DES ENGAGEMENTS 

L’Éditeur ne s’engage pas sur ses contenus exemptés : 

Les fichiers disponibles dans des formats bureautiques publiés avant le …. ;

Les contenus audio et vidéo préenregistrés, y compris ceux comprenant des composants interactifs, publiés avant le ….  ;

Les contenus audio et vidéo diffusés en direct, y compris ceux comprenant des composants interactifs ;

Les cartes et les services de cartographie en ligne, sous réserve que, s’agissant des cartes destinées à fournir une localisation ou un itinéraire, les informations essentielles soient fournies sous une forme numérique accessible ;

Les contenus de tiers qui ne sont ni financés ni développés par l’Éditeur et qui ne sont pas sous son contrôle ;

Les reproductions photographiques qui ne peuvent être rendues totalement accessibles en raison :

Soit de l’incompatibilité des exigences en matière d’accessibilité avec la préservation de la pièce concernée ou l’authenticité de la reproduction notamment en termes de contraste ;

Soit de l’indisponibilité de solutions automatisées et économiques qui permettraient de transcrire facilement le texte ou d’autres supports et de le restituer sous la forme d’un contenu compatible avec l’obligation d’accessibilité ;

Les contenus des intranets et des extranets publiés avant le … jusqu’à ce que ces sites fassent l’objet d’une révision en profondeur ;

Les contenus des sites internet et des applications mobiles qui ne présentent pas de valeur ajoutée, notamment les archives.

Norme de référence et niveau de conformité

L’Éditeur ne s’engage pas sur les exigences légales en matière d’accessibilité les services de communication au public en ligne visés par la norme européenne EN 301 549 V2.1.2 (2018-08).

L’Éditeur a fait le choix de se référer aux normes internationales en matière d’accessibilité numérique, ses  contenus et services web doivent en conséquence satisfaire aux critères de succès des Règles pour l’accessibilité des contenus Web (WCAG) 2.1 de niveau simple A (A) et double A (AA) telles que fixées en Annexe des présentes. 

Dérogation pour charge disproportionnée

Les engagements de l’Éditeur en matière d’accessibilité sont mises en œuvre dans la mesure où elles ne créent pas une charge disproportionnée pour lui. La charge disproportionnée est une dérogation invocable, au cas par cas, pour une fonctionnalité ou un contenu.

La charge disproportionnée peut être invoquée lorsqu’il est raisonnablement impossible à l’Éditeur de rendre un contenu ou une fonctionnalité accessible, notamment dans le cas où la mise en accessibilité compromettrait sa capacité à réaliser ses objectifs économiques.

Les contenus ou les fonctionnalités qui ne sont pas rendus accessibles en raison d’une dérogation pour charge disproportionnée sont accompagnés d’une alternative permettant à l’utilisateur d’accéder à des contenus ou fonctionnalités équivalentes, tant que la production de cette alternative ne constitue pas elle-même une charge disproportionnée.

Afin de déterminer l’existence d’une telle charge, l’Éditeur tient compte notamment des circonstances suivantes :

Sa taille, ses ressources et l’estimation des coûts et des avantages par rapport à l’avantage estimé pour les personnes handicapées, compte tenu de la fréquence et de la durée d’utilisation du service, ainsi que de l’importance du service rendu.

Sa taille est déterminée par la composition de son effectif, le nombre, la position et la répartition de ses usagers ou clients, l’importance, la diversité et le volume de ses activités et prestations, ainsi que l’étendue territoriale de ses interventions.

L’estimation des ressources tient compte :

De son budget,

Des redevances et rémunérations perçues,

Des subventions publiques ou dons privés, bénéfice et recettes diverses, dépenses obligatoires,

Masse salariale,

Emprunts et loyers.

L’estimation des coûts peut comprendre les dépenses d’investissement, les dépenses de fonctionnement et le temps de travail, les qualifications requises. L’absence de priorité, le manque de temps ou de connaissances ne constituent pas des circonstances légitimes.

La dérogation pour charge disproportionnée n’exempte pas l’Éditeur de produire une déclaration d’accessibilité. 

Les contenus et les fonctionnalités non accessibles à ce titre sont listés dans la déclaration d’accessibilité du service en ligne avec la justification de la dérogation, sa durée et l’indication, le cas échéant, d’une alternative accessible.

Les dispositions relatives à la lutte contre les discriminations s’appliquent aux situations individuelles et concrètes.

Lorsqu’une personne handicapée présente une demande d’aménagement de son poste à l’Éditeur, sa demande ne peut pas lui être refusée au motif qu’elle implique un niveau d’accessibilité supérieur à ce que préconise le présent référentiel. 

Les exemptions et délais de mise en conformité prévus ne s’appliquent pas aux demandes d’aménagement de poste par un Salarié de l’Éditeur. La procédure à suivre et les sanctions applicables relatives aux mesures d’aménagement raisonnable sont celles prévues par les dispositions propres à la lutte contre les discriminations.

ARTICLE 3 : ÉVALUATION DE LA CONFORMITÉ

Cadre général

Afin d’évaluer la conformité du service de communication au public en ligne avec la norme de référence, L’Éditeur a mis en place un audit d’accessibilité. L’audit (ou évaluation) peut être effectué par L’Éditeur lui-même (auto-évaluation) ou par un tiers. L’évaluation est réalisée sur un échantillon de pages représentatif du service de communication au public en ligne. La vérification de la conformité des pages de l’échantillon avec les critères applicables s’effectue à l’aide des critères de contrôle du RGAA qui contiennent des tests techniques. La phase finale de l’audit est la déclaration d’accessibilité qui rend compte de la conformité des services de communication au public en ligne avec les règles applicables.

L’audit (ou évaluation) répond aux critères suivants :

Il est fiable : il revient à L’Éditeur concerné de veiller à la fiabilité de sa déclaration par tous moyens (recours à un prestataire externe, formation d’experts internes, audits croisés…) ;

Il est représentatif : il porte sur un échantillon représentatif des pages du service de communication au public en ligne (cf. section « Échantillon » ci-dessous).

L’Éditeur peut recourir à une autre méthode de tests, à une triple condition :

S’assurer que la méthode de test utilisée est communicable sur demande à un utilisateur ;

Produire une table de correspondance explicite entre les critères et tests et la norme de référence choisie ;

L’indiquer dans la déclaration d’accessibilité.

Échantillon

L’échantillon sur lequel est réalisé l’audit porte au moins sur les pages suivantes, lorsqu’elles existent :

Page d’accueil (page constituant le point d’entrée principal du service de communication au public en ligne),

Page contact (page contenant les informations de contact ou le ou les formulaires permettant de contacter directement L’Éditeur responsable du service de communication au public en ligne),

Page mentions légales,

Page « accessibilité » (page comprenant la déclaration d’accessibilité),

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 service),

Page d’aide,

Page d’authentification.

S’ajoutent à ces pages, les pages suivantes, lorsqu’elles existent :

Au moins une page pertinente pour chaque type de service fourni et toute autre utilisation principale prévue (ex. : rubriques de 1er niveau dans l’arborescence…), y compris la fonctionnalité de recherche ;

Au moins un document téléchargeable pertinent, le cas échéant, pour chaque type de service fourni et pour toute autre utilisation principalement prévue ;

L’ensemble des pages constituant un processus (par exemple, un formulaire de saisie ou une transaction sur plusieurs pages) ;

Des exemples de pages ayant un aspect sensiblement distinct ou présentant un type de contenu différent (ex. : page contenant des tableaux de données, des éléments multimédias, des illustrations, des formulaires, etc.).

La sélection des pages auditées ainsi que leur nombre doivent être représentatifs du service de communication au public en ligne. Le nombre de visiteurs par page peut notamment être pris en compte lors de la constitution de l’échantillon.

Enfin, s’ajoutent des pages sélectionnées au hasard représentant au moins 10 % des pages de l’échantillon décrit supra.

Sont considérées comme des pages au titre du présent référentiel les pages web et les écrans des applications mobiles.

Environnement de test (ou « base de référence »)

Quelques critères RGAA, notamment ceux de la thématique JavaScript, incluent des tests de restitution à effectuer sur des technologies d’assistance associées à des navigateurs et des systèmes d’exploitation.

Pour valider ces critères, il convient de définir un environnement de test (ou « base de référence »). 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.

Lorsqu’il est possible de connaître la configuration des postes de travail, ainsi que le matériel utilisé, la base de référence est alors constituée des services réellement utilisés dans cet environnement.

Test des pages

Chaque page de l’échantillon doit être vérifiée au regard des critères qui lui sont applicables.

Il existe 3 raisons pour qu’un critère ne soit pas applicable à une page :

Le critère concerne un contenu ou une fonctionnalité qui n’existe pas, par exemple si la page ne comporte pas de vidéo, les critères liés aux vidéos ne seront pas applicables.

Le critère concerne un contenu ou un service exempté qui n’est donc pas soumis à l’obligation d’accessibilité.

Le critère concerne un contenu soumis à dérogation pour charge disproportionnée qui est accompagné d’une alternative numérique accessible. Par exemple, un tableau statistique avec des graphiques qui propose une alternative numérique en texte. Dans ce cas les critères applicables au contenu soumis à dérogation seront non applicables. À noter : si le contenu soumis à dérogation pour charge disproportionnée ne propose pas d’alternative numérique accessible, les critères concernant ce contenu sont considérés comme applicables.

Les pages sont ensuite testées au regard des critères applicables. Ces tests permettent d’obtenir :

Le nombre de critères validés et non validés pour chaque page ;

Le taux de conformité de chaque page.

À noter :

Un critère est validé pour une page donnée lorsque tous les éléments de la page ont passé avec succès les tests permettant de valider le critère ;

Dès lors qu’un seul élément de la page ne valide pas les tests d’un critère, le critère ne peut être validé ;

Si la page fait partie d’un processus (faire une déclaration, participer à une consultation, prendre un rendez-vous), un critère est validé pour une page du processus uniquement s’il est validé pour toutes les pages du processus.

Taux de conformité à la norme

Le taux de conformité permet de mesurer les progrès du service en ligne eu égard à la conformité aux exigences d’accessibilité.

Ce taux peut indiquer le pourcentage de critères respectés ou le niveau de conformité moyen du service en ligne.

Le pourcentage de critères RGAA respectés s’obtient en divisant le nombre de critères validés par le nombre de critères applicables.

Critère validé : un critère est validé s’il est validé sur toutes les pages de l’échantillon. Si un critère est invalidé sur une seule page de l’échantillon, il ne pourra pas être considéré comme valide pour le calcul du taux.

Critère applicable : pour qu’un critère soit applicable, il suffit qu’il le soit sur une seule page de l’échantillon. Ce qui a pour corollaire qu’un critère est non applicable s’il est non applicable sur toutes les pages de l’échantillon sans exception.

Le taux de moyen de conformité du service en ligne s’obtient en faisant la moyenne des taux de conformité de chaque page.

ARTICLE 4 : DÉCLARATION D’ACCESSIBILITÉ 

L’Éditeur publie régulièrement une Déclaration d’accessibilité. 

La déclaration d’accessibilité est le résultat d’une évaluation effective de la conformité du service de communication au public en ligne à la norme de référence.

La déclaration d’accessibilité comprend :

Un état de conformité :

Conformité totale : si tous les critères de contrôle du RGAA sont respectés ;

Conformité partielle : si au moins 50 % des critères de contrôle du RGAA sont respectés ;

Non-conformité : s’il n’existe aucun résultat d’audit en cours de validité permettant de mesurer le respect des critères ou si moins de 50 % des critères de contrôle du RGAA sont respectés ;

Un signalement des contenus non accessibles, distingués selon qu’il s’agit de non-conformité avec le RGAA, de contenus exemptés ou de contenus soumis à dérogation pour charge disproportionnée. Dans ce dernier cas, les dérogations doivent être expliquées et motivées. Le signalement est assorti, le cas échéant, d’une présentation des alternatives accessibles prévues ;

Des dispositifs d’assistance et de contact :

Un mécanisme accessible (adresse électronique ou formulaire) pour permettre à toute personne de signaler à L’Éditeur tout défaut d’accessibilité et à une personne handicapée de demander les informations correspondantes ou une solution alternative accessible ;

La mention de la faculté pour la personne concernée de saisir un service de médiation, en cas d’absence de réponse ou de solution, une fois les démarches effectuées via le mécanisme mentionné ci-dessus.

Validité de la déclaration d’accessibilité

La déclaration d’accessibilité est valide à partir de sa date de publication. Elle doit être mise à jour :

A la date de modification substantielle ou de refonte du site concerné.

3 ans après la date de publication de la déclaration, ou, 18 mois après la date de publication d’une nouvelle version du référentiel, pour les personnes qui appliquent la méthode technique.

L’Éditeur peut mettre à jour plus régulièrement la déclaration d’accessibilité, y compris pour une même version de la méthode technique, afin de souligner les efforts réalisés et de mettre à jour le pourcentage de critères respectés.

Publication de la déclaration d’accessibilité

La déclaration d’accessibilité est publiée sur internet dans un format accessible.

Pour les sites internet, la déclaration d’accessibilité est publiée sur le site internet concerné. Elle est mise à disposition au sein d’une page accessibilité, directement accessible depuis la page d’accueil et depuis n’importe quelle page du site.

Pour les applications mobiles, elle est disponible sur le site internet de L’Éditeur qui a développé l’application ou apparaît avec d’autres informations disponibles lors du téléchargement de l’application. L’état de conformité est précisé au sein de l’application.

Pour les autres services de communication au public en ligne, elle est disponible sur le site internet des organismes responsables de leur gestion ou de leur mise à disposition.

Réponse aux usagers

L’Éditeur fournit en ligne aux utilisateurs la possibilité de faire des réclamations relatives à l’accessibilité de ses services de communication au public en ligne. Il accuse réception de ces réclamations.

L’Éditeur répond à toute réclamation dans un délai d’une semaine à compter de sa date d’envoi. Si la réclamation de l’utilisateur soulève une ou plusieurs questions complexes justifiant un délai d’examen plus long, la réponse indique un délai raisonnable pour la réponse définitive. Le caractère complexe des questions soulevées doit être motivé.

L’utilisateur doit s’identifier dans sa réclamation en suivant les prescriptions données par l’Éditeur. 

Si les informations transmises par l’utilisateur dans sa réclamation sont incomplètes ou ne sont pas suffisamment claires, L’Éditeur lui demande de les compléter ou de les clarifier et lui communique le délai raisonnable de traitement ou sa réponse définitive après réception des compléments demandés.

La déclaration d’accessibilité adopte obligatoirement ce format :

[Nom de L’Éditeur] s’engage à rendre [son (ses) site(s) internet, intranet, extranet et son (ses) application(s) mobile(s), etc.] accessibles conformément à sa charte d’accessibilité. 

À cette fin, il met en œuvre la stratégie et les actions suivantes [liens vers le schéma pluriannuel et vers le plan d’action de l’année en cours incluant le bilan des actions réalisées l’année précédente].

Cette déclaration d’accessibilité s’applique à [Nom du site web de l’application mobile, ou d’un autre service auquel la déclaration s’applique].

État de conformité

[Nom du site web, de l’application mobile, ou d’un autre service concerné] est

[totalement / partiellement / non] conforme avec [pour les sites : le référentiel général d’amélioration de l’accessibilité / autre protocole de test utilisé ; pour les autres services de communication : protocole de test utilisé].

Résultat des tests

L’audit de conformité réalisé [en interne / par la société NNN] révèle que :

[pourcentage de critères RGAA respectés] des critères RGAA sont respectés.

[Facultatif] Le taux moyen de conformité du service en ligne s’élève à [taux moyen de conformité du service en ligne].

[Détailler ici les résultats des tests ou insérer un lien vers le rapport de test]

Contenus non accessibles

Les contenus listés ci-dessous ne sont pas accessibles pour les raisons suivantes.

Non conformité

[Lister la/les non-conformité(s) du/de la/des site(s) internet/application(s) mobile(s) et/ou décrire quels section(s)/contenu(s)/fonction(s) ne sont pas encore conformes, indiquer les alternatives s’il y a lieu].

Dérogations pour charge disproportionnée

[Lister la/le/les section(s)/contenu(s)/fonction(s) non accessible(s) pour laquelle/lequel/lesquels la dérogation pour charge disproportionnée est temporairement invoquée, indiquer les alternatives s’il y a lieu].

Contenus non soumis à l’obligation d’accessibilité

[Lister la/le/les section(s)/contenu(s)/fonction(s) non accessible(s) qui n’entre(nt) pas dans le champ d’application de la législation applicable, indiquer les alternatives s’il y a lieu].

Établissement de cette déclaration d’accessibilité

Cette déclaration a été établie le [JJ mois AAAA]. Elle a été mise à jour le [JJ mois AAAA].

Technologies utilisées pour la réalisation [Du site web / De l’application mobile / Du service…]

[Liste des technologies utilisées]

Environnement de test

Agents utilisateurs, technologies d’assistance et outils utilisés pour vérifier l’accessibilité

[Indiquer les combinaisons utilisées pour effectuer les vérifications de conformité]

Les outils utilisés lors de l’évaluation

[Indiquer les outils utilisés]

Pages du site ayant fait l’objet de la vérification de conformité

[Indiquer la liste des pages qui ont été testées]

Retour d’information et contact

Si vous n’arrivez pas à accéder à un contenu ou à un service, vous pouvez contacter le responsable du [site internet / application mobile / Autre service] pour être orienté vers une alternative accessible ou obtenir le contenu sous une autre forme.

Envoyer un message [url du formulaire en ligne]

Contacter [Nom de l’entité responsable du service en ligne] [url d’une page avec les coordonnées de l’entité]

Voies de recours

Cette procédure est à utiliser dans le cas suivant.

Vous avez signalé au responsable du site internet un défaut d’accessibilité qui vous empêche d’accéder à un contenu ou à un des services de l’Éditeur et vous n’avez pas obtenu de réponse satisfaisante.

ANNEXES 

NORMES ET SPÉCIFICATIONS D’ACCESSIBILITÉ

La méthode technique du RGAA permet de vérifier qu’une page web – c’est-à-dire tout contenu HTML (HTML4, XHTML1 et HTML5) – est conforme aux 50 critères de succès des niveaux A et AA de la norme internationale WCAG 2.1 qui ont été retenus dans la norme européenne de référence (.pdf 2Mo) pour établir le niveau d’exigence légale en matière d’accessibilité numérique.

La méthode technique du RGAA propose un cadre opérationnel de vérification de la conformité aux exigences d’accessibilité.

Elle comporte 106 critères de contrôle RGAA incluant une moyenne de 2,5 tests par critère. Certains tests font référence à des techniques d’implémentation (HTML, CSS, JavaScript…) pour vérifier que le critère est respecté afin de réduire la marge d’interprétation quant au respect des normes d’accessibilité.

En cas d’absence de mise à jour du référentiel sous 3 ans pour prendre en compte de nouveaux standards ou spécifications techniques, il est possible de créer ses propres tests en complément de ceux existants.

Certains tests, concernant notamment les composants d’interface développés en JavaScript, requièrent de vérifier la restitution des contenus avec des technologies d’assistance associées à des navigateurs et des systèmes d’exploitation. L’environnement de test (ou « Base de référence ») est décrit dans la partie 2.4.

À noter que la méthode technique du RGAA 4.1 ne couvre pas les applications mobiles natives, les progiciels et le mobilier urbain numérique pour lesquels il sera nécessaire de vérifier directement la mise en œuvre de la norme de référence EN 301-549 V2.1.2 (.pdf 2Mo) notamment avec les parties :

• 5 Exigences génériques ;
• 6 TIC avec communication vocale bidirectionnelle ;
• 7 TIC avec capacités vidéo ;
• 8 Matériels ;
• 11 Logiciels.

Critères et tests 

1. Images 

1.1

Chaque image porteuse d’information a-t-elle une alternative textuelle ? 

Tests et références du critère 1.1

1.2

Chaque image de décoration est-elle correctement ignorée par les technologies d’assistance ? 

Tests et références du critère 1.2

1.3

Pour chaque image porteuse d’information ayant une alternative textuelle, cette alternative est-elle pertinente (hors cas particuliers) ? 

Tests et références du critère 1.3

1.4

Pour chaque image utilisée comme CAPTCHA ou comme image-test, ayant une alternative textuelle, cette alternative permet-elle d’identifier la nature et la fonction de l’image ? 

Tests et références du critère 1.4

1.5

Pour chaque image utilisée comme CAPTCHA, une solution d’accès alternatif au contenu ou à la fonction du CAPTCHA est-elle présente ? 

Tests et références du critère 1.5

1.6

Chaque image porteuse d’information a-t-elle, si nécessaire, une description détaillée ? 

Tests et références du critère 1.6

1.7

Pour chaque image porteuse d’information ayant une description détaillée, cette description est-elle pertinente ? 

Tests et références du critère 1.7

1.8

Chaque image texte porteuse d’information, en l’absence d’un mécanisme de remplacement, doit si possible être remplacée par du texte stylé. Cette règle est-elle respectée (hors cas particuliers) ? 

Tests et références du critère 1.8

1.9

Chaque légende d’image est-elle, si nécessaire, correctement reliée à l’image correspondante ? 

Tests et références du critère 1.9

Haut de page

2. Cadres 

2.1

Chaque cadre a-t-il un titre de cadre ? 

Tests et références du critère 2.1

2.2

Pour chaque cadre ayant un titre de cadre, ce titre de cadre est-il pertinent ? 

Tests et références du critère 2.2

Haut de page

3. Couleurs 

3.1

Dans chaque page web, l’information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ? 

Tests et références du critère 3.1

3.2

Dans chaque page web, le contraste entre la couleur du texte et la couleur de son arrière-plan est-il suffisamment élevé (hors cas particuliers) ? 

Tests et références du critère 3.2

3.3

Dans chaque page web, les couleurs utilisées dans les composants d’interface ou les éléments graphiques porteurs d’informations sont-elles suffisamment contrastées (hors cas particuliers) ? 

Tests et références du critère 3.3

Haut de page

4. Multimédia 

4.1

Chaque média temporel pré-enregistré a-t-il, si nécessaire, une transcription textuelle ou une audiodescription (hors cas particuliers) ? 

Tests et références du critère 4.1

4.2

Pour chaque média temporel pré-enregistré ayant une transcription textuelle ou une audiodescription synchronisée, celles-ci sont-elles pertinentes (hors cas particuliers) ? 

Tests et références du critère 4.2

4.3

Chaque média temporel synchronisé pré-enregistré a-t-il, si nécessaire, des sous-titres synchronisés (hors cas particuliers) ? 

Tests et références du critère 4.3

4.4

Pour chaque média temporel synchronisé pré-enregistré ayant des sous-titres synchronisés, ces sous-titres sont-ils pertinents ? 

Tests et références du critère 4.4

4.5

Chaque média temporel pré-enregistré a-t-il, si nécessaire, une audiodescription synchronisée (hors cas particuliers) ? 

Tests et références du critère 4.5

4.6

Pour chaque média temporel pré-enregistré ayant une audiodescription synchronisée, celle-ci est-elle pertinente ? 

Tests et références du critère 4.6

4.7

Chaque média temporel est-il clairement identifiable (hors cas particuliers) ? 

Tests et références du critère 4.7

4.8

Chaque média non temporel a-t-il, si nécessaire, une alternative (hors cas particuliers) ? 

Tests et références du critère 4.8

4.9

Pour chaque média non temporel ayant une alternative, cette alternative est-elle pertinente ? 

Tests et références du critère 4.9

4.10

Chaque son déclenché automatiquement est-il contrôlable par l’utilisateur ? 

Tests et références du critère 4.10

4.11

La consultation de chaque média temporel est-elle, si nécessaire, contrôlable par le clavier et tout dispositif de pointage ? 

Tests et références du critère 4.11

4.12

La consultation de chaque média non temporel est-elle contrôlable par le clavier et tout dispositif de pointage ? 

Tests et références du critère 4.12

4.13

Chaque média temporel et non temporel est-il compatible avec les technologies d’assistance (hors cas particuliers) ? 

Tests et références du critère 4.13

Haut de page

5. Tableaux 

5.1

Chaque tableau de données complexe a-t-il un résumé ? 

Tests et références du critère 5.1

5.2

Pour chaque tableau de données complexe ayant un résumé, celui-ci est-il pertinent ? 

Tests et références du critère 5.2

5.3

Pour chaque tableau de mise en forme, le contenu linéarisé reste-t-il compréhensible ? 

Tests et références du critère 5.3

5.4

Pour chaque tableau de données ayant un titre, le titre est-il correctement associé au tableau de données ? 

Tests et références du critère 5.4

5.5

Pour chaque tableau de données ayant un titre, celui-ci est-il pertinent ? 

Tests et références du critère 5.5

5.6

Pour chaque tableau de données, chaque en-tête de colonne et chaque en-tête de ligne sont-ils correctement déclarés ? 

Tests et références du critère 5.6

5.7

Pour chaque tableau de données, la technique appropriée permettant d’associer chaque cellule avec ses en-têtes est-elle utilisée (hors cas particuliers) ? 

Tests et références du critère 5.7

5.8

Chaque tableau de mise en forme ne doit pas utiliser d’éléments propres aux tableaux de données. Cette règle est-elle respectée ? 

Tests et références du critère 5.8

Haut de page

6. Liens 

6.1

Chaque lien est-il explicite (hors cas particuliers) ? 

Tests et références du critère 6.1

6.2

Dans chaque page web, chaque lien a-t-il un intitulé ? 

Tests et références du critère 6.2

Haut de page

7. Scripts 

7.1

Chaque script est-il, si nécessaire, compatible avec les technologies d’assistance ? 

Tests et références du critère 7.1

7.2

Pour chaque script ayant une alternative, cette alternative est-elle pertinente ? 

Tests et références du critère 7.2

7.3

Chaque script est-il contrôlable par le clavier et par tout dispositif de pointage (hors cas particuliers) ? 

Tests et références du critère 7.3

7.4

Pour chaque script qui initie un changement de contexte, l’utilisateur est-il averti ou en a-t-il le contrôle ? 

Tests et références du critère 7.4

7.5

Dans chaque page web, les messages de statut sont-ils correctement restitués par les technologies d’assistance ? 

Tests et références du critère 7.5

Haut de page

8. Éléments obligatoires 

8.1

Chaque page web est-elle définie par un type de document ? 

Tests et références du critère 8.1

8.2

Pour chaque page web, le code source généré est-il valide selon le type de document spécifié ? 

Tests et références du critère 8.2

8.3

Dans chaque page web, la langue par défaut est-elle présente ? 

Tests et références du critère 8.3

8.4

Pour chaque page web ayant une langue par défaut, le code de langue est-il pertinent ? 

Tests et références du critère 8.4

8.5

Chaque page web a-t-elle un titre de page ? 

Tests et références du critère 8.5

8.6

Pour chaque page web ayant un titre de page, ce titre est-il pertinent ? 

Tests et références du critère 8.6

8.7

Dans chaque page web, chaque changement de langue est-il indiqué dans le code source (hors cas particuliers) ? 

Tests et références du critère 8.7

8.8

Dans chaque page web, le code de langue de chaque changement de langue est-il valide et pertinent ? 

Tests et références du critère 8.8

8.9

Dans chaque page web, les balises ne doivent pas être utilisées uniquement à des fins de présentation. Cette règle est-elle respectée ? 

Tests et références du critère 8.9

8.10

Dans chaque page web, les changements du sens de lecture sont-ils signalés ? 

Tests et références du critère 8.10

Haut de page

9. Structuration de l’information 

9.1

Dans chaque page web, l’information est-elle structurée par l’utilisation appropriée de titres ? 

Tests et références du critère 9.1

9.2

Dans chaque page web, la structure du document est-elle cohérente (hors cas particuliers) ? 

Tests et références du critère 9.2

9.3

Dans chaque page web, chaque liste est-elle correctement structurée ? 

Tests et références du critère 9.3

9.4

Dans chaque page web, chaque citation est-elle correctement indiquée ? 

Tests et références du critère 9.4

Haut de page

10. Présentation de l’information 

10.1

Dans le site web, des feuilles de styles sont-elles utilisées pour contrôler la présentation de l’information ? 

Tests et références du critère 10.1

10.2

Dans chaque page web, le contenu visible porteur d’information reste-t-il présent lorsque les feuilles de styles sont désactivées ? 

Tests et références du critère 10.2

10.3

Dans chaque page web, l’information reste-t-elle compréhensible lorsque les feuilles de styles sont désactivées ? 

Tests et références du critère 10.3

10.4

Dans chaque page web, le texte reste-t-il lisible lorsque la taille des caractères est augmentée jusqu’à 200 %, au moins (hors cas particuliers) ? 

Tests et références du critère 10.4

10.5

Dans chaque page web, les déclarations CSS de couleurs de fond d’élément et de police sont-elles correctement utilisées ? 

Tests et références du critère 10.5

10.6

Dans chaque page web, chaque lien dont la nature n’est pas évidente est-il visible par rapport au texte environnant ? 

Tests et références du critère 10.6

10.7

Dans chaque page web, pour chaque élément recevant le focus, la prise de focus est-elle visible ? 

Tests et références du critère 10.7

10.8

Pour chaque page web, les contenus cachés ont-ils vocation à être ignorés par les technologies d’assistance ? 

Tests et références du critère 10.8

10.9

Dans chaque page web, l’information ne doit pas être donnée uniquement par la forme, taille ou position. Cette règle est-elle respectée ? 

Tests et références du critère 10.9

10.10

Dans chaque page web, l’information ne doit pas être donnée par la forme, taille ou position uniquement. Cette règle est-elle implémentée de façon pertinente ? 

Tests et références du critère 10.10

10.11

Pour chaque page web, les contenus peuvent-ils être présentés sans perte d’information ou de fonctionnalité et sans avoir recours soit à un défilement vertical pour une fenêtre ayant une hauteur de 256 px, soit à un défilement horizontal pour une fenêtre ayant une largeur de 320 px (hors cas particuliers) ? 

Tests et références du critère 10.11

10.12

Dans chaque page web, les propriétés d’espacement du texte peuvent-elles être redéfinies par l’utilisateur sans perte de contenu ou de fonctionnalité (hors cas particuliers) ? 

Tests et références du critère 10.12

10.13

Dans chaque page web, les contenus additionnels apparaissant à la prise de focus ou au survol d’un composant d’interface sont-ils contrôlables par l’utilisateur (hors cas particuliers) ? 

Tests et références du critère 10.13

10.14

Dans chaque page web, les contenus additionnels apparaissant via les styles CSS uniquement peuvent-ils être rendus visibles au clavier et par tout dispositif de pointage ? 

Tests et références du critère 10.14

Haut de page

11. Formulaires 

11.1

Chaque champ de formulaire a-t-il une étiquette ? 

Tests et références du critère 11.1

11.2

Chaque étiquette associée à un champ de formulaire est-elle pertinente (hors cas particuliers) ? 

Tests et références du critère 11.2

11.3

Dans chaque formulaire, chaque étiquette associée à un champ de formulaire ayant la même fonction et répétée plusieurs fois dans une même page ou dans un ensemble de pages est-elle cohérente ? 

Tests et références du critère 11.3

11.4

Dans chaque formulaire, chaque étiquette de champ et son champ associé sont-ils accolés (hors cas particuliers) ? 

Tests et références du critère 11.4

11.5

Dans chaque formulaire, les champs de même nature sont-ils regroupés, si nécessaire ? 

Tests et références du critère 11.5

11.6

Dans chaque formulaire, chaque regroupement de champs de même nature a-t-il une légende ? 

Tests et références du critère 11.6

11.7

Dans chaque formulaire, chaque légende associée à un regroupement de champs de même nature est-elle pertinente ? 

Tests et références du critère 11.7

11.8

Dans chaque formulaire, les items de même nature d’une liste de choix sont-ils regroupés de manière pertinente ? 

Tests et références du critère 11.8

11.9

Dans chaque formulaire, l’intitulé de chaque bouton est-il pertinent (hors cas particuliers) ? 

Tests et références du critère 11.9

11.10

Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente (hors cas particuliers) ? 

Tests et références du critère 11.10

11.11

Dans chaque formulaire, le contrôle de saisie est-il accompagné, si nécessaire, de suggestions facilitant la correction des erreurs de saisie ? 

Tests et références du critère 11.11

11.12

Pour chaque formulaire qui modifie ou supprime des données, ou qui transmet des réponses à un test ou à un examen, ou dont la validation a des conséquences financières ou juridiques, les données saisies peuvent-elles être modifiées, mises à jour ou récupérées par l’utilisateur ? 

Tests et références du critère 11.12

11.13

La finalité d’un champ de saisie peut-elle être déduite pour faciliter le remplissage automatique des champs avec les données de l’utilisateur ? 

Tests et références du critère 11.13

Haut de page

12. Navigation 

12.1

Chaque ensemble de pages dispose-t-il de deux systèmes de navigation différents, au moins (hors cas particuliers) ? 

Tests et références du critère 12.1

12.2

Dans chaque ensemble de pages, le menu et les barres de navigation sont-ils toujours à la même place (hors cas particuliers) ? 

Tests et références du critère 12.2

12.3

La page « plan du site » est-elle pertinente ? 

Tests et références du critère 12.3

12.4

Dans chaque ensemble de pages, la page « plan du site » est-elle accessible à partir d’une fonctionnalité identique ? 

Tests et références du critère 12.4

12.5

Dans chaque ensemble de pages, le moteur de recherche est-il atteignable de manière identique ? 

Tests et références du critère 12.5

12.6

Les zones de regroupement de contenus présentes dans plusieurs pages web (zones d’en-tête, de navigation principale, de contenu principal, de pied de page et de moteur de recherche) peuvent-elles être atteintes ou évitées ? 

Tests et références du critère 12.6

12.7

Dans chaque page web, un lien d’évitement ou d’accès rapide à la zone de contenu principal est-il présent (hors cas particuliers) ? 

Tests et références du critère 12.7

12.8

Dans chaque page web, l’ordre de tabulation est-il cohérent ? 

Tests et références du critère 12.8

12.9

Dans chaque page web, la navigation ne doit pas contenir de piège au clavier. Cette règle est-elle respectée ? 

Tests et références du critère 12.9

12.10

Dans chaque page web, les raccourcis clavier n’utilisant qu’une seule touche (lettre minuscule ou majuscule, ponctuation, chiffre ou symbole) sont-ils contrôlables par l’utilisateur ? 

Tests et références du critère 12.10

12.11

Dans chaque page web, les contenus additionnels apparaissant au survol, à la prise de focus ou à l’activation d’un composant d’interface sont-ils si nécessaire atteignables au clavier ? 

Tests et références du critère 12.11

Haut de page

13. Consultation 

13.1

Pour chaque page web, l’utilisateur a-t-il le contrôle de chaque limite de temps modifiant le contenu (hors cas particuliers) ? 

Tests et références du critère 13.1

13.2

Dans chaque page web, l’ouverture d’une nouvelle fenêtre ne doit pas être déclenchée sans action de l’utilisateur. Cette règle est-elle respectée ? 

Tests et références du critère 13.2

13.3

Dans chaque page web, chaque document bureautique en téléchargement possède-t-il, si nécessaire, une version accessible (hors cas particuliers) ? 

Tests et références du critère 13.3

13.4

Pour chaque document bureautique ayant une version accessible, cette version offre-t-elle la même information ? 

Tests et références du critère 13.4

13.5

Dans chaque page web, chaque contenu cryptique (art ASCII, émoticône, syntaxe cryptique) a-t-il une alternative ? 

Tests et références du critère 13.5

13.6

Dans chaque page web, pour chaque contenu cryptique (art ASCII, émoticône, syntaxe cryptique) ayant une alternative, cette alternative est-elle pertinente ? 

Tests et références du critère 13.6

13.7

Dans chaque page web, les changements brusques de luminosité ou les effets de flash sont-ils correctement utilisés ? 

Tests et références du critère 13.7

13.8

Dans chaque page web, chaque contenu en mouvement ou clignotant est-il contrôlable par l’utilisateur ? 

Tests et références du critère 13.8

13.9

Dans chaque page web, le contenu proposé est-il consultable quelle que soit l’orientation de l’écran (portrait ou paysage) (hors cas particuliers) ? 

Tests et références du critère 13.9

13.10

Dans chaque page web, les fonctionnalités utilisables ou disponibles au moyen d’un geste complexe peuvent-elles être également disponibles au moyen d’un geste simple (hors cas particuliers) ? 

Tests et références du critère 13.10

13.11

Dans chaque page web, les actions déclenchées au moyen d’un dispositif de pointage sur un point unique de l’écran peuvent-elles faire l’objet d’une annulation (hors cas particuliers) ? 

Tests et références du critère 13.11

13.12

Dans chaque page web, les fonctionnalités qui impliquent un mouvement de l’appareil ou vers l’appareil peuvent-elles être satisfaites de manière alternative (hors cas particuliers) ? 

Tests et références du critère 13.12

Environnement des tests

Environnement de test

Quelques critères RGAA, notamment ceux de la thématique JavaScript, incluent des tests de restitution à effectuer sur des technologies d’assistance associées à des navigateurs et des systèmes d’exploitation.

Les tests effectués selon ces combinaisons (technologie d’assistance, système d’exploitation, navigateur) permettent de déclarer qu’un dispositif HTML / WAI-ARIA est “compatible avec l’accessibilité” tel que défini par WCAG.

Les combinaisons ont été établies à 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.

Environnement de test Ordinateur (desktop)

Les systèmes d’exploitation retenus sont Windows et Mac OS X et les navigateurs, Internet Explorer, Firefox et Safari. Il appartient à l’auditeur de définir, en concertation avec les responsables du site audité, les versions de système d’exploitation et de navigateur en adéquation avec le contexte d’usage du site et l’environnement de test utilisé lors du développement du site. Les versions des technologies d’assistance à utiliser seront soit la dernière disponible en langue française sur le système d’exploitation retenu soit la version précédente.

Lorsque le site ou l’application est destinée à un public dont l’équipement est maîtrisé, les tests devront se faire sur un environnement de test adapté au contexte de l’environnement maîtrisé.

Pour qu’un dispositif HTML / WAI-ARIA ou son alternative soit considéré comme compatible avec l’accessibilité, il faut qu’il soit pleinement fonctionnel, en termes de restitution et de fonctionnalités, sur au moins une des combinaisons suivantes.

Environnement de test Ordinateur (desktop) – Combinaison 1

Environnement de test Ordinateur (desktop) – Combinaison 2

Environnement de test Terminal mobile

Les systèmes d’exploitation retenus sont Android et iOS et les navigateurs Chrome et Safari. Il appartient à l’auditeur de définir, en concertation avec les responsables du site audité, les versions de système d’exploitation et de navigateur en adéquation avec le contexte d’usage du site et l’environnement de test utilisé lors du développement du site.

Les versions des technologies d’assistance à utiliser seront soit la dernière disponible en langue française sur le système d’exploitation retenu, soit la version précédente.

Pour tester un site web sur un terminal mobile, l’environnement de test devra comporter une des deux combinaisons complémentaires suivantes :

Environnement de test Terminal mobile – Combinaison 1

Environnement de test Terminal mobile – Combinaison 2

À noter que dans le cas d’un site web mobile grand public, il est fortement conseillé de tester dans les deux environnements.

Autres environnements

Enfin, en fonction du contexte du site audité, d’autres technologies d’assistance complémentaires peuvent être utiles telles que :

• ZoomText sur Windows ou Mac OSX ;
• Dragon Naturally Speaking sur Windows ou Mac OSX.

Environnement maîtrisé

Lorsque le site web est destiné à être diffusé et utilisé dans un environnement maîtrisé, l’environnement de test (base de référence) doit être constitué 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. Cet environnement de test (base de référence) se substitue à l’environnement de test (base de référence) utilisé en environnement non maîtrisé.