WCAG 3 : le brouillon de septembre 2026 reste un document de travail
Publié le · Rédaction : Plein Accès
Mis à jour le 1er octobre 2026. Événement ou publication source : .
Un document de travail, pas une recommandation finale
Le W3C a publié le 10 septembre 2026 un Working Draft des W3C Accessibility Guidelines 3.0. Le document porte explicitement un statut de travail. Ses propositions peuvent évoluer pendant le processus de normalisation. Il ne doit pas être présenté comme une recommandation finale ni comme le remplacement automatique des références utilisées dans un audit RGAA actuel. La version datée est liée en bas de page pour conserver le contexte exact.
L’acheteur doit distinguer une veille sur WCAG 3 d’une prestation d’évaluation contractuelle. Une offre qui utilise cette seule référence doit expliquer les exigences, les tests et la portée de ses résultats. Le guide du champ RGAA et EAA rappelle pourquoi le cadre juridique et la méthode technique doivent être identifiés séparément.
Suivre les travaux sans modifier le contrat par défaut
Une équipe peut examiner les orientations du projet pour anticiper ses pratiques. Cette démarche reste différente de la réception d’un service selon des critères définis. Conservez les références actuellement retenues dans le contrat, puis demandez une analyse explicite si vous souhaitez ajouter un travail de recherche ou d’expérimentation. Le prestataire doit annoncer les limites d’un contrôle fondé sur des propositions en évolution.
Pour les corrections, le guide de remédiation aide à partir des obstacles observés. Un défaut qui bloque une action peut être traité sans attendre l’issue de WCAG 3. Les résultats de la correction doivent rester rattachés aux exigences et aux scénarios que l’équipe peut vérifier aujourd’hui.
Conserver une veille traçable
Une expérimentation peut être menée sur un composant isolé avec des données fictives. Décrivez la question étudiée et les observations, puis gardez le statut exploratoire du résultat. Ce travail ne doit pas être confondu avec un test de réception déjà convenu. Les équipes peuvent ainsi apprendre des propositions sans attribuer à un brouillon une stabilité qu’il n’annonce pas.
Notez la date du document, son statut et les éléments examinés. Une page de spécification peut être mise à jour ; une version datée permet de retrouver ce qui a servi à une discussion. Demandez au responsable de veille de distinguer les changements de rédaction, les essais techniques et les éventuelles décisions de contrat. Cette trace évite de citer comme règle stable une proposition qui a ensuite changé.
Le cahier des charges permet de demander un livrable de veille séparé si votre projet le nécessite. Pour la déclaration d’accessibilité, le référentiel et les résultats doivent correspondre à la méthode applicable. Cette actualité explique le statut du brouillon de septembre 2026 ; elle ne prédit pas sa date d’adoption et ne certifie pas que ses propositions resteront identiques dans la version finale.