Juridique

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 - Accessibilité des documents PDF et dérogation pour charge disproportionnée.

Remi Verhalle

Seuls les contenus PDF possédant des alternatives accessibles peuvent ne pas être considérés comme applicables ( source ).

“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.”

Christian Volle

Je confirme votre interprétation du propos de Remi le critère reste applicable et doit être considéré Non Conforme.

Voir à ce sujet l’article Exemptions – dérogations pour une application rigoureuse du RGAA .

L’article date de quatre ans, mais je n’ai toujours pas vu une seule déclaration d’accessibilité avec une justification correcte de la dérogation pour charge disproportionnée.

Dans le cas que vous évoquez, y a-t-il une vraie justification de la dérogation pour charge disproportionnée, tant pour les pdf eux-mêmes que pour l’impossibilité de produire une version alternative accessible ? Qu’indique-t-elle précisément ?

Remi Verhalle

Oui, c’est bien cela. J’en profite pour rebondir sur le sujet plus large des dérogations afin d’illustrer ce qui justifie que ces contenus soient déclarés non conformes dans le résultat de l’audit.

La réglementation distingue en effet deux notions différentes les exemptions et les dérogations.

Une exemption concerne des contenus qui n’entrent pas dans le champ d’application de la réglementation. Il est donc normal que les critères spécifiques à des contenus non évalués soient déclarés non applicables (NA). L’appréciation des exemptions relève de la seule responsabilité de l’auditeur, qui détermine de manière neutre si un contenu relève ou non du périmètre du référentiel. Une dérogation répond à une logique différente. Elle permet à un organisme de justifier, dans sa déclaration d’accessibilité, pourquoi certains contenus restent non conformes, et ne modifie pas le constat issu de l’audit. Elle s’appuie à l’inverse sur des éléments contextuels, techniques, organisationnels et économiques propres à l’organisme (et qui ne relèvent pas de l’appréciation d’un auditeur neutre). Le rôle de l’auditeur est avant tout de délivrer une appréciation objective, indépendante et reproductible de la conformité observée.

La décision d’invoquer une dérogation relève ensuite de la seule responsabilité de l’organisme et n’a pas vocation à modifier les résultats de l’audit. En cas de contentieux, il est primordial que l’action de l’auditeur se limite au constat objectif de la conformité observée, afin d’éviter que sa propre responsabilité soit mise en cause sur des éléments qui dépendent exclusivement de l’organisme.

Pour conclure, l’invocation de la charge disproportionnée constitue, lorsqu’elle est étayée, le seul motif légitime permettant à un service soumis aux obligations d’accessibilité de ne pas atteindre le statut “totalement conforme”.

Je rejoins Christian Volle sur le fait que je n’ai pas vu non plus une seule déclaration où la justification d’une charge disproportionnée est établie selon les règles, et qu’il y demeure hélas trop fréquent que des auditeurs répercutent à tort ce type de dérogation dans le calcul du taux RGAA, ce qui aboutit parfois à des déclarations de prétendue « totale conformité ».

3 - 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.

4 - Comprendre le « design for all »

Le concept de « design for all » (conception pour tous) étend la portée de l’accessibilité en visant non seulement les personnes en situation de handicap, mais aussi toutes les variations humaines — âge, capacités temporaires, contexte d’usage et préférences individuelles. Plutôt que de traiter l’accessibilité comme un ajout ou une case à cocher, le design for all le place au cœur du processus de conception, produisant des expériences plus inclusives, plus résilientes et souvent meilleures pour l’ensemble des utilisateurs.

Pourquoi le design for all compte

• Justice et dignité : garantir que tout le monde puisse utiliser les produits avec autonomie protège la dignité des personnes.
• Impact commercial : des produits accessibles atteignent plus d’utilisateurs, réduisent les barrières d’entrée et peuvent améliorer la satisfaction et la fidélité.
• Conformité et risque : au-delà des obligations légales, le non‑respect de l’accessibilité peut entraîner des coûts importants en remédiation, litiges et perte de réputation.
• Qualité et robustesse : concevoir pour une diversité d’utilisateurs conduit à des interfaces plus claires, plus tolérantes aux erreurs et plus faciles à maintenir.

Principes fondamentaux

1. Perception Les informations doivent être présentées de manière à pouvoir être perçues par différents sens et en différentes conditions. Par exemple, proposer des alternatives textuelles pour le contenu non textuel, utiliser des contrastes de couleurs suffisants, et éviter de transmettre des informations uniquement par la couleur.

2. Opérabilité Les composants de l’interface et la navigation doivent être utilisables par différentes méthodes d’entrée (clavier, écran tactile, interactions vocales) et laisser le temps nécessaire pour lire et utiliser le contenu. Il s’agit aussi de prévoir des chemins clairs et cohérents, et d’éviter les éléments qui provoquent des réactions adverses (par ex. animations stroboscopiques).

3. Compréhension L’information et l’opération de l’interface doivent être compréhensibles : langage clair, organisation logique, aides contextuelles, et gestion des erreurs avec messages explicites et solutions possibles.

4. Robustesse Le contenu doit être suffisamment robuste pour fonctionner avec une large variété d’agents utilisateurs, y compris les technologies d’assistance. Cela implique une structure sémantique correcte, des API accessibles et la compatibilité avec les standards.

Approche pratique pour les équipes produit

• Intégrer l’accessibilité dès le départ : inclure des critères d’accessibilité dans les définitions de prêt, les stories et les exigences produit.
• Tester avec des utilisateurs réels : les audits automatisés sont utiles mais incomplets ; les tests avec des personnes ayant des besoins divers révèlent des problèmes réels.
• Utiliser des composants accessibles réutilisables : les bibliothèques de composants accessibles réduisent la dette technique et assurent la cohérence.
• Former l’équipe : designers, développeurs et chefs de produit doivent connaître les principes et les techniques de base.
• Mesurer et suivre : définir des métriques (couverture des tests, nombre de tickets d’accessibilité, scores d’audit) et intégrer l’accessibilité dans le flux de travail (CI, revue de code).

Techniques et considérations concrètes

• Alternatives textuelles : images, graphiques et médias doivent avoir des descriptions utiles et concises.
• Navigation au clavier : assurer que tous les éléments interactifs sont accessibles au clavier et que l’ordre de tabulation est logique.
• Contraste et lisibilité : respecter les ratios de contraste recommandés et prévoir des tailles de police et interlignes adaptés.
• Structuration sémantique : utiliser correctement les balises (titres, listes, repères ARIA si nécessaire).
• Formulaires accessibles : labels visibles, indices, validation accessible et gestion claire des erreurs.
• Média et audiovisuel : sous‑titres, transcriptions et descriptions audio lorsque pertinent.
• Préférences utilisateur : respecter les réglages d’os/navigateur (taille de texte, préférences de mouvement, thèmes sombre/clair).
• Politiques de mouvement et animations : permettre de réduire ou supprimer les animations pour prévenir inconforts.
• Internationalisation : prévoir la longueur du texte, le sens de lecture et les conventions locales.

Surmonter les idées reçues

• « L’accessibilité coûte cher » : investir tôt coûte généralement moins qu’une refonte complète ; beaucoup d’améliorations sont peu coûteuses si intégrées dès la conception.
• « Ça ralentit l’expérience » : souvent, la simplification nécessaire pour l’accessibilité améliore la clarté et les performances perçues.
• « Seulement pour une minorité » : la diversité des utilisateurs signifie que presque tout le monde bénéficiera d’une conception plus inclusive à un moment donné (blessure temporaire, environnement bruyant, vieillissement).

Mesurer le succès

Des indicateurs pratiques :

• Pourcentage de composants accessibles dans la bibliothèque.
• Nombre et gravité des bugs d’accessibilité ouverts/fermés.
• Résultats des tests utilisateurs incluant participants avec handicaps.
• Temps moyen pour accomplir les tâches critiques pour différents groupes d’utilisateurs.

Ressources et standards

Le design for all se base sur des standards établis (WCAG pour le web, guidelines d’accessibilité pour plateformes natives) et sur les bonnes pratiques partagées par la communauté. Les outils d’audit automatisés, les checklists et les bibliothèques de composants accessibles sont des compléments utiles mais ne remplacent pas les tests utilisateurs.

Conclusion

Le design for all est une approche centrée sur la diversité humaine qui améliore l’utilisabilité, la résilience et l’équité des produits. En intégrant l’accessibilité dès la conception, en testant avec de vrais utilisateurs et en adoptant des composants et des pratiques durables, les équipes peuvent créer des expériences qui fonctionnent pour tout le monde — et qui sont meilleures pour chacun.

5 - 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 :

1. 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:
   1. 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;
   2. 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.
2. 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)

6 - 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 :

1. s’assurer que la méthode de test utilisée est communicable sur demande à un utilisateur ou à une administration ;
2. produire une table de correspondance explicite entre les critères et tests et la norme de référence choisie ;
3. 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 :

1. la mention totalement conforme s’applique à la condition que tous les critères soient satisfaits sans exception;
2. 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é;
3. 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

7 - Vous êtes poursuivi en justice. Que faire maintenant ?

Vous êtes poursuivi en justice. Que faire maintenant ? Par Karl Groves – 19/02/2026

Je travaille dans le domaine de l’accessibilité numérique depuis plus de 20 ans. J’ai été expert judiciaire dans de nombreuses affaires liées à l’ADA (Americans with Disabilities Act), réalisé des dizaines d’audits d’accessibilité, formé plus de 1 000 développeurs à travers le monde et conseillé certaines des plus grandes organisations publiques et privées. Au fil des ans, j’ai travaillé à la fois pour des plaignants et des défendeurs.

J’ai déjà écrit deux articles sur ce sujet, en 2015 et 2016, et ces publications restent pertinentes. Cependant, je souhaitais en rédiger une nouvelle version, enrichie d’informations actualisées et de recommandations clés.

Depuis 2016, entre 8 000 et 9 000 poursuites liées à l’accessibilité web sont déposées chaque année aux États-Unis. Voyons comment aborder une nouvelle action en justice. Précision importante : rien dans cet article ne constitue un conseil juridique. Je m’appuie simplement sur mon expérience pour aider les défendeurs à gérer l’accessibilité dans ce contexte.

1. Trouvez un avocat spécialisé

Dès que vous recevez une assignation ou une lettre de mise en demeure, la première étape consiste à engager un avocat expérimenté dans la défense des affaires ADA. Même si vous avez déjà un avocat pour d’autres questions juridiques ou un service juridique interne, il est crucial de faire appel à un spécialiste de ce type de contentieux.

J’ai souvent collaboré avec le cabinet Seyfarth Shaw. Si votre affaire est déposée à New York, contactez John Egan ( JEgan@seyfarth.com ). J’ai travaillé avec lui par le passé : c’est un professionnel compétent, éthique et rigoureux. En Californie, adressez-vous à Kristina Launey ( KLauney@seyfarth.com ). Si votre affaire ne relève ni de New York ni de la Californie, pas de problème : Seyfarth dispose d’avocats qualifiés dans tout le pays.

Bien que je n’aie pas d’expérience directe avec eux, les cabinets Dentons et Jackson Lewis ont également une excellente réputation dans la défense des affaires ADA. D’autres cabinets se spécialisent dans ce domaine. L’avantage de ces spécialistes ? Ils connaissent souvent déjà les juges et les avocats des plaignants, ce qui leur permet de mieux gérer votre dossier.

2. Préparez-vous à recevoir des sollicitations

Une grande partie de l’activité des entreprises spécialisées en accessibilité consiste à aider les sociétés à gérer les conséquences de leurs poursuites. Il y a de fortes chances que vous receviez des messages de commerciaux proposant leur aide. Ne les traitez pas comme du spam : triez-les et répondez à ceux qui vous semblent pertinents. En somme, si ces prestataires profitent de votre situation pour vous démarcher, vous pouvez en faire autant pour étudier rapidement les solutions disponibles sur le marché.

3. Contactez votre assurance

Vous pouvez contacter votre assurance pour connaître l’étendue de votre couverture et le type d’assistance proposée. Attention : cette démarche peut vous engager à accepter des conditions défavorables, à court ou long terme. Les avocats des assurances ne sont pas forcément experts en ADA. Je vous conseille donc d’éviter cette voie si votre assurance ne vous permet pas de choisir votre propre avocat. Insistez pour travailler avec un spécialiste : cela leur coûtera moins cher à long terme. J’ai vu des assurances abandonner trop vite en acceptant des accords coûteux et des clauses contraignantes pour leurs clients.

4. Agissez avec prudence

La pire chose à faire est de prendre des décisions hâtives. Selon le tribunal et la nature de l’affaire, vous aurez entre 14 et 30 jours pour répondre. Priorisez donc la recherche d’une représentation juridique, mais ne prenez pas de mesures précipitées concernant votre site web. Prenez le temps de planifier votre approche.

Cela dit, certaines actions sont universellement nécessaires, en dehors du volet juridique.

5. Résolvez vos problèmes d’accessibilité

Soyons clairs : sur le plan juridique, les options pour gagner le procès sont limitées. Vous pouvez :

• Contester la recevabilité du plaignant,
• Exploiter des lacunes techniques dans le dépôt de plainte,
• Arguer que le web n’est pas un « lieu public » au sens de l’ADA,
• Ou affirmer que votre site est déjà accessible.

Spoiler : ces stratégies ont peu de chances de fonctionner, surtout la dernière.

Selon l’étude « WebAIM Million », il y a en moyenne 50 erreurs d’accessibilité par page sur le web. Pour faire une comparaison imagée : trouver un site inaccessible, c’est comme tirer sur des poissons dans un tonneau… un petit tonneau, rempli à ras bord, avec un fusil à pompe, à bout portant. Dans votre cas, vous étiez probablement l’un des dizaines de poissons touchés par une seule salve.

Quoi qu’il arrive sur le plan juridique, vous devez désormais accepter une nouvelle réalité : l’accessibilité est un domaine de conformité essentiel, qui exige votre attention. Et surtout, la correction de votre site est inévitable. Le procès ne prendra fin que lorsque votre site sera accessible. Alors, commençons par là.

Solutions techniques

La meilleure défense contre une poursuite ADA ? Un site accessible.

• Si vous perdez le procès, le juge vous ordonnera de corriger votre site.
• Si vous trouvez un accord, celui-ci inclura des obligations de correction. Bref, une fois la poursuite engagée, une chose est sûre : vous devrez rendre votre site accessible. Il n’y a pas d’échappatoire.

Voici les approches possibles pour y parvenir :

Approche 1 : Ajouter un overlay (ou widget d’accessibilité)

Cette solution est mal perçue par les experts en accessibilité et les avocats, pour plusieurs raisons :

• Les éditeurs de ces outils sont souvent accusés de fausses promesses.
• Un widget seul est insuffisant et ne sera pas accepté par le plaignant.
• Certains proposent des « corrections personnalisées », mais celles-ci disparaissent dès que vous arrêtez de payer.
• Une étude académique a montré que les corrections automatiques des overlays ne résolvent que 44 % des problèmes au mieux.
• Pire encore : en 2024, plus de 1 000 poursuites ont cité l’utilisation d’un overlay comme barrière à l’accessibilité. Ces outils peuvent donc augmenter le risque de poursuite, et non le réduire.

Conclusion : à éviter, sauf en complément d’une approche plus globale.

Approche 2 : Réaliser un audit

La plupart des cabinets de conseil en accessibilité recommandent un audit. C’est une bonne solution si vous avez une équipe de développement interne. Dans ce cas, le cabinet testera en profondeur les fonctionnalités clés et les parcours utilisateurs pour identifier les problèmes.

Attention :

• Cette approche n’est viable que si vous avez une équipe technique en interne… et même dans ce cas, celle-ci risque de ne pas savoir comment corriger les problèmes identifiés.
• Si votre site est géré par un prestataire externe, il est préférable de faire appel à un développeur spécialisé en accessibilité.

Critère de choix :

• Demandez un exemple de livrable avant de sélectionner un prestataire.
• Un bon audit doit fournir des instructions claires et actionnables (pas de jargon, pas de liens vers des ressources génériques).
• Si le prestataire refuse de vous montrer un exemple ou si son rapport est flou, éliminez-le.

Approche 3 : Correction directe (remédiation)

Sans surprise, faire appel à une équipe de développement pour corriger directement les problèmes est selon nous la meilleure solution.

• Coût comparable à un audit.
• Plus rapide (en jours calendaires) qu’un audit suivi d’une correction.
• Même si vous avez une équipe interne, externaliser peut être plus rentable.

Risque principal : trouver un prestataire vraiment compétent. Le développement web accessible reste une niche. Exigez des preuves d’expertise (références, historique, etc.).

À noter : un audit ou une correction ne résout que le problème immédiat. Sans formation et outils adaptés, les futures mises à jour pourraient recréer des problèmes d’accessibilité, vous exposant à de nouveaux risques.

Outils

Votre approche dépend de la nature de vos actifs numériques :

1. Votre entreprise développe ses propres solutions :

   • Si votre équipe utilise déjà des tests unitaires, fonctionnels ou d’intégration, intégrez-y des assertions d’accessibilité.
   • Pas besoin d’acheter un outil tiers : les tests peuvent être écrits en interne.
   • Le meilleur moment pour tester l’accessibilité ? Pendant le développement du code.

2. Votre entreprise utilise des plateformes tierces (Shopify, WordPress, etc.) :

   • Optez pour un outil capable de crawler et tester votre site en production.
   • Testez plusieurs solutions avant de choisir (voir : « 13 questions à poser avant de choisir un outil de test automatisé d’accessibilité »).

Changements organisationnels

Corriger votre site ne suffit pas. Vous devez intégrer l’accessibilité dans votre culture d’entreprise.

1. Formation

• Tous les employés doivent suivre une formation de sensibilisation à l’accessibilité (à inclure dans l’onboarding).
• Les dirigeants doivent être formés aux enjeux éthiques, juridiques et aux risques/opportunités business.
• Formations spécifiques par rôle :
  • Support technique → technologies d’assistance (lecteurs d’écran, etc.).
  • Designers → conception accessible.
  • Développeurs → développement accessible.

2. Politiques et procédures

• Publiez une déclaration d’accessibilité sur votre site, avec un moyen pour les utilisateurs de signaler des problèmes.
• Définissez des normes internes (ex. : WCAG 2.2 niveau AA).
• Documentez vos processus :
  • Comment l’accessibilité est intégrée dans les workflows de design/développement ?
  • Comment les problèmes sont triés et priorisés ?
  • Comment les nouveaux contenus/fonctionnalités sont revus avant mise en ligne ? Sans procédures écrites, l’accessibilité sera systématiquement négligée.

3. Achats (Procurement)

• Si vous utilisez des produits, plateformes ou services tiers, assurez-vous qu’ils sont accessibles.
• Exigez :
  • Des clauses d’accessibilité dans vos appels d’offres et contrats.
  • Des VPAT (Voluntary Product Accessibility Template) ou ACR (Accessibility Conformance Reports) de la part des fournisseurs.
  • Une responsabilisation des fournisseurs. Rappel : si un widget ou plugin tiers sur votre site n’est pas accessible, c’est votre responsabilité légale.

6. Acceptez que ce soit un processus continu

Même si une poursuite peut sembler venue de nulle part, vous devez désormais admettre que l’accessibilité est une obligation permanente, au même titre que le respect des lois du travail, de la fiscalité ou de la sécurité.

Pour éviter de nouvelles poursuites :

• Ne traitez pas l’accessibilité comme un projet ponctuel, mais comme une démarche continue.
• Prenez-la au sérieux : c’est la meilleure façon de limiter les risques.