Introduction
Vous avez sûrement déjà entendu parler d’accessibilité numérique. Cela peut être à travers des articles de la taverne, ce webinaire de 2023 ou toute autre source comme des conférences ou des articles de médias.
Au delà d’une importance de principe pour garantir un accès au plus grand nombre (dans un contexte aussi large que possible) au service numérique, le monde de l’accessibilité est structuré. La principale référence est le WCAG qui propose des règles priorisées.
Le WCAG est un référentiel reconnu internationalement… qui n’est évidemment pas contraignant.
Ce n’est pas le cas du RGAA pour Référentiel Général d’Amélioration de l’Accessibilité qui est une norme, très fortement inspiré du WCAG, obligatoire en France.
Obligations du RGAA
Champ d’application
Le RGAA s’applique pour les :
- les services publics
- les services de délégations de service public
- les services qui répondent à des besoins d’intérêt général
- les organisations avec un chiffre d’affaires supérieur ou égal à 250 millions d’euros
Les services en question sont:
- les services internes et externes qui sont utilisés avec un navigateur web (site internet, intranet, progiciels…)
- les applications mobiles
- le mobilier urbain (ex: l’interface des horodateurs)
Vous noterez que le public est évidemment visé mais aussi le privé. De même, les services externes (comme un site web public) est concerné mais aussi les services internes dédiés aux employés.
Obligations et pénalités
Le RGAA n’est pas une obligation d’accessibilité. Néanmoins elle s’accompagne d’un certain nombre d’obligations pour chaque service numérique elligible.
La principale est la publication d’une déclaration d’accessibilité qui indique si le service est:
- totalement conforme,
- partiellement (50%+ des critères)
- conforme ou non conforme.
Les autres obligations sont:
- Réaliser un audit d’accessibilité (pour avoir la déclaration)
- Afficher le taux de conformité
- Définir un schéma pluriannuel
- Définir un plan d’action annuel
Le non suivi des obligations donne lieu à une amende pouvant aller jusqu’à 25 000€ par service numérique tous les 6 mois.
Le contrôle est effectué par l’ARCOM, l’ARCEP ou la DINUM.
Comme vous le constater, les obligations tournent autour du respect de critères spécifiques du RGAA.
Structure du RGAA et de ses critères
Le but annoncé du RGAA est de proposer une méthode de vérification de conformité du service numérique aux 50 critères de succès des niveaux A et AA de la norme WCAG 2.1.
Le RGAA 4 comporte 106 critères, chaque critère incluant en moyenne 2,5 tests.
Les critères étant nombreux ils ont été organisés en « familles » comme pour l’ISO-25010, l’ISO-25019 ou encore le RGESN.
Les 106 critères sont répartis en 12 familles:
Ces familles sont:
- Les images : le principe est de s’assurer que les informations véhiculées par les images sont accessibles même pour des personnes ne pouvant pas le voir correctement. De même, les images sans information doivent être « cachées » pour ne pas alourdir la lisibilité du service.
- Les cadres : la présence et la cohérence de titres sur les différentes zones des pages web
- Les couleurs : la gestion des contrastes, le passage d’information qui ne dépend pas uniquement des couleurs. On pense tout de suite aux personnes souffrant de daltonisme… Mais quand on y réfléchit cela marche aussi lorsque l’on a du soleil sur son écran.
- Les multimédias : assurer que les informations contenus dans les médias soient accessibles de plusieurs manières (régler le volume, avoir des sous titres, des descriptions audio si nécessaire)…
- Les tableaux : s’assurer que les tableaux de données soient intelligibles (présence d’un résumé, lecture intelligible si lecteur d’écran…)
- Les liens : les liens sont-ils explicite et avec un intitulé ?
- Les scripts : s’assurer que les scripts sont compatibles avec les technologies d’assistance, contrôlables par clavier, que l’utilisateur les maitrise…
- Les éléments obligatoires : On est ici sur une liste d’informations générales apportant une information importante. Par exemple: la définition du type de la page, bonne définition de la langue utilisée, titre pertinent, changement de langue indiqué…
- La structuration de l’information : vérification de la hiérarchisation de l’information et des titres
- La présence de l’information : s’assurer l’accès à l’information. Notamment avec les éléments web sont définis et présentés correctement ou encore le zoom qui laisse l’information visible…
- Les formulaires : la lisibilité des formulaires, la capacité à bien identifier chaque champ de tout formulaire
- La navigation : s’assurer que l’on puisse naviguer et accéder correctement (avec une suite cohérente entre chaque tabulation) à toutes les fonctionnalités proposées par le service. Notamment sans l’utilisation d’une souris.
- La consultation : éviter les « ruptures » dans la navigation (web). Par exemple, en évitant d’ouvrir des onglets et fenêtre sans déclenchement explicite de l’utilisateur ou encore éviter les flashs et changements brusques de luminosité
Conclusion
L’accessibilité numérique est, au premier abord, assez complexe à comprendre. Les normes comme le WCAG ou le RGAA ne sont pas non plus très attirantes. Néanmoins, quand on prend le temps de s’y pencher il y a une logique et un intérêt derrière chaque critère.
De même, les critères d’accessibilités sont bénéfiques pour tout le monde, pas uniquement les personnes en situation de handicap.
Enfin, comme vous l’aurez noté, il y a assez peu de services numériques sur lesquels l’ensemble des 106 critères du RGAA sont applicables. Dans la pratique il y en a beaucoup moins. Seulement 52 critères sont applicables dans la taverne qui a entre 40 et 42 critères validés sur sa homepage (analyse faite avec l’outil CheckAccess). La différence se fait au niveau des liens et des images qui n’ont pas toujours de texte alternatifs :
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
5 réponses
Je trouve ta conclusion très orientée ; je ne suis pas d’accord que l’accessibilité numérique serait complexe à comprendre et que les normes seraient plutôt repoussantes (pas très attirantes. pour reprendre tes mots).
Notons que moins de 5 % des sites web sont conformes à l’accessibilité numérique, et que ce ratio est toujours le même depuis 25 ans !
Enfin, le champs d’application est nettement plus restrictif : les entreprises sont concernées pour leurs activités commerciales B2C à partir de 10 salariés et pour un CA annuel supérieur à 2 M€.
merci pour ce retour
Après avoir discuté et regardé les normes d’un peu plus près je vois que ce n’est pas forcément complexe. Néanmoins c’est un sujet inconnu pour beaucoup de personnes et un sujet assez technique. Cela demande de l’investissement si l’on veut vraiment bien faire les choses… Hors cet investissement est rarement disponible pour plusieurs raisons comme le manque d’intérêt (financier ou compréhension de l’apport) et d’autres priorités.
Pour le champ d’application j’ai repris ce qui est écrit sur la page du gouvernement: https://accessibilite.numerique.gouv.fr/obligations/champ-application/
Tout à fait d’accord, Marc.
D’autant que (pour une fois !) l’action du gouvernement s’est montrée efficace, en rédigeant le cahier de test complet des 106 critères, avec les outils, la méthodologie, les cas de test et les critères de succès/échec !
https://accessibilite.numerique.gouv.fr/methode/criteres-et-tests/
Petite précision, les critères d’exemption sont cumulatifs : moins de 10 salariés ET moins de 2 M€ de CA.
Une PME de 11 salariés, quel que soit son CA, (ou une PME de moins de 10 salariés mais dont le CA > 2M€), si ses services numériques s’adressent directement à des particuliers (notamment un site e-commerce, un service de transport ou un outil bancaire/financier), doit obligatoirement se mettre en conformité et sa plateforme doit respecter la norme européenne d’accessibilité (EN 301 549).
Ses 3 obligations majeures qui s’imposent sont :
– La conformité technique : Garantir que le site ou l’application est pleinement utilisable par une personne en situation de handicap (navigation au clavier, compatibilité avec les lecteurs d’écran pour les personnes aveugles, contrastes de couleurs suffisants).
– La publication d’une déclaration d’accessibilité : Le site/application doit être évalué (généralement via un audit) et publier une page légale « Déclaration d’accessibilité » affichant clairement votre taux de conformité.
– Le risque de sanctions financières : Les contrôles de la DGCCRF peuvent déboucher sur des amendes administratives (jusqu’à 7 500 € par manquement, cumulables) ainsi que sur des injonctions de mise en conformité sous astreinte
Bonjour
De mon point de vue le RGAA améliore l’expérience utilisateur, qu’on soit porteur d’une différence ou non. Toutefois il est dommage que malgré les sanctions trop peu d’organisations privées ne soient engagées réellement pour viser un taux élevé de conformité.
J’ai eu l’opportunité d’intervenir sur ce type de tests non fonctionnels et d’échanger avec des spécialistes, et je vous propose ces retours.
Mon premier retour est que sur un projet avec des développeurs formés et avec une évaluation rapide « bonne » on peut avoir des surprises et un taux de conformité en deçà de nos espérances quand on déroule un audit complet RGAA.
Le second est que c’est un type de tests avec certaines particularités.
Vérifier la conformité au RGAA est un peu perturbant pour un débutant en tests non fonctionnels. En effet, il faut :
– se familiariser avec les 106 critères (ils sont organisés par famille, ce qui aide bien) et la méthode d’évaluation
– avoir en tête qu’une évaluation « automatique » avec un outil (tel que CheckAccess)est une aide pour « savoir où on en est », mais est insuffisante pour évaluer correctement le taux de conformité
– choisir les bons outils pour certains critères (ça se trouve facilement), et en évaluer beaucoup manuellement
– savoir interpréter certains critères qui ont une dimension subjective
– s’intéresser au développement web et être à l’aise avec HTML
– comprendre le fonctionnement des outils de lecture pour personnes mal voyantes (comme NVDA) avant de démarrer les tests
Le troisième est qu’il y a une grosse différence en ce qui concerne la gestion des bugs. En effet, contrairement aux tests fonctionnels, sur un bug RGAA il faut
– bien sûr indiquer ce qu’on observe et ce qu’on attend
– citer le critère (avec le lien vers le référentiel)
– suggérer une approche de correction : utiliser telle balise / mettre en couleur XX tel élément….
Ce dernier point s’est avéré à chaque fois extrêmement efficace.
Lorsqu’un critère est non conforme sur une page (ou plusieurs) alors il est globalement non conforme !
C’est pourquoi un bon testeur RGAA priorise les bugs dont la correction peut faire augmenter le taux de conformité (parce que le critère pourrait passer à conforme). On priorise donc souvent les gains rapides (critère non conforme sur une seule page par exemple).
Mon dernier retour concerne les clients du secteur public qui contractuellement exigent à la fois d’appliquer le DSFR et d’avoir un taux de conformité RGAA 100%. Or parfois ces deux référentiels sont incompatibles…