Beaucoup d'agences et de consultants résument EN 301 549 comme "WCAG 2.1 plus quelques exigences supplémentaires, notamment 11.7 sur les préférences utilisateur".
Spoiler alert : c'est faux. Ou plutôt, ça va l'être.
La section 11 ne s'applique pas au web — elle concerne les logiciels.
Le tableau A.1 de la norme dit autre chose, il est public. EN 301 549 V3.2.1 — Tableau A.1.
Lecture, allons-y.
La méthode
Tout ce qui suit est extrait directement du tableau A.1 d'EN 301 549 v3.2.1 (mars 2021), qui liste l'intégralité des exigences applicables aux contenus web au titre de la directive 2016/2102/EU — et par extension de l'EAA depuis juin 2025.
Pas d'interprétation d'agence. Pas de "notamment". Le tableau, les clauses, les conditions.
Premier constat
C'est presque tout WCAG 2.1.
La section 9 du tableau A.1 reprend l'intégralité de WCAG 2.1 Level AA. Rien à redire, c'est documenté depuis longtemps. Ce qui intéresse ici, c'est ce qui vient en plus — sections 5, 6, 7 et 10.
Deuxième constat immédiat : tous ces critères supplémentaires sont conditionnels. Pas un seul n'est universel. Chaque exigence ne s'applique que si le site embarque une fonctionnalité spécifique. Ce point est systématiquement omis dans les résumés d'agences.
Section 5, fonctionnalités génériques
5.2 — Activation des fonctionnalités d'accessibilité
Condition : le site documente des fonctionnalités d'accessibilité.
Si votre site expose des fonctionnalités d'accessibilité — options d'affichage, raccourcis clavier, mode dyslexie, réduction des animations — ces fonctionnalités doivent pouvoir être activées sans en nécessiter une autre préalablement. Autrement dit : le menu d'accessibilité doit être accessible sans accessibilité préalable. Oui, ça mérite d'être dit explicitement.
5.3 — Biométrie
Condition : le site utilise des caractéristiques biologiques pour identification ou contrôle.
Si reconnaissance faciale, empreinte digitale ou autre identifiant biométrique est utilisé, une alternative non biométrique doit exister. Plateformes bancaires, services RH, authentification forte — le périmètre est ciblé.
5.4 — Préservation des informations d'accessibilité lors de conversion
Condition : le site convertit du contenu d'un format à un autre.
Un outil qui génère des PDF non balisés à partir de HTML structuré échoue ici. Un export Word qui perd les niveaux de titres aussi. La structure et les métadonnées d'accessibilité doivent survivre à la conversion.
Section 6, Communication en temps réel
C'est la section la plus fournie — et la plus inutilement citée pour des sites qui n'ont aucune fonctionnalité de communication voix ou vidéo.
Si votre site n'a pas de communication bidirectionnelle voix ou vidéo intégrée : la section 6 entière ne vous concerne pas.
Pour les autres — télémédecine, collaboration, service client en visio, WebRTC — les exigences sont précises :
6.1 — Bande passante audio pour la parole
Condition : communication voix bidirectionnelle.
La qualité audio doit permettre une parole intelligible. Exigence technique sur le codec et la bande passante, pas sur l'interface.
6.2.x — RTT (Real-Time Text)
Condition : communication voix bidirectionnelle.
Un mécanisme de texte en temps réel doit être disponible simultanément à la voix. Les sous-critères couvrent l'affichage visuellement distinct des flux envoi/réception (6.2.2.1), la direction programmatiquement déterminable (6.2.2.2), l'identification du locuteur si plusieurs participants (6.2.2.3), l'indicateur visuel d'audio actif en contexte RTT (6.2.2.4), et l'interopérabilité avec d'autres systèmes RTT (6.2.3).
6.3 — Identification de l'appelant
Condition : le site fournit une identification d'appelant ou fonction téléphonique équivalente.
L'identification de l'appelant doit être restituée visuellement ou textuellement — numéro ou nom affiché à l'écran, accessible programmatiquement. Un signal sonore seul exclut les utilisateurs sourds.
6.4 — Alternatives aux services vocaux
Condition : le site propose messagerie vocale, serveur vocal interactif ou répondeur automatique.
Une alternative non vocale doit exister pour chacun de ces services. Un Serveur Vocal Interactif sans alternative textuelle ou clavier est non conforme.
6.5.x — Qualité vidéo en temps réel
Condition : communication voix bidirectionnelle avec vidéo temps réel.
Résolution minimale QVGA (320×240) en réception (6.5.2), framerate minimum 12 fps (6.5.3), synchronisation audio/vidéo sous 100 ms (6.5.4), indicateur visuel quand l'audio est actif (6.5.5), identification visuelle du locuteur pour la langue des signes (6.5.6).
Section 7, contenu vidéo
Condition générale : le site diffuse de la vidéo avec audio synchronisé.
7.1.x — Sous-titres
- 7.1.1 Lecture des sous-titres — le lecteur doit les afficher s'ils sont présents dans le flux
- 7.1.2 Synchronisation — décalage maximal acceptable défini
- 7.1.3 Préservation — si la page transmet ou convertit la vidéo, les sous-titres survivent
- 7.1.4 Caractéristiques — couleur, police, taille, positionnement des sous-titres contrôlables par l'utilisateur
- 7.1.5 Sous-titres parlés — option de lecture vocale des sous-titres si l'utilisateur ne peut pas les lire
7.2.x — Audiodescription
- 7.2.1 Lecture — le lecteur doit restituer l'audiodescription si présente dans le flux
- 7.2.2 Synchronisation — l'audiodescription doit être synchronisée avec la vidéo
- 7.2.3 Préservation — survit à la transmission ou conversion
7.3 — Contrôles utilisateur
Condition : le site diffuse principalement des contenus vidéo avec audio.
L'utilisateur doit pouvoir contrôler indépendamment sous-titres et audiodescription — activation, désactivation, réglages.
Section 10, documents téléchargeables
Condition : des documents ou formulaires sont téléchargeables depuis la page web.
La section 10 reprend l'intégralité des critères WCAG 2.1 mais appliqués aux documents (PDF, Word, ODT…) accessibles via la page. Chaque critère WCAG a son équivalent section 10 — 10.1.1.1 pour le contenu non textuel, 10.1.3.1 pour l'information et les relations, etc.
C'est probablement la section la plus sous-évaluée en pratique. Un site conforme WCAG qui propose des PDF non structurés en téléchargement est non conforme EN 301 549. Le PDF est dans le périmètre — et il l'a toujours été.
Ce que la section 11 ne dit pas sur le web
Pour clore le sujet des agences : 11.8 (outils d'édition) n'apparaît pas dans le tableau A.1 — elle concerne les logiciels, pas le web. 11.7 (préférences utilisateur) y figure, inconditionnelle, mais sera retirée du périmètre web dans la v4.1.1. Mettre de la ressource sur ce point aujourd'hui, c'est anticiper une correction déjà actée.
prefers-reduced-motion et le respect de la taille de fonte navigateur restent de bonnes pratiques, couvertes indirectement par WCAG 1.4.4 (Redimensionnement du texte) et 2.3.3 (Animation résultant des interactions).
En résumé
Pour un site web sans communication temps réel, sans biométrie et sans conversion de contenu, les ajouts concrets d'EN 301 549 par rapport à WCAG 2.1 se limitent à :
- 5.2 si des fonctionnalités d'accessibilité sont documentées
- 5.4 si des exports ou conversions de documents sont proposés
- Section 10 si des documents sont téléchargeables — et c'est loin d'être anodin (un PDF de 80 pages non structuré, c'est quoi comme chantier ?).
Le reste est conditionnel à des fonctionnalités que la majorité des sites n'ont pas.
La prochaine fois qu'une agence vous cite la section 11.7 dans un audit web EN 301 549, posez-leur la question : tableau A.1, numéro de ligne ?
Et avec WCAG 2.2 ?
EN 301 549 v4.1.1 — attendue en 2026, pas encore publiée au Journal officiel de l'Union européenne — intégrera WCAG 2.2. La structure conditionnelle des sections 5, 6 et 7 restera inchangée : ce sont des exigences liées aux fonctionnalités du site, pas à la version de WCAG.
Ce qui évoluera, c'est uniquement la section 9 (web) et son équivalent section 10 (documents téléchargeables), avec les 9 critères supplémentaires de WCAG 2.2 Level AA :
- 2.4.11 Focus non masqué (minimum) — un composant qui reçoit le focus ne doit pas être entièrement masqué par un contenu fixe (bandeau cookie, header sticky…)
- 2.4.12 Focus non masqué (amélioré) — le composant focalisé doit être entièrement visible
- 2.4.13 Apparence du focus — le focus visible doit respecter un ratio de contraste et une surface minimale
- 2.5.3 Gestes de glissement — toute action déclenchée par un glissement doit avoir une alternative par pointeur simple
- 2.5.7 Mouvements de glissement — idem, alternative disponible sans geste complexe
- 2.5.8 Taille de la cible (minimum) — 24×24 CSS pixels minimum, ou espacement suffisant autour
- 3.2.6 Aide cohérente — si un mécanisme d'aide est présent sur plusieurs pages, il doit apparaître au même endroit
- 3.3.7 Authentification accessible — pas de test cognitif (recopie de texte, puzzle) sans alternative
- 3.3.8 Authentification accessible (améliorée) — aucun test cognitif, sans exception
En pratique, les critères 2.4.11/2.4.12 (focus masqué par un header sticky) et 3.3.7 (authentification sans CAPTCHA cognitif) sont ceux qui auront l'impact le plus large sur les sites existants. Les cibles tactiles (2.5.8) concernent principalement le mobile et les interfaces à forte densité de composants.
WCAG 3.0 — le troll de service
WCAG 3.0 est au statut Working Draft depuis plusieurs années. Dernière mise à jour : 3 mars 2026. Il abandonne le modèle pass/fail au profit d'un scoring par composant et par type de handicap — une refonte structurelle complète.
L'EAA a mis 6 ans entre sa publication et son entrée en vigueur. EN 301 549 v4.1.1 n'est pas encore au Journal officiel. RGAA 5 sortira sur WCAG 2.2 — déjà en retard dès le premier jour.
Quand WCAG 3.0 sera stable, tout le monde sera encore deux versions derrière. Le millefeuille normatif aura juste gagné un étage — et personne ne sera surpris.