WCAG 3 : ce que le brouillon de travail implique pour les sites actuels

Description de l’image : Un brouillon de travail imprimé de WCAG 3 avec des marque-pages autocollants colorés sur un bureau, à côté d’un document WCAG 2.2 — le repère visuel de cet article d’introduction à WCAG 3.

Temps de lecture : 12 minutes

WCAG 3 — la prochaine génération des règles d’accessibilité que le W3C élabore sous le nom de travail Silver depuis 2017 — est encore, à mi-2026, un brouillon de travail du W3C. Ce seul fait est la chose la plus importante à savoir à son sujet. Ce n’est pas une Recommandation, ni une Recommandation Candidate, et rien de ce document ne peut encore être cité par un régulateur, un tribunal ou un responsable des marchés publics avec force juridique. WCAG 2.2 reste la norme contre laquelle le monde réalise actuellement ses audits, et EN 301 549, la Section 508 américaine et les transpositions nationales de la Directive sur l’accessibilité des sites web font toutes référence à WCAG 2.x. Ce que représente WCAG 3, c’est une réécriture architecturale délibérée de la façon dont la conformité en matière d’accessibilité est mesurée — et un aperçu de ce à quoi ressemblera la prochaine décennie d’adoption par les régulateurs, une fois le document stabilisé.

Cet article d’introduction couvre ce qu’est WCAG 3, ce qu’il modifie structurellement, comment fonctionnent ses niveaux de conformité bronze/argent/or proposés, quand la Recommandation Candidate pourrait réalistement apparaître, la tension politique avec WCAG 2.2 (que les régulateurs nationaux sont encore en train d’adopter), et ce que les équipes qui travaillent actuellement avec la version 2.x devraient réellement faire dès maintenant. En bref : lisez le brouillon de travail, ne refactorisez pas pour lui, et considérez tout vendeur promettant une « conformité WCAG 3 » aujourd’hui comme étant soit dans l’erreur, soit en train de vendre quelque chose.

Ce qu’est réellement WCAG 3 — et ce qu’il n’est pas

WCAG 3 est le titre de travail d’une nouvelle piste de Recommandation au sein du Groupe de travail sur les règles d’accessibilité (AG WG) du W3C, distinct de la ligne WCAG 2.x. Le projet a démarré en 2017 sous le nom de projet Silver (le symbole chimique Ag, un clin d’œil à « Accessibility Guidelines ») et le premier brouillon de travail public a été publié en janvier 2021. Le brouillon de travail le plus récent est la version que les lecteurs trouveront à l’URL w3.org/TR/wcag-3.0/ — et le W3C date ce brouillon, comme tous les brouillons précédents, avec une bannière d’en-tête bien visible indiquant « Ce document est un brouillon de travail. Il n’est pas stable et ne doit pas être référencé ou utilisé comme base d’implémentation. »

Cette bannière remplit un rôle réel. Dans le cadre du processus du W3C, un document passe par cinq niveaux de maturité : brouillon de travail, Recommandation Candidate (CR), Recommandation Proposée (PR), Recommandation (REC) et enfin Recommandation Supplantée. WCAG 2.0 a atteint le statut REC en décembre 2008. WCAG 2.1 a atteint le statut REC en juin 2018. WCAG 2.2 a atteint le statut REC en octobre 2023. WCAG 3 n’est pas encore entré en CR — et le W3C a explicitement indiqué que plusieurs questions de conception substantielles doivent encore être résolues avant que cela soit possible. L’état actuel, au vu du dernier brouillon publié, est celui d’un document de recherche et de conception comportant des sections exploitables et des questions ouvertes clairement signalées, et non une spécification stable.

Ce que WCAG 3 n’est pas : il ne remplace pas WCAG 2.2. Le W3C a déclaré que WCAG 2.2 et WCAG 3 coexisteront vraisemblablement pendant une longue période de transition après que WCAG 3 aura atteint le statut de Recommandation. WCAG 3 n’est pas non plus « WCAG 2.3 » — son modèle de contenu, son modèle de conformité et sa structure éditoriale sont suffisamment différents pour que la renumérotation dans la ligne 2.x ait été rejetée dès le début du processus de conception.

Objectif et portée : pourquoi une nouvelle ligne

Trois problèmes structurels avec WCAG 2.x ont conduit à la décision de lancer une nouvelle ligne plutôt que de continuer à incrémenter la numérotation 2.x.

Premièrement, la portée. WCAG 2.x correspond, techniquement, aux règles pour l’accessibilité des contenus web — il cible les contenus web rendus dans un agent utilisateur. Le mandat du Groupe de travail s’est cependant élargi au cours d’une décennie pour couvrir l’ensemble des surfaces de l’accessibilité numérique : applications mobiles natives, bornes interactives, interfaces vocales, réalité virtuelle et augmentée, outils de communication augmentative et alternative (AAC), surfaces d’IA conversationnelle. WCAG 3 est conçu dès le départ pour être agnostique quant au contenu et à la plateforme, avec la même règle s’appliquant à une page web, un écran d’application native, un flux vocal et un dialogue de borne interactive sans obliger les équipes à rédiger trois déclarations de conformité différentes contre une règle dont le nom dit encore « Web ».

Deuxièmement, le modèle de conformité. La conformité WCAG 2.x est binaire : chaque critère de succès applicable est soit réussi soit échoué, et un seul échec sur un seul critère AA fait chuter la déclaration de conformité de la page. Cela fonctionne bien pour les critères nets au niveau de l’interface comme « utiliser des titres sémantiques » — cela fonctionne moins bien pour les critères où la barrière sous-jacente est graduée plutôt que catégorielle, comme la complexité du langage, la charge cognitive ou la clarté d’un message d’erreur. WCAG 3 introduit des résultats notés afin qu’une page puisse obtenir un résultat mesurément meilleur sur, disons, la « clarté du langage » sans imposer le choix binaire qu’exige la version 2.x.

Troisièmement, les utilisateurs encore mal servis. WCAG 2.x présente des lacunes bien documentées pour les utilisateurs ayant des déficiences cognitives, les utilisateurs peu alphabétisés, les utilisateurs s’appuyant sur des dispositifs AAC, les utilisateurs d’interfaces vocales, les personnes sourdes-aveugles qui naviguent avec un afficheur braille actualisable, et les modalités émergentes de technologies d’assistance comme le suivi oculaire et les interfaces cerveau-ordinateur. Les critères de succès 2.x peuvent être appliqués à ces utilisateurs — mais ils ont été rédigés en gardant principalement à l’esprit les utilisateurs de lecteurs d’écran, de logiciels de grossissement, de navigation au clavier uniquement et de basse vision. L’architecture des règles de WCAG 3 invite explicitement des contributions pour les modalités cognitives, vocales, AAC et de technologies d’assistance émergentes en tant que cibles de premier ordre.

Changements clés : des résultats, pas des critères de succès

Le changement le plus structurant de WCAG 3 — celui dont tous les autres découlent — est le passage des critères de succès aux résultats.

Un critère de succès WCAG 2.x est un énoncé binaire et testable. 1.4.3 Contraste (Minimum) stipule : le texte et les images de texte ont un rapport de contraste d’au moins 4,5:1, avec deux exceptions spécifiques. Une page satisfait soit au critère soit elle ne le satisfait pas. C’est excellent pour les tests reproductibles et les usages adversariaux (contentieux, audit, marchés publics) mais pénalisant pour les critères où le besoin utilisateur sous-jacent ne se divise pas clairement en réussite/échec.

Un résultat WCAG 3, dans le brouillon actuel, est un énoncé testable associé à une ou plusieurs méthodes qui décrivent comment vérifier le résultat et comment noter le score. Les résultats peuvent être binaires là où le binaire est la bonne forme (un champ de formulaire a soit une étiquette soit il n’en a pas), mais ils peuvent aussi être notés sur une échelle numérique là où le besoin utilisateur sous-jacent est gradué (dans quelle mesure ce paragraphe est-il lisible ; dans quelle mesure cet état d’erreur est-il récupérable ; dans quelle mesure cette navigation est-elle prévisible). Le résultat de conformité pour un produit est ensuite calculé à partir de l’ensemble des résultats plutôt que conditionné au passage de chaque critère.

Plusieurs autres changements architecturaux en découlent :

• Les règles comme unité organisatrice. WCAG 3 regroupe les résultats sous des règles (qui correspondent approximativement à la couche principes-et-règles de WCAG 2.x, mais sont rédigées de manière plus déclarative).
• Des méthodes, pas des techniques. WCAG 2.x dispose de techniques informatives qui suggèrent comment satisfaire un critère de succès. WCAG 3 dispose de méthodes normatives qui décrivent comment un résultat est vérifié. Le passage d’ « informatif » à « normatif » est important : cela signifie que la procédure de test accompagne la règle plutôt que d’être un complément séparé et discutable.
• Tests atomiques et holistiques. Certains résultats sont testés au niveau atomique (un élément, une règle) et d’autres sont testés de manière holistique sur une vue ou un flux de tâches entier. Les résultats liés à la charge cognitive et à la clarté du langage sont intrinsèquement holistiques ; les résultats liés au contraste et à l’étiquetage sont intrinsèquement atomiques. WCAG 3 explicite cette distinction dans la méthode.
• Catégories de besoins fonctionnels. Le brouillon introduit les besoins fonctionnels — vision, audition, cognition, parole, mobilité, multi-sensoriel — comme axe transversal. Chaque résultat est associé aux besoins fonctionnels qu’il adresse, de sorte qu’un testeur ou un régulateur peut demander « montrez-moi tout ce qui concerne les utilisateurs ayant des besoins cognitifs » sans relire l’intégralité du document.

Niveaux de conformité : bronze, argent, or

Là où WCAG 2.x comporte trois niveaux de conformité — A, AA, AAA — WCAG 3 propose trois niveaux de conformité : Bronze, Argent et Or. Ces appellations ne sont délibérément pas des lettres et ne sont délibérément pas cumulatives par règle ; elles indiquent que les niveaux supérieurs reflètent une expérience significativement meilleure pour les utilisateurs, et non « le même produit avec plus de cases cochées ».

Bronze est le niveau de conformité minimum. Il est destiné à correspondre, grosso modo, à « l’équivalent WCAG 2.x AA » — c’est-à-dire qu’un produit conforme Bronze ne devrait pas être substantiellement moins bon que le produit conforme AA d’aujourd’hui. La conformité Bronze exige de réussir toutes les erreurs critiques (les résultats signalés dans le brouillon comme des barrières fondamentales — par exemple, l’absence de texte alternatif sur des images informatives), et d’atteindre un seuil défini sur le score des résultats du produit. Le brouillon propose que les erreurs critiques restent binaires même dans le modèle noté : toute erreur critique bloque la conformité Bronze quelle que soit la réussite du produit par ailleurs.

Argent est le niveau intermédiaire et est destiné à correspondre, grosso modo, à un produit solide AA-plus — meilleur que le seuil WCAG 2.x AA mais pas encore au niveau AAA. Le niveau Argent exige généralement un seuil plus élevé sur les mêmes résultats notés, plus la réussite de résultats supplémentaires non requis au niveau Bronze. Les seuils précis sont encore en consultation dans le brouillon de travail.

Or est le niveau le plus élevé. Il est destiné à représenter un produit qui a été conçu et testé pour l’ensemble des besoins fonctionnels couverts par la règle, et pas seulement ceux que les critères AA de la version 2.x traitaient principalement. Or est le niveau où les résultats cognitifs, vocaux, AAC et de technologies d’assistance émergentes ont le plus de poids, car ce sont les groupes d’utilisateurs pour lesquels la conformité 2.x ne produit pas actuellement un résultat comparable.

Deux propriétés importantes du modèle de niveaux méritent d’être notées. Premièrement, la portée est par vue ou par flux, et non par page : un produit peut présenter différents niveaux de conformité sur différentes surfaces, ce qui est plus honnête que le modèle page par page de WCAG 2.x pour les applications complexes. Deuxièmement, la déclaration de conformité est associée aux méthodes utilisées pour la vérifier — ainsi, une déclaration Argent sous WCAG 3 devrait être reproductible par un autre testeur suivant les mêmes méthodes, d’une manière que les déclarations WCAG 2.x AA (qui reposent fortement sur le jugement du testeur aux marges) ne permettent souvent pas.

Modalités émergentes de technologies d’assistance

L’un des engagements éditoriaux majeurs du projet WCAG 3 est le support de premier ordre pour les modalités de technologies d’assistance que WCAG 2.x n’a historiquement adressées qu’indirectement.

L’accessibilité cognitive est la plus grande de ces extensions. Le brouillon actuel intègre des travaux sur les résultats précédemment développés dans le cadre du Groupe de travail sur l’accessibilité cognitive du W3C (le document Making Content Usable for People with Cognitive and Learning Disabilities). Les résultats dans ce domaine portent sur la clarté du langage, la prévisibilité de la navigation, le soutien à l’orientation et au guidage, la prévention et la récupération des erreurs, et la minimisation de la charge cognitive inutile. Beaucoup de ces résultats sont notés plutôt que binaires — il n’y a pas de réussite/échec nette pour « cette phrase est-elle suffisamment lisible » — et c’est le cas pour lequel le modèle de conformité noté a été conçu.

Les interfaces vocales et conversationnelles sont explicitement dans le périmètre. Les résultats portent sur la reconnaissance des invites vocales, la découvrabilité des commandes vocales, le chemin de récupération en cas de mauvaise reconnaissance vocale et l’équivalence entre l’interaction vocale et visuelle dans les interfaces à double modalité. C’est la partie du brouillon où l’architecture de règles agnostique à la plateforme est la plus importante : un flux purement vocal sur une enceinte connectée ne peut pas être testé de manière significative contre les critères de succès « contenu web » de WCAG 2.x, mais il peut être testé contre des résultats WCAG 3 rédigés pour être agnostiques à la modalité.

Les utilisateurs AAC (communication augmentative et alternative) — personnes qui communiquent principalement via des tableaux de symboles, des systèmes d’échange d’images ou des dispositifs de génération de parole — sont explicitement adressés dans les cibles de recherche utilisateur du brouillon. Les résultats concernent ici la cohérence des symboles, le soutien de l’entrée AAC comme mode d’interaction de premier ordre, et la prévisibilité cognitive des états de dialogue qu’un utilisateur AAC doit naviguer.

Les technologies d’assistance émergentes — suivi oculaire, interfaces à contacteur, interfaces cerveau-ordinateur, suivi de la tête et les surfaces d’assistance des dispositifs de réalité mixte — sont nommées dans la feuille de route du brouillon. La position de travail du Groupe de travail est que l’architecture des règles devrait accommoder ces modalités sans exiger que le document les énumère toutes ; l’axe des besoins fonctionnels est l’un des mécanismes permettant cela.

Calendrier : quand la Recommandation Candidate pourrait-elle arriver

La réponse honnête est que personne en dehors de l’AG WG ne peut donner une date fiable, et personne à l’intérieur n’en a publié une. Le processus du W3C est fondé sur le consensus, et les questions de conception encore ouvertes dans WCAG 3 — la méthodologie de notation précise, les seuils exacts pour Bronze/Argent/Or, le format de la déclaration de conformité, la testabilité des résultats cognitifs, la relation avec WCAG 2.2 pendant la transition — sont non triviales. Les brouillons de travail dans toute lignée de normes peuvent rester à ce niveau de maturité pendant des années.

Ce qui peut être dit avec une confiance raisonnable, c’est la forme du chemin. La Recommandation Candidate est la prochaine étape de maturité après le brouillon de travail actuel, et on ne peut entrer en CR qu’une fois que le Groupe de travail aura résolu les questions ouvertes actuellement signalées dans le brouillon et démontré que les résultats proposés sont testables (un processus que le W3C appelle la révision « feature-at-risk » et qui nécessite une expérience d’implémentation substantielle pour être validé). Plusieurs déclarations publiques de membres du personnel du W3C au cours de 2025 ont indiqué que la CR pour WCAG 3 était encore loin et que le projet devrait être traité comme nécessitant des années plutôt que des mois avant une spécification stable.

Une fois la CR entrée, le calendrier standard prévoit au moins une période d’implémentation de plusieurs mois durant laquelle le groupe de travail recueille des preuves que les résultats ont été vérifiés sur des produits réels. La PR suit. La REC suit. Après la REC, le lent processus d’adoption par les régulateurs commence — et il a historiquement été mesuré en années, pas en mois. La citation dans le style de l’EAA de WCAG 3 via une révision d’EN 301 549 (une V5 ou ultérieure) est, dans toute lecture réaliste, une perspective de la fin des années 2020 plutôt qu’une perspective immédiate.

La tension avec WCAG 2.2

WCAG 3 se trouve dans une tension politique réelle avec WCAG 2.2, et cette tension est le sous-texte de toute discussion sur WCAG 3 au sein de l’industrie. WCAG 2.2 a atteint le statut de Recommandation en octobre 2023 — une norme publiée, stable et citable que les régulateurs nationaux sont encore en train d’adopter. Certains l’ont déjà adoptée. D’autres non. La prochaine V4 d’EN 301 549 intégrera WCAG 2.2 ; la Section 508 américaine est en cours de révision qui pointe vers WCAG 2.x ; la défense dans les contentieux privés aux États-Unis cite WCAG 2.x par défaut.

La tension ne porte pas vraiment sur le document qui est « meilleur ». Elle porte sur la capacité des régulateurs à adopter une norme encore en mouvement — et sur la question de savoir si les équipes qui viennent d’investir dans la conformité WCAG 2.2 doivent croire qu’un cadre différent est imminent. La position déclarée du Groupe de travail est que les deux lignes ne sont pas à somme nulle : WCAG 2.2 reste la norme opérationnelle pour l’adoption réglementaire, et WCAG 3 est la prochaine génération qui, avec le temps, lui succédera. Les deux documents seront maintenus en parallèle côté W3C une fois WCAG 3 ayant atteint le statut de Recommandation, et le W3C a signalé que la transition sera délibérément assez longue pour que les équipes ne soient pas contraintes à une migration forcée.

En pratique, cela signifie trois choses. Le travail d’audit WCAG 2.2 n’est pas perdu — les barrières d’accès sous-jacentes qu’il identifie ne disparaissent pas sous WCAG 3, elles sont réorganisées en résultats. Les régulateurs en cours d’adoption de WCAG 2.2 ne commettent pas d’erreur — ils font le travail qui doit être fait cette décennie. Et les vendeurs qui commercialisent une « conformité WCAG 3 » contre un brouillon de travail donnent une représentation erronée de la maturité de la norme ; aucune déclaration de conformité contre un brouillon de travail instable n’a de sens.

WCAG 2.2 vs WCAG 3 : comparaison des dimensions

Implications pour les sites 2.x aujourd’hui

La question pratique pour toute équipe gérant un site, une application ou un produit sous WCAG 2.x aujourd’hui est : devons-nous faire quelque chose différemment parce que WCAG 3 arrive ? La réponse se décompose en trois points.

Auditer et corriger selon WCAG 2.2 AA. C’est la norme que les régulateurs adoptent, qu’EN 301 549 V4 intégrera, et que les tribunaux dans les juridictions ayant des droits d’action privés citent. Un audit WCAG 2.2 AA bien réalisé en 2026 n’est pas un travail à jeter — les barrières sous-jacentes resteront des barrières sous WCAG 3, et l’effort de correction pour les résoudre est le même. Les équipes qui ont repoussé le travail sur la version 2.2 dans l’espoir de « faire WCAG 3 à la place » choisissent un résultat moins bon sur un calendrier plus long.

Lire le brouillon de travail WCAG 3, ne pas refactoriser pour lui. Le brouillon est une fenêtre utile sur la direction que prend la norme et les besoins utilisateurs que la prochaine décennie mettra en avant. Les équipes devraient le lire (il est disponible gratuitement sur le site TR du W3C), le partager en interne avec les équipes de conception et d’ingénierie, et l’utiliser pour amorcer des conversations sur l’accessibilité cognitive, les interfaces vocales et l’AAC. Elles ne devraient cependant pas commencer à rédiger des déclarations de conformité contre lui, à rédiger des clauses de marchés publics contre lui, ou à restructurer des programmes d’audit pour l’anticiper. Le brouillon n’est pas assez stable pour aucune de ces activités.

Investir dans la capacité de recherche utilisateur et de recherche en conception que WCAG 3 exigera. Les résultats notés, holistiques et agnostiques à la modalité qu’introduit WCAG 3 ne peuvent pas être vérifiés par des outils d’analyse automatisée seuls. Ils ont besoin de recherche en conception avec des utilisateurs ayant des déficiences cognitives, avec des utilisateurs AAC, avec des utilisateurs d’interfaces vocales. Les équipes qui seront prêtes lorsque WCAG 3 atteindra le statut de Recommandation ne sont pas celles dotées des outils automatisés les plus sophistiqués — ce sont celles qui ont établi des relations de recherche utilisateur couvrant l’ensemble des besoins fonctionnels. Construire ces relations maintenant est un investissement qui porte ses fruits sous les deux normes.

WCAG 3 dans le graphe des normes que vous connaissez déjà

Si vous avez suivi l’arc des normes d’accessibilité — de la Section 508 à EN 301 549, du WCAG 2.0 du W3C à 2.1 puis à 2.2 — WCAG 3 est la prochaine génération de cet arc, actuellement en cours de conception. C’est le document que la communauté des normes construit parce que les limites du modèle de critères de succès binaires, axé sur le web, de WCAG 2.x sont devenues difficiles à ignorer alors que l’accessibilité numérique s’est étendue aux interfaces mobiles, vocales, AAC et cognitives. C’est aussi, aujourd’hui, un brouillon de travail instable qu’aucun régulateur ne peut encore citer et contre lequel aucun vendeur responsable ne peut encore revendiquer de conformité.

Pour les praticiens qui planifient le reste de cette décennie : WCAG 2.2 est la norme à auditer, EN 301 549 V4 est l’instrument de marchés publics à aligner, et WCAG 3 est le document à lire un vendredi après-midi pour comprendre où va le travail. La bonne posture est une patience informée — gardez WCAG 3 dans votre champ de vision périphérique, faites le travail WCAG 2.2 devant vous, et construisez la capacité de recherche utilisateur qui importera quelle que soit la norme citée par les auditeurs dans cinq ans. Pour le prochain épisode de cette série d’introduction, voir l’enquête sur le taux d’adoption de WCAG 2.2 qui suit quels régulateurs nationaux ont déjà franchi le cap.