Checklist EN 301 549 : définir le périmètre, tester et documenter l'accessibilité (v4.1.1)

Avec la version 4.1.1 de la norme EN 301 549, les exigences applicables aux pages web, aux documents et aux logiciels passent au WCAG 2.2. Cette checklist vous aide à repérer les clauses qui concernent votre produit, à tester chaque domaine et à garder une trace de ce que vous avez vérifié.

Pour consulter la nouvelle version, ouvrez la norme EN 301 549 v4.1.1 (PDF), publiée par l'ETSI le 2 septembre 2026.

Ce qu'il faut retenir

• La v4.1.1 ajoute six critères du WCAG 2.2 : focus visible et non masqué, mouvements de glissement, taille des cibles, aide cohérente, saisie redondante et authentification accessible. Le critère 4.1.1 Parsing disparaît.

• À ce jour (octobre 2026), aucune norme harmonisée n'est citée au titre de la directive européenne sur l'accessibilité. La v3.2.1 est citée au titre de la directive sur l'accessibilité des sites internet, et la citation de la v4.1.1, qui fait correspondre ses clauses aux exigences de la directive, est attendue. Tester dès maintenant avec le WCAG 2.2 vous prépare aux deux cas.

• La plus grande partie de la norme ne concerne pas le web. Documents, logiciels, applications mobiles, matériel et communication en temps réel ont chacun leurs propres clauses.

• Les preuves comptent autant que les corrections. Chaque résultat doit indiquer la version testée, la date, le périmètre et la méthode.

La norme EN 301 549 fixe les exigences d'accessibilité des produits et services TIC en Europe. C'est la référence technique que la plupart des équipes utilisent pour la directive européenne sur l'accessibilité (EAA).

Qu'est-ce qui change avec la v4.1.1, et sur quelle version tester ?

Publiée en septembre 2026, la version 4.1.1 apporte quatre changements principaux :

• Les pages web, les documents et les logiciels passent du WCAG 2.1 au WCAG 2.2 : six nouveaux critères de niveau A et AA, et la suppression du critère 4.1.1 Parsing.

• Les exigences sur les préférences des utilisateurs s'appliquent désormais aussi aux pages web et aux documents, et plus seulement aux logiciels.

• Les exigences sur le texte en temps réel couvrent maintenant la conversation totale, où vidéo, texte et voix fonctionnent en même temps.

• Les clauses de la norme sont reliées directement aux exigences de la directive européenne sur l'accessibilité (annexe ZB).

Notre guide de la norme EN 301 549 détaille chacun de ces changements.

Testez dès maintenant avec le WCAG 2.2 niveau AA, et indiquez dans chaque rapport la version utilisée.

• La v3.2.1 repose sur le WCAG 2.1. Elle est citée au Journal officiel de l'Union européenne au titre de la directive sur l'accessibilité des sites internet, qui s'applique aux sites et applications du secteur public.

• À ce jour (octobre 2026), aucune norme harmonisée n'a été citée au titre de la directive européenne sur l'accessibilité. La norme EN 301 549 reste une référence technique utile, mais elle ne confère pas actuellement de présomption de conformité à cette directive. La v4.1.1 relie ses clauses aux exigences de la directive (annexe ZB), et sa citation est attendue.

• Si vous êtes un organisme public qui déclare sa conformité à la v3.2.1, conservez un résultat pour le critère 4.1.1 Parsing jusqu'à ce que la v4.1.1 la remplace.

Et le RGAA ? En France, les organismes publics et les grandes entreprises auditent leurs sites avec le RGAA. La version actuelle, le RGAA 4.1.2, s'appuie sur le WCAG 2.1, et restera basée dessus jusqu'à la publication du RGAA 5. Notre comparatif RGAA vs WCAG explique comment les deux référentiels s'articulent.

Avant de commencer : quelles clauses concernent votre produit ?

La norme EN 301 549 est organisée par type de technologie. La première étape consiste donc à identifier les chapitres qui s'appliquent. Un simple site web n'est pas concerné par les clauses sur le matériel ou les services de relais. Une application bancaire avec appels vidéo, elle, en déclenche plusieurs.

La clause 4 définit des exigences de performance fonctionnelle, comme l'usage sans la vue ou avec une portée limitée, qui valent pour tous les chapitres. Pour les applications, les logiciels et le matériel, distinguez aussi les fonctions ouvertes (compatibles avec la technologie d'assistance de l'utilisateur, par exemple un lecteur d'écran) des fonctions fermées (comme une borne de billetterie, à laquelle on ne peut pas brancher son propre outil). Les fonctions fermées suivent les exigences de la clause 5.1, par exemple une sortie vocale intégrée.

Notez ce périmètre par écrit. C'est la première pièce de votre dossier de preuves.

Comment utiliser cette checklist

Combinez un scan automatisé et des tests manuels. Un scan repère vite les barrières numériques répétitives, comme une alternative textuelle absente ou un contraste trop faible. En revanche, il ne peut pas juger si une alternative a du sens, ni si un composant sur mesure fonctionne avec un lecteur d'écran.

Testez vos principaux parcours utilisateurs plutôt que des pages isolées : inscription, connexion, recherche, paiement, contact.

Utilisez le clavier seul, un lecteur d'écran (NVDA ou JAWS sous Windows, VoiceOver sous macOS et iOS, TalkBack sous Android), le zoom et la loupe d'écran.

Attribuez à chaque point l'un de ces quatre résultats :

• Conforme : testé, l'exigence est respectée.

• Non conforme : une barrière numérique est avérée.

• Non applicable : l'exigence ne s'applique pas. Notez pourquoi.

• Non testé : la preuve reste à apporter.

Pour chaque résultat, consignez :

• les versions de la norme EN 301 549 et du WCAG testées

• le périmètre

• le produit et sa version

• la date du test

• la personne qui a testé

• le navigateur ou l'appareil, et une capture d'écran ou une référence de ticket

Checklist pour les sites web (clause 9)

La clause 9 applique le WCAG 2.2 niveaux A et AA aux pages web. Le WCAG 2.2 ajoute neuf nouveaux critères de succès, dont six de niveau A ou AA : ce sont eux que reprend la v4.1.1. Ils sont signalés Nouveau en v4.1.1 dans le tableau, et ce sont les manques les plus fréquents dans un audit réalisé avec le WCAG 2.1.

Checklist pour les documents (clause 10)

La clause 10 reprend la plupart de ces critères pour les documents téléchargeables : PDF, fichiers Word, tableurs. Commencez par ceux dont les gens ont besoin pour faire une démarche, comme les contrats, les factures, les formulaires et les conditions générales.

Notre guide explique comment rendre un PDF accessible. Pour les grands volumes, nos solutions PDF prennent en charge le test et la remédiation.

Checklist pour les applications et logiciels (clause 11)

Une application native se teste sur chaque plateforme, avec ses propres technologies d'assistance. Pour un exemple concret, lisez notre étude de cas sur les applications de Lavazza.

Checklist pour les appels, la vidéo et le matériel (clauses 5 à 8)

Le matériel se teste sur l'appareil réel, dans son installation définitive, pas seulement sur un plan ou en simulation. Nos audits matériels et logiciels couvrent ces vérifications.

Checklist pour la documentation et l'assistance (clause 12)

Corriger, retester et tenir vos preuves à jour

Corrigez d'abord les barrières numériques qui bloquent une démarche, comme la connexion, le paiement ou l'envoi d'un formulaire. Les problèmes esthétiques passent après. Retestez ensuite les mêmes parcours avec la même méthode, puis mettez le résultat à jour.

Mettez à jour votre déclaration d'accessibilité et votre rapport de conformité (ACR, sur le modèle du VPAT édition UE) quand vous passez à la v4.1.1. Les deux doivent mentionner la version à laquelle ils se réfèrent.

Notre guide pour faire un audit d'accessibilité numérique décrit toute la démarche, et nos conseils pour rendre un site internet accessible montrent la suite.

Notre audit d'accessibilité de votre site web s'accompagne d'une phase de remédiation pour guider vos développeurs dans les corrections, tandis que nos tests utilisateurs avec des personnes en situation de handicap révèlent ce qu'un expert ne voit pas toujours.

Questions fréquentes sur les tests EN 301 549

Faut-il une checklist EN 301 549 ou une checklist pour la directive européenne sur l'accessibilité ?

Le plus souvent, les deux, car elles ne servent pas à la même chose. La checklist EN 301 549 vérifie que votre produit est techniquement accessible. Celle de la directive couvre vos obligations d'entreprise : périmètre, déclaration d'accessibilité, moyens de contact, documentation. Commencez par le test technique, puisque le reste s'appuie sur ses résultats.

Faut-il tout retester pour la v4.1.1 ?

En général, non. Si vous disposez d'un audit récent au niveau AA du WCAG 2.1, testez les lignes « Nouveau en v4.1.1 » et les changements de la v4.1.1 qui concernent votre produit, puis mettez à jour la version dans vos rapports.

À quelle fréquence refaire un audit EN 301 549 ?

Prévoyez un audit complet au moins une fois par an, et retestez les parcours concernés après chaque mise en production importante qui touche la navigation, la connexion, les formulaires ou les gabarits. Entre deux audits, une surveillance automatisée détecte les nouvelles barrières au fil des changements de contenu.

Quand la v4.1.1 deviendra-t-elle la référence légale ?

Quand la Commission européenne la citera au Journal officiel de l'Union européenne, ce qui est attendu fin 2026.

Que faut-il avoir fait avant de déclarer la conformité EN 301 549 ?

1. Chaque clause est marquée applicable ou non applicable, avec une justification pour chaque « non applicable ».

2. Chaque point applicable a été testé manuellement, pas seulement par un scan.

3. Les six lignes « Nouveau en v4.1.1 » ont un résultat.

4. Les barrières qui bloquent une démarche sont corrigées et retestées.

5. Chaque résultat est accompagné de sa preuve.

6. Votre déclaration d'accessibilité et votre ACR correspondent aux résultats.

Vous voulez savoir où en est votre site aujourd'hui ? Commencez par une évaluation gratuite sur notre plateforme de conformité en accessibilité, puis échangez avec notre équipe sur un audit EN 301 549 complet.