On vous a demandé de vous assurer qu'un site web ou une application est conforme aux WCAG. Puis, un autre document mentionne la norme EN 301 549. L'équipe technique commence alors à se demander quelle norme utiliser et ce qui doit réellement être testé.
Cette confusion est compréhensible. Bien qu'étroitement liées, ces deux normes ont des rôles et des champs d'application différents.
Pour les équipes qui conçoivent ou gèrent des produits numériques, cette distinction est importante, surtout lorsque l'accessibilité doit être intégrée aux processus de conception, de développement, d'assurance qualité et de conformité.
Qu'est-ce que la norme EN 301 549 ?
La norme EN 301 549 est la norme européenne définissant les exigences d'accessibilité applicables aux produits et services des technologies de l'information et de la communication (TIC).
Son champ d'application dépasse le cadre des seuls sites web. Elle couvre les exigences relatives à des technologies telles que les sites web, les documents non web, les logiciels, les applications mobiles, le matériel informatique ainsi que d'autres produits et services TIC.
Cela change la perspective pour une équipe produit.
Si votre organisation gère un service numérique complexe, l'accessibilité doit être prise en compte dans tous les composants pertinents de ce service, et pas seulement sur la page web principale.
Pour les équipes techniques, la norme EN 301 549 fournit des exigences qui peuvent être intégrées aux spécifications, aux processus d'achat, au développement et aux tests.
La Commission européenne précise que cette norme va au-delà des exigences des WCAG. Par conséquent, respecter tous les critères de succès WCAG pertinents ne signifie pas automatiquement que toutes les exigences de la norme EN 301 549 sont couvertes.
Quelle est la place des WCAG ?
Les WCAG (Web Content Accessibility Guidelines) constituent la norme internationale développée par le W3C pour l'accessibilité des contenus web.
Les critères de succès des WCAG sont organisés autour de quatre principes :
- Perceptible
- Utilisable
- Compréhensible
- Robuste
Sous ces principes se trouvent des critères de succès testables, répartis en trois niveaux de conformité : A, AA et AAA.
En pratique, ces critères se traduisent par des exigences très concrètes.
Une image informative doit être accompagnée d'une alternative textuelle appropriée.
Le contenu doit présenter un contraste suffisant.
Les fonctionnalités doivent être utilisables selon les méthodes requises par les critères de succès applicables.
Les formulaires doivent être conçus de manière à ce que les informations et les relations nécessaires aux utilisateurs puissent être déterminées par programme, conformément aux critères pertinents.
La prise de focus au clavier doit être visible et identifiable.
Les composants interactifs doivent être implémentés de façon à ce que les technologies d'assistance puissent recevoir les informations nécessaires à leur sujet.
Soudainement, l'« accessibilité » devient un ensemble d'exigences que les designers, les développeurs et les spécialistes QA peuvent réellement discuter et tester.
La norme EN 301 549 et les WCAG ne sont pas la même chose
C'est l'une des distinctions les plus importantes à comprendre.
Les WCAG se concentrent sur l'accessibilité du contenu web. La norme EN 301 549 possède un champ d'application TIC plus large et intègre les exigences WCAG pour le contenu web au sein de sa structure, en plus d'exigences supplémentaires.
La version de la norme EN 301 549 actuellement pertinente pour les exigences européennes harmonisées en matière d'accessibilité utilise les WCAG 2.1. La Commission européenne précise que les WCAG 2.2 ne sont pas encore utilisés dans une norme EN 301 549 harmonisée par la publication de sa référence au Journal officiel de l'Union européenne.
Cette distinction est importante en 2026.
Mais les WCAG 2.2 existent déjà
Les WCAG 2.2 constituent la dernière version finalisée de la famille WCAG, et le W3C recommande d'utiliser la version la plus récente lorsque les organisations développent ou mettent à jour leurs politiques et pratiques d'accessibilité.
Les WCAG 2.2 ajoutent neuf nouveaux critères de succès par rapport aux WCAG 2.1. Ceux-ci incluent des exigences relatives à l'apparence de la prise de focus, à la taille minimale des cibles, aux alternatives aux interactions par glisser-déposer, à l'authentification accessible et à l'évitement de la saisie redondante d'informations dans certaines situations.
Depuis 2025, les WCAG 2.2 sont également une norme internationale ISO : ISO/IEC 40500:2025.
Pour une équipe technique, cela crée une distinction entre la norme européenne utilisée pour le cadre réglementaire pertinent et la version des WCAG recommandée par le W3C pour le développement actuel de l'accessibilité.
Le W3C explique également que tout contenu conforme aux WCAG 2.2 est aussi conforme aux WCAG 2.1 et 2.0, en raison de la manière dont les versions successives ont été conçues.
Qu'est-ce que cela signifie pour les équipes produit ?
L'accessibilité est plus efficace lorsqu'elle est intégrée aux exigences produit avant le début du développement.
Prenons l'exemple d'un simple formulaire de création de compte.
L'équipe définit les champs et les règles de validation. L'UX définit l'interaction. Le design prépare les composants et leurs états. Le développement les implémente. L'assurance qualité vérifie le résultat.
Si l'accessibilité n'est prise en compte qu'après le lancement, les problèmes découverts peuvent nécessiter des modifications dans plusieurs de ces domaines.
Si les exigences sont définies dès la phase de planification, l'équipe peut discuter des étiquettes, de la navigation au focus, des messages d'erreur, du contraste et de la navigation au clavier dès le départ.
Cela permet également d'éviter que l'accessibilité ne devienne une liste de bugs distincte à corriger après la mise en ligne.
Quels points les équipes UX et design doivent-elles prendre en compte ?
Un bon système de design permet d'éviter que le même problème d'accessibilité ne se répète sur des dizaines de pages.
Les boutons, formulaires, fenêtres modales, éléments de navigation, composants interactifs et états de focus doivent tous être définis en intégrant les exigences d'accessibilité dans leurs spécifications.
Le contraste en est un exemple évident.
Mais l'accessibilité ne se limite pas à la couleur.
Les designers doivent également réfléchir à la manière dont les utilisateurs perçoivent la hiérarchie de l'information, les états des composants, les messages d'erreur et les interactions qui ne dépendent pas d'une méthode de saisie unique.
Un composant peut paraître parfait dans un fichier de design et pourtant poser des problèmes d'accessibilité une fois implémenté.
C'est pourquoi les tests d'accessibilité doivent se poursuivre sur le produit fonctionnel.
Quels points les équipes de développement doivent-elles prendre en compte ?
Le HTML sémantique et la mise en œuvre correcte des composants jouent un rôle direct dans l'accessibilité.
Les développeurs doivent comprendre ce qui se passe lorsqu'un utilisateur délaisse la souris pour naviguer dans l'interface uniquement au clavier.
La manière dont les technologies d'assistance reçoivent les informations est tout aussi importante.
Quel est le nom accessible du composant ?
Quel est son rôle ?
Dans quel état se trouve-t-il ?
Que devient le focus lorsqu'une fenêtre modale s'ouvre ou se ferme ?
Le formulaire peut-il réellement être rempli ?
Ces questions sont bien plus utiles lors du développement que l'exigence vague selon laquelle « la page doit être accessible ».
Que doivent prendre en compte les équipes d'assurance qualité ?
Les tests automatisés sont utiles, mais ils ne peuvent pas couvrir à eux seuls toutes les exigences d'accessibilité.
Le W3C explique que les WCAG sont conçues pour que la conformité puisse être évaluée par une combinaison de tests automatisés et de jugement humain.
C'est là que les tests manuels restent essentiels.
L'assurance qualité permet de tester la navigation au clavier, l'ordre de tabulation et le comportement des composants. Les tests avec des technologies d'assistance ajoutent un niveau de validation supplémentaire.
Les tests automatisés, quant à eux, permettent d'identifier rapidement certains problèmes récurrents sur un grand nombre de pages.
Combiner ces méthodes offre une vision bien plus pertinente que de se fier à un score unique.
Un score d'accessibilité ne dit pas tout
Le tableau de bord affiche 92/100. C'est plutôt encourageant.
Mais que se passe-t-il si le problème restant concerne le bouton qui permet de finaliser un paiement ?
L'impact sur l'utilisateur n'est pas nécessairement proportionnel au nombre total d'erreurs.
C'est pourquoi les équipes devraient également prendre en compte le la gravité d'un problème, le composant affecté et son emplacement au sein d'un parcours utilisateur critique.
Le paiement, l'authentification, la création de compte, le règlement et la réservation sont des exemples où un seul obstacle à l'accessibilité peut empêcher un utilisateur de finaliser une action.
Les priorités de remédiation doivent prendre ce contexte en compte.
L'accessibilité se poursuit après la mise en ligne
Un produit numérique évolue.
De nouvelles pages, de nouveaux composants et de nouvelles intégrations sont ajoutés. L'équipe marketing publie du contenu inédit. Un formulaire est modifié. Le processus de paiement est mis à jour.
Un test effectué il y a six mois décrit le produit tel qu'il existait il y a six mois.
C'est pourquoi votre processus doit inclure des tests après chaque modification pertinente et une surveillance des problèmes susceptibles d'apparaître à mesure que le produit évolue.
Wawsome peut vous aider à identifier les problèmes d'accessibilité détectables automatiquement et à surveiller l'accessibilité de votre site web au fil du temps.
À quoi devrait ressembler un processus d'accessibilité interne ?
Pour une équipe qui gère un produit numérique en continu, l'accessibilité doit intervenir à plusieurs étapes du processus.
Lors de la définition des besoins, au moment où les fonctionnalités sont établies.
Dans le système de design, pour les composants réutilisables.
Lors du développement et de la revue de code, au moment de l'implémentation de ces composants.
Lors de l'assurance qualité, grâce à des tests automatisés et manuels.
Après la mise en ligne, par le suivi et le retest des zones ayant évolué.
Cela transforme les normes EN 301 549 et WCAG, initialement abstraites, en exigences concrètes, tâches de développement et cas de test. que les équipes peuvent réellement utiliser.
FAQ
Dois-je utiliser les WCAG 2.1 ou les WCAG 2.2 ?
La norme EN 301 549 utilise actuellement les WCAG 2.1 dans la version harmonisée pertinente au niveau européen. Le W3C recommande d'utiliser la version la plus récente des WCAG et précise que le contenu conforme aux WCAG 2.2 est également conforme aux WCAG 2.1.
Pour les obligations légales, vous devez vérifier la norme spécifique et le cadre réglementaire applicables au produit ou au service concerné.
Si je me conforme aux WCAG, cela signifie-t-il automatiquement que je suis conforme à la norme EN 301 549 ?
Non. La norme EN 301 549 a un champ d'application plus large. La Commission européenne précise explicitement que le respect des seuls critères de succès des WCAG 2.1 ne suffit pas à présumer la conformité à toutes les exigences pertinentes de la norme EN 301 549.
Puis-je tester automatiquement tous les critères de succès des WCAG ?
Non. L'évaluation de l'accessibilité nécessite également des vérifications faisant appel au jugement humain. Les tests automatisés sont utiles pour les problèmes détectables techniquement et de manière cohérente, mais ils ne peuvent pas remplacer une évaluation manuelle.
À quel moment dois-je tester l'accessibilité ?
Pendant le développement et avant la mise en ligne, puis à nouveau après toute modification susceptible d'affecter l'expérience utilisateur. Pour les produits mis à jour fréquemment, un suivi continu permet aux équipes d'identifier les nouveaux problèmes dès leur apparition.
Par où commencer ?
Si votre équipe gère un site web existant, commencez par identifier les problèmes d'accessibilité détectables dès maintenant. Les résultats d'une analyse initiale constituent un point de départ pour prioriser les tests et les correctifs à venir.
Pour une évaluation complète, les résultats automatisés doivent être complétés par des vérifications manuelles, nécessaires pour les critères qui ne peuvent pas être évalués automatiquement.