EN 301 549 V4.1.1 : ce qui a changé, et quelle version compte encore
La norme derrière l'European Accessibility Act a une nouvelle version, publiée en septembre 2026. Elle fait entrer WCAG 2.2 dans la clause logicielle. La version que vise la loi, elle, reste V3.2.1, de 2021. Voici la différence, exigence par exigence, et ce à quoi l'audit d'une application mobile doit répondre aujourd'hui.
Quelle version vise la loi
Une norme devient la référence juridique lorsque sa référence est publiée au Journal officiel de l'Union européenne. C'est ce qui donne à sa conformité la présomption de conformité à la loi. Pour EN 301 549, la version citée est V3.2.1, de mars 2021, qui porte WCAG 2.1 niveau AA.
V4.1.1 a été publiée en septembre 2026. À ce jour, elle n'est pas citée : elle ne change donc aucune obligation par elle-même. AccessibleEU, le centre de la Commission elle-même, a indiqué le 7 septembre 2026 que, tant que la citation n'est pas parue, la référence en vigueur reste V3.2.1.
Les textes nationaux passent d'une version figée à une référence dynamique. En France, le décret n° 2026-816 du 24 août 2026 a réécrit le décret antérieur : un service est accessible lorsqu'il est conforme aux normes harmonisées dont les références sont publiées au Journal officiel. Quand la citation change, l'obligation suit, sans nouveau décret.
La conséquence pratique pour quiconque réalise un audit aujourd'hui : un rapport qui ne répond que pour V4.1.1 ne répond pas à la question que pose la loi, et un rapport qui ne répond que pour V3.2.1 ignore WCAG 2.2. Les deux versions doivent figurer dans le tableau.
Ce que la clause 11 a gagné
La clause 11 est la partie logicielle, celle à laquelle répond une application mobile. Dans V4.1.1, elle porte les 50 critères WCAG 2.2 de niveaux A et AA qui s'appliquent aux logiciels, contre WCAG 2.1 dans V3.2.1.
Sept exigences de la clause 11 n'ont pas d'équivalent dans V3.2.1. Cinq viennent de WCAG 2.2 : 11.2.4.11 Focus not obscured (minimum), 11.2.5.7 Dragging movements, 11.2.5.8 Target size (minimum), 11.3.3.7 Redundant entry et 11.3.3.8 Accessible authentication (minimum). Deux étaient simplement sans objet dans V3.2.1 et sont désormais des exigences : 11.2.4.2, qui reprend WCAG 2.4.2 sous le titre Non-web software titled, et 11.3.2.4 Consistent identification.
Parmi elles, 11.2.5.8 est celle qui change le résultat de la plupart des audits mobiles. Une cible tactile inférieure à 24 par 24 n'était qu'un conseil sous WCAG 2.1 et constitue un échec sous 2.2, et les cibles trop petites sont le défaut que nos propres vérifications trouvent le plus souvent.
Un critère de WCAG 2.2 n'est pas entré dans la clause logicielle : 3.2.6 Consistent help. La clause 11.3.2.6 est sans objet, une application n'y est donc pas évaluée sur ce point.
Ce qu'elle a perdu, et ce qui n'a fait que bouger
Parsing disparaît. WCAG 2.2 a supprimé le critère 4.1.1, et avec lui l'exigence 11.4.1.1.1 de V3.2.1. Si un ancien rapport met une app en échec sur Parsing, ce constat n'existe plus.
Les exigences qui portent sur les services d'accessibilité eux-mêmes ont été réécrites. V3.2.1 demandait au logiciel d'utiliser les services d'accessibilité documentés de la plateforme (11.5.2.3) et demandait aux plateformes de les fournir (11.5.2.1, 11.5.2.2). Dans V4.1.1, 11.5.2.3 est une recommandation et 11.5.2.2 est sans objet, tandis que l'obligation de la plateforme est énoncée une seule fois, en 11.5.2.1.
Les outils de création ont quitté la clause 11 pour la clause 5 : les cinq exigences numérotées 11.8.1 à 11.8.5 sont désormais 5.10.1 à 5.10.5, avec les mêmes titres.
La documentation et l'assistance ont été restructurées. Les 12.1.1, 12.1.2, 12.2.2, 12.2.3 et 12.2.4 de V3.2.1 sont devenues 12.1, 12.2 et 12.3, et les guides électroniques de programmes ont été ajoutés en 12.4 et 12.5.
La clause 6, pour les apps qui passent des appels, a été réécrite autour de scénarios opérationnels (6.0.2 à 6.0.9), et ses exigences de texte en temps réel ont été renumérotées et renommées. La clause 7 emploie maintenant le terme subtitles là où V3.2.1 disait captions.
Les numéros qui ont survécu à une renumérotation sont le piège. Dans V3.2.1, 6.2.3 est Interoperability ; dans V4.1.1, le même numéro désigne DTMF touch-tone generation during RTT operations. Un tableau de correspondance doit faire correspondre des exigences, pas des numéros.
Ce à quoi un audit doit répondre aujourd'hui
En comptant les exigences qu'une application mobile native peut respecter ou manquer, notre protocole répond pour 144 d'entre elles : les exigences V4.1.1 des clauses 5, 6, 7, 11 et 12, plus les 19 exigences de V3.2.1 qui n'ont pas d'équivalent identique dans V4.1.1 et qui appartiennent encore à la version que cite la loi.
Chaque exigence est vérifiée à la main sur les écrans du rapport, avec les lecteurs d'écran de l'environnement de test qui y sont nommés. Des vérifications automatisées tournent en parallèle et pointent la ligne de code, mais elles répondent pour une partie de la liste, pas pour la liste entière.
Le rapport indique la clause dans les deux numérotations : le même document répond à un régulateur qui lit V3.2.1 et à une équipe qui se prépare à V4.1.1.
Ou faites vérifier le build entier : l'audit de conformité aux stores coûte 190 €, en 2 jours ouvrés.