EN 301 549 v4.1.1 est là · Ce que ça change, et que faire tout de suite

En résumé

Le 2 septembre 2026, l'ETSI a publié EN 301 549 v4.1.1, la nouvelle version de la norme technique européenne d'accessibilité pour les sites web, applications, PDF, logiciels et produits de télécommunication. Dans les lignes qui suivent, je l'appellerai « la norme », plus simple pour les lecteurs d'écran. C'est un évènement important, mais ce n'est pas encore une échéance. Voyez ça comme la version finale d'un brouillon qui devient le règlement officiel, alors que l'arbitre (la Commission européenne) n'a pas encore donné le coup de sifflet pour démarrer le match.

Si vous êtes responsable d'un site web, d'une application, ou de la conformité en accessibilité au sein de votre organisation, au Luxembourg, en France, ou n'importe où dans l'UE, voici ce qui change concrètement, à partir de quand cela devient juridiquement contraignant, et ce qu'il faut faire dès maintenant.

Pourquoi cette mise à jour existe

Cette norme est le référentiel technique derrière l'European Accessibility Act (EAA). L'EAA est la directive qui dit « vos produits et services numériques doivent être accessibles ». La norme EN 301 549 est le règlement détaillé qui précise exactement ce que signifie « accessible » en pratique, principalement en s'appuyant sur les critères de succès WCAG, plus des exigences supplémentaires dont l'EAA a besoin (communication en temps réel, matériel, terminaux en libre-service, etc.), déjà intégrées pour la plupart dans le RAWeb 1.1, le référentiel luxembourgeois.

Jusqu'à présent, ce règlement s'appuyait sur WCAG 2.1. La nouvelle version v4.1.1 de la norme le reconstruit sur WCAG 2.2, avec en prime une réécriture substantielle des règles de communication en temps réel (pensez appels vidéo, chat, sous-titres pendant les appels).

Trois étapes, pas une seule échéance

C'est la partie qui piège pas mal de monde, y compris de nombreux professionnels. Publication ne veut pas dire obligation légale. Il y a trois jalons distincts, et les confondre est actuellement l'erreur la plus répandue.

1. Publication par l'ETSI, faite. La norme en version v4.1.1 a été formellement publiée le 2 septembre 2026. Le contenu technique est final et ne changera plus.
2. Citation au Journal officiel de l'UE (JOUE), en attente. C'est l'étape qui compte réellement sur le plan juridique. Tant que la Commission européenne n'a pas cité la v4.1.1 au JOUE, elle ne bénéficie pas de la « présomption de conformité », ce refuge légal qui dit « si vous avez suivi cette norme, vous êtes présumé conforme à la loi ». À l'heure actuelle, c'est toujours la version v3.2.1 (basée sur WCAG 2.1) qui est juridiquement reconnue. La citation est attendue autour du 30 novembre 2026, bien que plusieurs observateurs signalent que cette date n'est pas confirmée par la Commission et pourrait bouger.
3. Transposition dans le droit national de chaque pays. L'EAA est une directive, pas un règlement, donc chaque pays de l'UE rédige sa propre loi de transposition. Certaines de ces lois renvoient à l'EN 301 549 sans préciser de numéro de version. Si c'est le cas de la vôtre, la nouvelle version pourrait devenir votre référence légale automatiquement, sans qu'aucune nouvelle législation ne soit nécessaire de votre côté. Au Luxembourg, le référentiel pour les sites web est le RAWeb, déjà aligné sur cette norme, et censé évoluer avec elle.

Pourquoi s'y mettre dès maintenant malgré tout ? Parce que, quelle que soit la version finalement citée, c'est vers WCAG 2.2 que les choses se dirigent, et construire ou corriger vos produits aujourd'hui sur la base de la 2.1 n'invalidera pas votre travail, mais le rendra incomplet. Si votre loi nationale ne fige pas de numéro de version, les nouvelles exigences pourraient s'appliquer à vous plus tôt que prévu.

Ce qui change concrètement

Le changement principal pour les sites web, applications et documents est le passage de WCAG 2.1 à WCAG 2.2, qui ajoute six nouveaux critères de succès. Nous avons déjà évoqué ces nouveaux critères WCAG 2.2 dans un précédent article. Voici ce que chacun signifie pour un utilisateur réel, pas seulement pour la checklist d'un auditeur.

• Focus non obscurci (AA) : quand vous naviguez au clavier sur une page avec la touche tabulation, l'élément que vous avez sélectionné doit rester réellement visible, pas caché derrière un en-tête collant ou une bannière de cookies.
• Mouvements de glisser-déposer (AA) : tout ce que vous feriez normalement glisser (comme un curseur ou le réordonnancement d'une liste) doit pouvoir se faire sans glisser, pour les personnes incapables d'exécuter ce geste avec précision.
• Taille minimale des cibles (AA) : les boutons et icônes cliquables doivent mesurer au moins 24 par 24 pixels, afin que les personnes ayant une motricité réduite ou de gros doigts sur écran tactile puissent réellement les toucher.
• Aide cohérente (A) : si un lien d'aide, un bouton de chat ou une option de contact apparaît sur plusieurs pages, il doit rester au même endroit relatif à chaque fois, pour que les gens n'aient pas à le chercher.
• Saisie redondante (A) : si un utilisateur vous a déjà donné une information (comme son adresse à une étape précédente), ne le forcez pas à la retaper. Préremplissez-la ou laissez-le simplement la sélectionner à nouveau.
• Authentification accessible minimale (AA) : les étapes de connexion qui s'appuient sur la résolution d'une énigme ou la mémorisation de quelque chose (un CAPTCHA classique, par exemple) doivent proposer une alternative accessible qui ne repose pas sur cette tâche cognitive spécifique.

Deux choses à retenir ici. Premièrement, certains de ces critères (taille des cibles, glisser-déposer, visibilité du focus) résident en grande partie dans votre design system, dans vos boutons, curseurs et composants de mise en page, c'est justement pour ça que les corriger au niveau du composant, plutôt que page par page, est la voie la plus efficace. Deuxièmement, respecter WCAG 2.2 AA est nécessaire mais pas suffisant pour la conformité à la norme européenne. Celle-ci couvre aussi des aspects que WCAG ne traite pas, comme les exigences remaniées de communication en temps réel pour les produits d'appel, de messagerie et de vidéoconférence, où la portée du support du « texte en temps réel » s'est considérablement élargie. Si votre organisation développe ce type de produit, prévoyez un effort nettement plus important sur ce point précis.

Ce qu'il faut faire concrètement cette semaine

Pas besoin d'un groupe de travail de six mois pour démarrer. Quelques actions concrètes :

• Auditez dès maintenant sur la base de WCAG 2.2, pas 2.1, même si votre loi nationale renvoie techniquement encore vers l'ancienne version. La norme WCAG de CheckFox intègre déjà l'ensemble des critères 2.2, vous testez donc dès aujourd'hui l'exigence de demain, pas celle d'hier.
• Vérifiez ce que votre loi nationale référence réellement. Si elle cite l'EN 301 549 sans numéro de version, vous êtes peut-être déjà concerné par la v4.1.1 dès qu'elle sera citée. Si vous êtes au Luxembourg, c'est le référentiel RAWeb qu'il faut surveiller.
• Attendez-vous à de nouveaux constats sur des points qui passaient auparavant. Ce n'est pas une régression de votre produit, c'est la barre qui se relève. Anticipez-le plutôt que d'en être surpris.
• Commencez par le design system, pas par les pages. La taille des cibles, les alternatives au glisser-déposer et la visibilité du focus sont presque toujours plus efficaces à corriger une seule fois dans un composant partagé de bouton, de curseur ou de fenêtre modale, plutôt que dispersées sur chaque page qui les utilise.
• Si vous développez des outils de communication en temps réel (appel, chat, vidéo), commencez dès maintenant à évaluer l'ampleur des changements de la clause 6. C'est la partie la plus susceptible d'exiger un véritable refactoring technique plutôt qu'un simple ajustement de design.
• Concentrez-vous sur vos services, pas seulement sur un site web. C'est pour ça que je propose les Parcours d'Accessibilité avec CheckFox.

Comment CheckFox et moi pouvons vous accompagner dans cette transition

Je suis Geoffrey, la personne qui développe CheckFox, et aussi un auditeur en accessibilité en activité. J'ai construit cette suite d'outils d'accessibilité précisément parce que j'étais fatigué de maintenir des tableurs et des checklists statiques chaque fois qu'une norme évolue, exactement ce qui se passe actuellement avec l'EN 301 549 v4.1.1.

Deux façons de vous aider à naviguer cette mise à jour, selon vos besoins.

Si vous voulez auditer vous-même : CheckFox intègre déjà WCAG 2.2, ainsi que le RGAA, le RAWeb, le RAAM et le RAPDF, tous cartographiés sur l'EN 301 549. Vous n'avez pas besoin de construire votre propre checklist ni d'attendre que quelqu'un mette à jour un PDF. Cartographiez votre parcours utilisateur complet sur votre site web, votre application, vos PDF et vos emails, lancez des audits selon les critères actuels, et générez une déclaration d'accessibilité prête pour un audit en quelques clics.

Quand les référentiels évolueront à nouveau (et ils le feront), le versionnage de CheckFox vous permet de conserver ce que vous avez déjà testé et de montrer une réelle progression dans le temps, plutôt que de repartir de zéro.

Si vous préférez faire réaliser l'audit par quelqu'un d'autre : je propose directement des services d'audit d'accessibilité, couvrant les mêmes référentiels sur lesquels CheckFox est construit : WCAG, RGAA, RAWeb, RAAM et RAPDF. Si vous ne savez même pas encore si l'EAA s'applique à votre organisation, commencez par la auto-évaluation gratuite sur la page EAA, elle prend environ une minute et vous oriente vers les premiers points à examiner. À partir de là, je peux vous aider à cadrer un plan de transition vers la conformité (et au-delà) qui s'adapte à votre calendrier de mises en production, plutôt que de traiter ce sujet comme un exercice d'urgence en novembre.

Dans tous les cas, l'objectif n'est pas de paniquer face à une date de citation qui pourrait bouger. C'est d'arrêter de tester par rapport à une norme déjà en fin de vie, et de commencer à construire vers celle qui arrive. Lancez un audit CheckFox gratuit dès aujourd'hui, ou contactez-moi directement si vous voulez un coup de main pour cadrer ce que cette mise à jour signifie pour votre produit spécifique.

Sources et ressources

https://weareneem.com/en-301-549-v4-1-1-ecommerce-accessibility/ « EN 301 549 V4.1.1 : ce que cela signifie pour l'accessibilité e-commerce, Neem Consulting »## La version courte

Le 2 septembre 2026, l'ETSI a publié EN 301 549 v4.1.1, la nouvelle version de la norme technique européenne d'accessibilité pour les sites web, applications, PDF, logiciels et produits de télécommunication. Dans les lignes qui suivent, je l'appellerai « la norme », plus simple pour les lecteurs d'écran. C'est un évènement important, mais ce n'est pas encore une échéance. Voyez ça comme la version finale d'un brouillon qui devient le règlement officiel, alors que l'arbitre (la Commission européenne) n'a pas encore donné le coup de sifflet pour démarrer le match.

Si vous êtes responsable d'un site web, d'une application, ou de la conformité en accessibilité au sein de votre organisation, au Luxembourg, en France, ou n'importe où dans l'UE, voici ce qui change concrètement, à partir de quand cela devient juridiquement contraignant, et ce qu'il faut faire dès maintenant.

Pourquoi cette mise à jour existe

Cette norme est le référentiel technique derrière l'European Accessibility Act (EAA). L'EAA est la directive qui dit « vos produits et services numériques doivent être accessibles ». La norme EN 301 549 est le règlement détaillé qui précise exactement ce que signifie « accessible » en pratique, principalement en s'appuyant sur les critères de succès WCAG, plus des exigences supplémentaires dont l'EAA a besoin (communication en temps réel, matériel, terminaux en libre-service, etc.), déjà intégrées pour la plupart dans le RAWeb 1.1, le référentiel luxembourgeois.

Jusqu'à présent, ce règlement s'appuyait sur WCAG 2.1. La nouvelle version v4.1.1 de la norme le reconstruit sur WCAG 2.2, avec en prime une réécriture substantielle des règles de communication en temps réel (pensez appels vidéo, chat, sous-titres pendant les appels).

Trois étapes, pas une seule échéance

C'est la partie qui piège pas mal de monde, y compris de nombreux professionnels. Publication ne veut pas dire obligation légale. Il y a trois jalons distincts, et les confondre est actuellement l'erreur la plus répandue.

1. Publication par l'ETSI, faite. La norme en version v4.1.1 a été formellement publiée le 2 septembre 2026. Le contenu technique est final et ne changera plus.
2. Citation au Journal officiel de l'UE (JOUE), en attente. C'est l'étape qui compte réellement sur le plan juridique. Tant que la Commission européenne n'a pas cité la v4.1.1 au JOUE, elle ne bénéficie pas de la « présomption de conformité », ce refuge légal qui dit « si vous avez suivi cette norme, vous êtes présumé conforme à la loi ». À l'heure actuelle, c'est toujours la version v3.2.1 (basée sur WCAG 2.1) qui est juridiquement reconnue. La citation est attendue autour du 30 novembre 2026, bien que plusieurs observateurs signalent que cette date n'est pas confirmée par la Commission et pourrait bouger.
3. Transposition dans le droit national de chaque pays. L'EAA est une directive, pas un règlement, donc chaque pays de l'UE rédige sa propre loi de transposition. Certaines de ces lois renvoient à l'EN 301 549 sans préciser de numéro de version. Si c'est le cas de la vôtre, la nouvelle version pourrait devenir votre référence légale automatiquement, sans qu'aucune nouvelle législation ne soit nécessaire de votre côté. Au Luxembourg, le référentiel pour les sites web est le RAWeb, déjà aligné sur cette norme, et censé évoluer avec elle.

Pourquoi s'y mettre dès maintenant malgré tout ? Parce que, quelle que soit la version finalement citée, c'est vers WCAG 2.2 que les choses se dirigent, et construire ou corriger vos produits aujourd'hui sur la base de la 2.1 n'invalidera pas votre travail, mais le rendra incomplet. Si votre loi nationale ne fige pas de numéro de version, les nouvelles exigences pourraient s'appliquer à vous plus tôt que prévu.

Ce qui change concrètement

Le changement principal pour les sites web, applications et documents est le passage de WCAG 2.1 à WCAG 2.2, qui ajoute six nouveaux critères de succès. Nous avons déjà évoqué ces nouveaux critères WCAG 2.2 dans un précédent article. Voici ce que chacun signifie pour un utilisateur réel, pas seulement pour la checklist d'un auditeur.

• Focus non obscurci (AA) : quand vous naviguez au clavier sur une page avec la touche tabulation, l'élément que vous avez sélectionné doit rester réellement visible, pas caché derrière un en-tête collant ou une bannière de cookies.
• Mouvements de glisser-déposer (AA) : tout ce que vous feriez normalement glisser (comme un curseur ou le réordonnancement d'une liste) doit pouvoir se faire sans glisser, pour les personnes incapables d'exécuter ce geste avec précision.
• Taille minimale des cibles (AA) : les boutons et icônes cliquables doivent mesurer au moins 24 par 24 pixels, afin que les personnes ayant une motricité réduite ou de gros doigts sur écran tactile puissent réellement les toucher.
• Aide cohérente (A) : si un lien d'aide, un bouton de chat ou une option de contact apparaît sur plusieurs pages, il doit rester au même endroit relatif à chaque fois, pour que les gens n'aient pas à le chercher.
• Saisie redondante (A) : si un utilisateur vous a déjà donné une information (comme son adresse à une étape précédente), ne le forcez pas à la retaper. Préremplissez-la ou laissez-le simplement la sélectionner à nouveau.
• Authentification accessible minimale (AA) : les étapes de connexion qui s'appuient sur la résolution d'une énigme ou la mémorisation de quelque chose (un CAPTCHA classique, par exemple) doivent proposer une alternative accessible qui ne repose pas sur cette tâche cognitive spécifique.

Deux choses à retenir ici. Premièrement, certains de ces critères (taille des cibles, glisser-déposer, visibilité du focus) résident en grande partie dans votre design system, dans vos boutons, curseurs et composants de mise en page, c'est justement pour ça que les corriger au niveau du composant, plutôt que page par page, est la voie la plus efficace. Deuxièmement, respecter WCAG 2.2 AA est nécessaire mais pas suffisant pour la conformité à la norme européenne. Celle-ci couvre aussi des aspects que WCAG ne traite pas, comme les exigences remaniées de communication en temps réel pour les produits d'appel, de messagerie et de vidéoconférence, où la portée du support du « texte en temps réel » s'est considérablement élargie. Si votre organisation développe ce type de produit, prévoyez un effort nettement plus important sur ce point précis.

Ce qu'il faut faire concrètement cette semaine

Pas besoin d'un groupe de travail de six mois pour démarrer. Quelques actions concrètes :

• Auditez dès maintenant sur la base de WCAG 2.2, pas 2.1, même si votre loi nationale renvoie techniquement encore vers l'ancienne version. La norme WCAG de CheckFox intègre déjà l'ensemble des critères 2.2, vous testez donc dès aujourd'hui l'exigence de demain, pas celle d'hier.
• Vérifiez ce que votre loi nationale référence réellement. Si elle cite l'EN 301 549 sans numéro de version, vous êtes peut-être déjà concerné par la v4.1.1 dès qu'elle sera citée. Si vous êtes au Luxembourg, c'est le référentiel RAWeb qu'il faut surveiller.
• Attendez-vous à de nouveaux constats sur des points qui passaient auparavant. Ce n'est pas une régression de votre produit, c'est la barre qui se relève. Anticipez-le plutôt que d'en être surpris.
• Commencez par le design system, pas par les pages. La taille des cibles, les alternatives au glisser-déposer et la visibilité du focus sont presque toujours plus efficaces à corriger une seule fois dans un composant partagé de bouton, de curseur ou de fenêtre modale, plutôt que dispersées sur chaque page qui les utilise.
• Si vous développez des outils de communication en temps réel (appel, chat, vidéo), commencez dès maintenant à évaluer l'ampleur des changements de la clause 6. C'est la partie la plus susceptible d'exiger un véritable refactoring technique plutôt qu'un simple ajustement de design.
• Concentrez-vous sur vos services, pas seulement sur un site web. C'est pour ça que je propose les Parcours d'Accessibilité avec CheckFox.

Comment CheckFox et moi pouvons vous accompagner dans cette transition

Je suis Geoffrey, la personne qui développe CheckFox, et aussi un auditeur en accessibilité en activité. J'ai construit cette suite d'outils d'accessibilité précisément parce que j'étais fatigué de maintenir des tableurs et des checklists statiques chaque fois qu'une norme évolue, exactement ce qui se passe actuellement avec l'EN 301 549 v4.1.1.

Deux façons de vous aider à naviguer cette mise à jour, selon vos besoins.

Si vous voulez auditer vous-même : CheckFox intègre déjà WCAG 2.2, ainsi que le RGAA, le RAWeb, le RAAM et le RAPDF, tous cartographiés sur l'EN 301 549. Vous n'avez pas besoin de construire votre propre checklist ni d'attendre que quelqu'un mette à jour un PDF. Cartographiez votre parcours utilisateur complet sur votre site web, votre application, vos PDF et vos emails, lancez des audits selon les critères actuels, et générez une déclaration d'accessibilité prête pour un audit en quelques clics.

Quand les référentiels évolueront à nouveau (et ils le feront), le versionnage de CheckFox vous permet de conserver ce que vous avez déjà testé et de montrer une réelle progression dans le temps, plutôt que de repartir de zéro.

Si vous préférez faire réaliser l'audit par quelqu'un d'autre : je propose directement des services d'audit d'accessibilité, couvrant les mêmes référentiels sur lesquels CheckFox est construit : WCAG, RGAA, RAWeb, RAAM et RAPDF. Si vous ne savez même pas encore si l'EAA s'applique à votre organisation, commencez par la auto-évaluation gratuite sur la page EAA, elle prend environ une minute et vous oriente vers les premiers points à examiner. À partir de là, je peux vous aider à cadrer un plan de transition vers la conformité (et au-delà) qui s'adapte à votre calendrier de mises en production, plutôt que de traiter ce sujet comme un exercice d'urgence en novembre.

Dans tous les cas, l'objectif n'est pas de paniquer face à une date de citation qui pourrait bouger. C'est d'arrêter de tester par rapport à une norme déjà en fin de vie, et de commencer à construire vers celle qui arrive. Lancez un audit CheckFox gratuit dès aujourd'hui, ou contactez-moi directement si vous voulez un coup de main pour cadrer ce que cette mise à jour signifie pour votre produit spécifique.

Sources et ressources

• EN 301 549 V4.1.1 Is Now Published: What It Means for Digital Commerce
• The European accessibility standard EN 301 549 has been updated