Table des matières
- En cas de procès
- https://afixt.com/youre-getting-sued-what-happens-now/
1 - Accessibilité des applications mobiles selon EN 301 549 v4.1.0
Résumé
🧭 L’essentiel à retenir
La nouvelle norme EN 301 549 v4.1.0 met à jour les exigences d’accessibilité pour les applications mobiles en s’alignant sur WCAG 2.2.
👉 Elle va remplacer la version actuelle (v3.2.1) et servira à prouver la conformité avec les exigences européennes (EAA).
📱 Ce qui change pour les apps mobiles
1. Clarification majeure
- Les web views dans les apps mobiles sont considérées comme du logiciel non web
- 👉 Donc : seule la clause 11 s’applique (plus d’ambiguïté)
2. Logique d’application simplifiée
- Un critère s’applique uniquement si la fonctionnalité existe
- 👉 Sinon, il est automatiquement validé
3. Responsabilité par couches
- OS / plateforme
- App mobile
- Matériel
- Technologies d’assistance
👉 Une app n’est responsable que de ce qu’elle contrôle
✅ Nouveaux points importants (WCAG 2.2)
- Focus visible : ne doit pas être caché
- Drag alternatif : pas d’action uniquement par glissement
- Taille minimale : 24×24 (idéalement 44×44)
- Pas de saisie répétée
- Auth accessible : éviter mémoire/puzzle sans alternative
🔁 Nouveaux critères maintenant obligatoires
- Titre d’écran clair
- Composants cohérents (même action = même apparence)
🛠️ Clarifications importantes
- Support du clavier externe / assistif
- Texte redimensionnable (200%)
- Reflow sans perte de contenu
- Compatibilité avec les réglages d’accessibilité du système
- Messages accessibles aux lecteurs d’écran
❌ Ce qui disparaît
- Parsing
- Aide cohérente
🎯 En résumé
👉 La norme devient :
- plus claire
- plus stricte côté mobile
- plus alignée WCAG 2.2
👉 Et impose :
- des tests plus complets
- une meilleure UX accessible
- une prise en compte réelle des usages mobiles
Article traduit
La norme EN 301 549 v3.2.1 est la principale norme européenne harmonisée dans l’Union européenne pour l’accessibilité des produits et services TIC. Elle est alignée sur WCAG 2.1 niveau AA et s’applique aux sites web, aux applications mobiles, aux logiciels non web, au matériel et aux documents électroniques.
La norme est référencée au Journal officiel de l’Union européenne depuis 2021 et peut être utilisée pour démontrer la conformité avec l’Acte européen sur l’accessibilité (EAA) via le mécanisme de présomption de conformité des normes harmonisées. Cela signifie que les organisations qui appliquent cette norme sont considérées comme respectant les exigences légales en matière d’accessibilité.
Une nouvelle version de la norme, EN 301 549 v4.1.0, est actuellement en cours d’approbation à l’Institut européen des normes de télécommunications (ETSI). Cette version met à jour les clauses 9, 10 et 11 afin de s’aligner sur WCAG 2.2 et intègre des concepts et interprétations issus de la note du groupe WCAG2ICT du W3C datée du 11 décembre 2025. Une fois cette version publiée au Journal officiel de l’Union européenne, elle remplacera la version actuelle v3.2.1, probablement avec une période de transition, comme ce fut le cas lorsque la version v3.2.1 a remplacé la v2.1.2.
Qu’est-ce que cela signifie pour les applications mobiles ?
EN 301 549 v4.1.0 introduit à la fois des clarifications conceptuelles et des changements dans les définitions et la clause 11 qui affectent directement la manière dont l’accessibilité des applications mobiles est évaluée. Certains critères de succès auparavant hors périmètre pour les logiciels non web s’appliquent désormais, et plusieurs critères WCAG 2.2 ont été ajoutés.
Cette version est beaucoup plus étroitement alignée sur la note WCAG2ICT, avec de nombreuses notes explicatives harmonisées entre les deux documents. Cet article se concentre sur ces évolutions et explique ce qui doit être revu dans une approche de test d’accessibilité mobile afin de s’aligner sur la norme mise à jour.
Changements conceptuels et clarifications
Le changement conceptuel le plus important concerne probablement les web views. EN 301 549 v4.1.0 précise explicitement :
Lorsque des parties de logiciels non web, comme les applications mobiles, sont implémentées avec des web views, celles-ci sont intégrées à l’application et ne répondent donc pas à la définition d’une page web. Les exigences de la clause 11 « Logiciels non web » sont celles qui doivent être appliquées. Il n’existe aucun cas où les exigences de la clause 9 et celles de la clause 11 s’appliquent simultanément. En cas de doute, la clause 11 prévaut.
Cette clarification supprime une ambiguïté de longue date pour les applications mobiles intégrant des web views. Celles-ci doivent être évaluées comme faisant partie du logiciel non web.
La norme précise également que les critères de succès ne s’appliquent que lorsque la situation décrite se produit réellement dans l’application. Si une fonctionnalité n’existe pas, le critère est considéré comme satisfait.
Un autre changement important est l’introduction d’un modèle clair de responsabilité par couches :
- couche sous-jacente (matériel, bas niveau),
- logiciel de plateforme (OS, composants natifs),
- logiciel applicatif (applications mobiles),
- technologies d’assistance.
Chaque couche est responsable uniquement de ce qu’elle contrôle.
La terminologie évolue également : « user agent » devient « user agent ou autre logiciel de plateforme ».
Critères de succès désormais applicables aux applications mobiles
11.2.4.2 Logiciel non web avec titre
(aligné WCAG 2.2 – 2.4.2, niveau A)
Les écrans doivent avoir un titre décrivant leur contenu ou leur objectif. Dans une app mobile, cela peut être un titre visible, une icône ou un indicateur de navigation.
11.3.2.4 Identification cohérente
(aligné WCAG 2.2 – 3.2.4, niveau AA)
Les composants ayant la même fonction doivent être identifiés de manière cohérente dans toute l’application.
Nouveaux critères issus de WCAG 2.2
11.2.4.11 Focus non masqué (minimum)
Un élément ayant le focus ne doit pas être totalement caché par d’autres contenus.
11.2.5.7 Mouvements de glissement (drag)
Toute action nécessitant un glissement doit pouvoir être réalisée sans glissement, sauf si indispensable.
11.2.5.8 Taille de cible (minimum)
Les zones interactives doivent faire au moins 24 × 24 pixels (ou équivalent). Recommandation pratique : viser 44 × 44 pour une meilleure utilisabilité.
11.3.3.7 Saisie redondante
Les informations déjà fournies ne doivent pas être redemandées inutilement.
11.3.3.8 Authentification accessible (minimum)
L’authentification ne doit pas reposer uniquement sur des capacités cognitives (mémoire, puzzle), sauf si :
- une alternative existe,
- une aide est fournie,
- ou des mécanismes comme biométrie sont disponibles.
Critères modifiés ou clarifiés
Quelques points clés :
- Descriptions audio : niveau AA couvre automatiquement le niveau A.
- Orientation : non applicable si l’app est limitée à une orientation physique.
- Objectif des champs : dépend des capacités de la plateforme.
- Redimensionnement du texte : jusqu’à 200 %, sans perte de contenu.
- Reflow : contenu adaptable sans défilement bidimensionnel.
- Contraste non textuel : concerne aussi les composants personnalisés.
- Espacement du texte : doit être respecté si configurable.
- Contenu au survol/focus : doit être contrôlable et persistant.
- Clavier : compatibilité avec les entrées clavier système (physique ou assistive).
- Piège clavier : ne s’applique que s’il y a gestion du focus.
- Clignotement : concerne uniquement ce que l’app génère elle-même.
- Liens : incluent les contrôles de navigation mobile.
- Gestes pointeur : responsabilité par couche.
- Messages d’état : doivent être accessibles aux technologies d’assistance.
Critères devenus non applicables (Void)
- 11.4.1.1 Parsing
- 11.3.2.6 Aide cohérente
Conclusion
La version EN 301 549 v4.1.0 renforce fortement l’alignement avec WCAG 2.2 et clarifie de nombreux points spécifiques au mobile. Elle implique :
- une extension du périmètre des tests,
- une meilleure prise en compte des couches techniques,
- et une évolution des pratiques de test d’accessibilité mobile.
2 - Application du RGAA aux entreprises : cas des filiales
Avis 1
Je me permets de retransmettre mon analyse que j’avais partagée sur cette liste il y a quelques mois, car elle me semble compléter les points soulevés :
Le décret de 2019 mentionne le “chiffre d’affaires”, mais pour un groupe d’entreprises, c’est le chiffre d’affaires consolidé qui est pertinent au sens du R233-7 du Code du Commerce Donc effectivement, les filiales prises individuellement ne sont, a priori, pas soumises directement aux obligations, mais la société mère y est soumise dès lors que son CA consolidé est supérieur à 250 millions d’euros. Les services en ligne de la société mère et les services mutualisés devront donc répondre aux obligations du décret de 2019.
Pour rebondir sur les remarques de Bertrand et Aurélien, s’en tenir aux seules mentions légales rendrait le contournement de la loi extrêmement simple : il suffirait à un groupe de confier sa communication à une petite filiale dédiée sous le seuil des 250 millions.
À titre d’exemple :
Le site de Lagardère indique dans ses mentions légales qu’il appartient à la filiale “Lagardère Ressources” (CA de 48,9 millions d’euros en 2024, CA Groupe 8942 millions).
Le site e.leclerc est géré par la filiale “L Commerce” (CA de 131 millions d’euros en 2024).
L’Arcom est à mon avis légèrement péremptoire lorsqu’elle affirme que la société désignée dans les mentions légales serait celle dont le CA seul doit être apprécié.
Dès lors qu’il existe une concentration des pouvoirs de direction et que la filiale n’est qu’un instrument de communication pour les intérêts du groupe, c’est le contrôle effectif qui doit primer.
En conclusion, un service en ligne d’une filiale ne pourrait être considéré comme autonome que s’il dispose d’une gestion propre, de ressources financières indépendantes pour sa création et d’une ligne éditoriale non contrôlée par le groupe.
Avis 2
L’Arcom fait clairement une lecture littérale du droit et donne une indication pragmatique pour que ses agents puissent faire des contrôles sans ambiguïté:
L’article du décret ne parle pas de CA consolidé ( ce que fait en principe le législateur quand il souhaite parler de “groupe”) et au contraire renchéri en parlant de calcul “par personne”. Si l’Arcom avait dit l’inverse (CA = CA consolidé) , elle aurait pu être dénoncée pour excès de pouvoir. De quelle “personne” parle t-on ? La réponse est à l’article 1-1 de la LCEN : celle dont l’activité est d’éditer le service de communication en ligne et dont on retrouve le nom dans les mentions légales. C’est simple, vérifiable. Efficace pour les contrôles.
Il n’en reste pas moins que c’est un sacré trou dans la raquette car un gros groupe pourrait effectivement techniquement s’affranchir de l’accessibilité en faisant dépendre ses sites d’une filiale qui ferait moins de 250 M de CA…
Mais :
des groupes oseront-il cet abus de droit et risquer un procès devant le Conseil d’État qui aurait toutes les chances de mal se finir pour eux ? Et au delà du risque juridique, il y a le risque sociétal… En outre, ces filiales peuvent effectivement maintenant tomber sous le coup de l’EAA (Directive (UE) 2019/882 ) pour peu qu’elles fournissent - aujourd’hui - des produits ou services de type bancaires, sites de commerce électronique, de transport (billetterie), médias audiovisuels, livres numériques ( et demain ?). Après, en droit, il y a toujours une part d’interprétation et une part de stratégie.
Avis 3
Si un service numérique est édité dans les intérêts économiques d’un acteur économique, ou de plusieurs, peu importe ce que dit la page “Mentions légales”, c’est bien le chiffre d’affaires de ces acteurs qui doit être pris en compte.
Là ou l’ARCOM va au-delà de la juste interprétation, c’est en prétendant qu’un acteur économique peut décider qu’en confiant la responsabilité légale d’un site internet à une autre unique entité économique (que cela soit sa filiale, une holding ou une tierce partie) alors cela l’exonérerait de ses propres obligations légales rien qu’en modifiant l’entité responsable dans les mentions légales.
Lorsque l’article 2 du décret de 2019 indique que le chiffre d’affaires est calculé “pour chaque personne”, cela implique donc effectivement un calcul du CA au niveau de la personne morale, donc l’entreprise elle-même (et non du groupe auquel elle appartient), mais n’exclut pas la possibilité que le service électronique bénéficie économiquement à plusieurs personnes. Il faut donc calculer le CA pour chaque personne morale dont le service en ligne présente un intérêt économique. Si une seule de ces structures dépasse le seuil de 250 millions d’euros, alors on peut avec certitude affirmer que le service doit répondre aux obligations du RGAA, peu importe les liens économiques qui unissent ces entreprises ni le nom inscrit dans les mentions légales.
Il est normal et habituel que le CA de chaque filiale soit apprécié individuellement, mais pour une société mère (et uniquement pour elle), il est normalement attendu que le CA à prendre en compte soit le CA consolidé, car c’est habituellement ce chiffre qui sert de seuil à de nombreuses réglementations (égalité homme-femmes, calcul des seuils de TVA pour les franchises, calcul de la CVAE, seuils sociaux du droit du travail, ou encore répartition des bénéfices). Voir ce qui se fait par exemple pour une unité économique et sociale
Lorsqu’un service électronique bénéficie à l’ensemble des sociétés d’un groupe, il paraît judicieux d’apprécier le CA à l’échelle du groupe. Ma lecture distingue donc la société mère, dont la réalité économique est par nature consolidée, des filiales dont le chiffre d’affaires doit continuer à s’apprécier individuellement.
3 - Réglementation Organismes Publics et Arcom
Pour concernant les obligations légales, la déclaration d’accessibilité d’un site comprenant le schéma pluriannuel et le plan d’action et mentionnant un état non conforme en l’absence d’un audit est il correct ?
Dans le cadre de site organise le publics, c’est l’Arcom qui contrôle et elle indique 25000€ d’amende en cas de manquements aux obligations d’affichage, donc pour ce qui est cité au dessus ce serait bon j’imagine même sans audit ?
Mais après il est indiqué un risque d’amende de 50000€ en pour non conformité aux exigences en matière d’accessibilité.
Que faut il fait faire dans ce cas? Est ce que cela impose la réalisation d’un audit et que seulement le fait de réaliser un audit couvre cette exigence ?
Dans ce cas afficher le taux de conformité serait suffisant ?
Ou faut il en plus de l’audit, réaliser les corrections des anomalies listées (mais tout corriger semble est difficile ) ?
Avis
Pour que votre déclaration soit conforme, vous devez passer un audit. La déclaration doit, entre autre, indiquer le nom de l’organisme qui a effectué l’audit ainsi que la date. Elle doit également informer des non-conformités, des exemptions, etc… Et il n’y a qu’un audit qui permet de le faire. Plus d’information sur la déclaration ici: https://accessibilite.numerique.gouv.fr/obligations/declaration-accessibilite/ Donc faire une déclaration non conforme vous expose à des sanctions.
Concernant les corrections, le schéma pluriannuel sur 3 ans et les plans d’actions annuels permettent d’étaler les corrections et donc de ne pas tout faire en même temps.
Pour être en conformité vous devez donc faire passer un audit, publier la déclaration d’accessibilité ainsi que le taux de conformité, publier le schéma pluriannuel sur 3 ans et le plan d’action sur 1 année.
Avis
- Pour que votre déclaration soit conforme, vous devez passer un audit.
- Non une déclaration non conforme par défaut sans audit est conforme sur les aspects déclaratif
- La déclaration doit, entre autre, indiquer le nom de l’organisme qui a effectué l’audit ainsi que la date.
- L’autocontrole est également permis
- Elle doit également informer des non-conformités, des exemptions, etc… Et il n’y a qu’un audit qui permet de le faire. Plus d’information sur la déclaration ici: https://accessibilite.numerique.gouv.fr/obligations/declaration-accessibilite/. Donc faire une déclaration non conforme vous expose à des sanctions.
- Non pas sur l’aspect déclaratif uniquement sur l’aspect conformité
- Concernant les corrections, le schéma pluriannuel sur 3 ans et les plans d’actions annuels permettent d’étaler les corrections et donc de ne pas tout faire en même temps.
- Le schéma n’a pas vocation à lister les non conformité ce n’est pas le plan de corrections du site mais un ensemble d’actions au niveau du fonctionnement de l’organisme (gouvernance, formation, clause d’achat, etc) en charge de l’ensemble des sites
- Pour concernant les obligations légales, la déclaration d’accessibilité d’un site comprenant le schéma pluriannuel et le plan d’action et mentionnant un état non conforme en l’absence d’un audit est il correct ?
- Oui sur l’aspect déclaratif (si contenu du schéma est également correct)
- Dans le cadre de site organise le publics, c’est l’arcom qui contrôle et elle indique 25000 e d’amende en cas de manquements aux obligations d’affichage, donc pour ce qui est cité au dessus ce serait bon j’imagine même sans audit ?
- Oui si il y a également la mention “accessibilité : non conforme” à minima sur page d’accueil
- Mais après il est indiqué un risque d’amende de 50 000 en pour non conformité aux exigences en matière d’accessibilité. Que faut il fait faire dans ce cas? Est ce que cela impose la réalisation d’un audit et que seulement le fait de réaliser un audit couvre cette exigence ?
- Non il faut etre conforme (donc faire les corrections nécessaire pour etre conforme et donc pour cela faire un audit est souvent effectivement la première étape sauf à avoir en interne qqun de suffisamment compétent pour mettre en oeuvre des corrections directement sans pour autant avoir un audit formel)
- Dans ce cas afficher le taux de conformité serait suffisant ?
- Non cf plus haut
- Mes questions sont purement pour le cadre légales ce qu’il faut afficher et faire réellement. Évidement que dans un autre monde l’idéal serait de faire les audits et tout corriger mais lorsque l’organisme a plusieurs applications ça fait un gros budget et parfois l’organisme n’a pas la main sur les modifications (SaaS)
- En cas de SaaS dont l’entité n’est pas propriétaire cela ne relève pas de l’article 47 par exemple si votre administration utilise microsoft team pour ces visio elle n’a pas a faire une déclaration sur microsoft teams. Par contre elle doit demander / inclure la conformité dans ses exigences lors de son processus d’achat (comme pour le RGPD par exemple) et s’assurer de la conformité
- Dans tous les cas, si elle juge cela légitime elle peut si une solution alternative conforme est mise en place évoquer et justifier le caractère disproportionnée de la charge de mise en conformité cela sera alors soumis à l’avis du juge / autorité de contrôle en cas de conflit.
Avis
Le RGAA indique
« 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. »
Donc, en l’absence d’audit, l’obligation d’avoir une déclaration d’accessibilité pour le site (ou l’application mobile) n’est pas respectée et l’Arcom serait en droit d’appliquer la sanctionde 25 k€ au titre du non-respect des obligations déclaratives et de 50 k€ au titre du défaut d’accessibilité des contenus.
Il est rappelé que le besoin principal des personnes handicapées, ce n’est pas d’avoir des déclarations d’accessibilité ou des schémas pluriannuels de mise en accessibilité.
Leur besoin est d’avoir des sites et des applications pleinement accessibles.
Il faut souligner qu’on parle de schémas pluriannuels de mise en accessibilité. L’expression « mise en accessibilité » est fondamentale : au terme du schéma pluriannuel, l’ensemble des services de communication au public en ligne de l’organisme doit avoir été rendu accessible.
Il ne serait donc pas recevable d’afficher un taux de conformité inférieur à 100 % et de ne pas agir pour la mise en accessibilité complète.
L’argument du recours à des prestataires externes (SaaS par exemple) pour la fourniture des services de communication au public en ligne n’est pas entendable. Il appartient à l’organisme d’exiger de ses prestataires qu’ils lui permettent de respecter la réglementation relative à l’accessibilité.
Avis
Étant donné que le RGAA indique « Non-conformité : s’il n’existe aucun résultat d’audit en cours de validité permettant de mesurer le respect des critères », on pourrait, avec une lecture large du texte, considérer qu’il y a « évaluation effective » même en l’absence d’audit.
Avis
Personnellement, je dirais qu’il faut être prudent vis-à-vis du conseil juridique, ce rôle appartient aux juristes, et il me parait sage d’orienter vers des professionnels du droit pour toute analyse d’exposition ou de risque contractuel. Il y a une différence entre conseil juridique et information sur le cadre légal, qui est bien de notre ressort. On peut aider un client à mesurer sa situation sans se substituer à un avocat.
Sur la pertinence des déclarations d’accessibilité, il n’y a actuellement aucune jurisprudence, aucune décision ne porte encore sur des questions de déclaration d’accessibilité publiée sans audit.
Dans L’article 3 de la décision d’exécution 2018/1523 de la commission https://eur-lex.europa.eu/legal-content/fr/TXT/HTML/?uri=CELEX:32018D1523
On trouve ceci :
- Les États membres veillent à ce que les mentions figurant dans la déclaration, au sujet de la conformité avec les exigences fixées dans la directive (UE) 2016/2102, soient exactes et fondées sur l’un des éléments suivants:
- une évaluation effective de la conformité du site internet ou de l’application mobile avec les exigences fixées dans la directive (UE) 2016/2102, telle que:
- une autoévaluation réalisée par l’organisme du secteur public,
- une évaluation réalisée par un tiers, par exemple une certification;
- toute autre mesure, jugée appropriée par les États membres, qui offre une assurance égale que les mentions figurant dans la déclaration sont exactes.
- La déclaration indique la méthode utilisée en application du paragraphe 1.
À part des bruits de couloirs, Je ne trouve aucune source officielle qui validerais le fait qu’une déclaration de non-conformité pour défaut d’audit pourrait valider les obligations d’affichage.
La transposition de la directive dans le droit français n’aborde absolument pas le point B (Sauf peut-être si ça concerne la fiabilité de l’audit)
4 - Stratégie d’audit accessibilité pour sites répartis dans le monde
J’accompagne actuellement un client qui dispose de plusieurs sites répartis à l’international. L’objectif est de réaliser des audits d’accessibilité sur l’ensemble de cet écosystème numérique.
Je m’interroge toutefois sur le choix du référentiel le plus pertinent à appliquer. Mon idée initiale serait d’auditer :
les sites opérant en France selon le RGAA,
et les autres sites, hors France, selon les WCAG.
À noter que l’ensemble des sites sont hébergés aux États-Unis, ce qui pourrait également influencer la décision.
Je souhaiterais donc avoir votre avis et vos recommandations sur la démarche la plus cohérente à adopter dans ce contexte.
Avis
Le RGAA vous autorise à unifier la méthode d’évaluation. P. ex. n’utiliser que les WCAG.
Avis
Merci beaucoup pour ce retour qui m’intéresse d’autant plus que je suis confronté à un cas un peu similaire (prestataire étranger délivrant en France un progiciel audité selon les normes WCAG).
En revanche, je m’interroge quant aux conséquences sur la déclaration d’accessibilité de cette autorisation du recours à une autre méthode de test.
En effet, à partir du seul résultat final des tests WCAG, il me semble difficile de calculer un taux de conformité au RGAA même en utilisant une table de concordance des critères RGAA/WCAG puisque les critères WCAG et RGAA ne se recoupent pas parfaitement (à un même critère WCAG peuvent correspondre X critères RGAA et à un même critère RGAA peuvent correspondre X critères WCAG).
Or le format de la déclaration d’accessibilité fixé par le RGAA impose certaines mentions qui présupposent la connaissance du taux de conformité au RGAA (état de conformité de l’application et pourcentage des critères RGAA respectés). Faut-il conclure que ces mentions cessent d’être obligatoires sur la déclaration d’accessibilité si l’audit a été réalisé exclusivement d’après la norme WCAG ?
Avis
Le RGAA autorise le recours à une autre méthode dès lors qu’il existe “une table de correspondance explicite entre les critères et tests et la norme de référence choisie”.
Les personnes mentionnées au 4° de l’article 47 précité peuvent 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 ou à une administration ;
- 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é.
La “norme de référence” dont il s’agit c’est la norme EN 301 549 elle même calquée sur le WCAG, donc de fait cette table de correspondance existe. A contrario, et aussi curieux que cela puisse paraître, une telle table de correspondance n’existe pas pour le RGAA.
La lecture de la décision d’exécution européenne applicable en France est intéressante notamment pour comprendre comment établir la déclaration en l’absence du “taux RGAA”.
Ainsi, cette décision précise que :
- la mention totalement conforme s’applique à la condition que tous les critères soient satisfaits sans exception;
- la mention partiellement conforme ne s’applique qu’à la condition de d’avoir quelques exceptions non satisfaites et que les mesures nécessaires aient été prises pour parvenir à une totale conformité;
- sinon la mention est “non conforme”. On comprend donc que le calcul du taux n’est pas nécessaire sauf à donner un indicateur qui n’a réellement d’intérêt qu’en interne à l’organisme.
Ceci étant dit, rien n’empêche de calculer le “taux RGAA” après avoir fait un audit WCAG, ou calculer un “taux WCAG”, bien que, là encore, ça n’ait pas grande utilité.
Avis
attention que le standard EN301549 est calqué en partie sur le WCAG2.1 uniquement. Voici un article qui cite les différences : https://digital-strategy.ec.europa.eu/en/policies/latest-changes-accessibility-standard
Avis
Les simples renvois pour information vers la norme légale EN 301 549 au sein des critères RGAA ne constituent pas vraiment, à mon sens, ce qu’on attend d’une table de correspondance. Des documents récapitulatifs ont été produits avec les informations du RGAA mais ils ne permettent pas vraiment d’atteindre l’objectif qui est de vérifier l’exhaustivité de la méthodologie.
Une telle table devrait détailler les exigences propres à chaque critère de la norme européenne, et indiquer en face les tests de la méthode technique qui couvrent chacune de ces exigences.
En cherchant à procéder de la sorte, on éprouve quelques difficultés au niveau du RGAA pour établir facilement une telle correspondance (*)
Bonne fin de journée
(*) je mets quelques exemples en annexe, car le sujet est complexe (et surement ennuyeux), de quelques problèmes relevés rapidement ::
- la référence aux 9.2.4.7 et 9.1.3.1 pour le RGAA 7.3,
- la couverture partielle du critère 9.3.2.4 de la norme (par le RGAA 11.3),
- le RGAA 13.3/13.4 traitant du chapitre 10 de la norme mais faisant référence à des critères 9.x de la norme et des techniques sans lien avec le sujet,
- la référence au 9.2.4.6 au 11.1 (avec couverture incomplète du 9.3.3.2) et la référence au 9.3.3.2 au 11.2