Résumé

  • La version de travail de SVG Accessibility API Mappings publiée le 27 août 2026 succède expressément à celle du 10 mai 2018. L’intervalle de 3 031 jours est réel, tout comme les modifications techniques recensées dans le nouveau texte.
  • Lors de l’affinement public de la prochaine charte SVG, un commentaire du 4 juillet a demandé un jalon concret et un engagement de test. Le correctif d’intégration a remplacé « indéterminé » par « vise à progresser sur les tests ».
  • Cette formulation indique une priorité, mais ne permet pas de constater son accomplissement : elle ne désigne ni révision de référence, ni inventaire de fonctions, ni commit de tests, ni couverture, ni paire d’implémentations, ni responsable, ni date de réexamen.
  • La charte proposée possède déjà de solides critères généraux : tests ouverts, planification précoce et deux implémentations indépendantes et interopérables avant de dépasser Candidate Recommendation. Le chaînon manquant est propre au livrable SVG AAM.
  • Le Processus du W3C ne demande des dates de jalon prévisionnelles que « lorsqu’elles sont disponibles ». L’absence de date ne prouve donc ni violation, ni abandon, ni mauvaise foi.
  • Un reçu public et versionné du jalon de test suffirait à séparer publication, couverture, expérience d’implémentation et décision de maturité, sans créer de nouveau droit de veto.

Trois états publics en dix jours

Le dossier ne raconte pas une immobilité suivie d’un réveil soudain. Il montre trois états qui ne doivent pas être confondus.

Dans la charte SVG actuellement en vigueur, commencée le 27 juin 2024 et valable jusqu’au 30 septembre 2026, SVG Accessibility API Mappings apparaît comme une Working Draft adoptée le 10 mai 2018. Son achèvement prévisionnel est indiqué comme indéterminé. Cette ligne décrit l’état de la charte, pas nécessairement tout le travail éditorial accompli depuis.

La future charte a ensuite été examinée dans l’issue stratégique 559. Le 4 juillet, une intervention publique a précisément rapproché l’ancienneté de la Working Draft et l’échéance indéterminée, puis demandé un jalon concret assorti d’un engagement sur les tests. Le 18 août, le contact d’équipe a annoncé la fin de l’affinement et l’intégration des suggestions.

Le commit 806338 permet de vérifier exactement cette intégration. Trois lignes changent. L’une corrige un lien, une autre élargit la coordination mentionnée avec WHATWG, et la troisième remplace l’état « indéterminé » de SVG AAM par une formulation que l’on peut traduire ainsi : « vise à avancer sur les tests ». La charte figée à ce commit conserve alors le texte de 2018 comme brouillon adopté.

Enfin, le 27 août, une nouvelle Working Draft est publiée. Elle indique elle-même que la précédente publication datait du 10 mai 2018, dont le document reste accessible. Entre les deux : 3 031 jours.

Ce dernier événement est substantiel. La nouvelle version répertorie des changements portant notamment sur le calcul des noms accessibles, les rôles SVG, les correspondances d’éléments et d’attributs, ainsi que certains contenus cachés ou de présentation. Un instantané daté donne aux lecteurs et aux implémenteurs une base commune que ne fournit pas une branche mouvante.

Mais son statut est tout aussi explicite : une Working Draft est publiée pour examen ; sa publication n’implique pas l’approbation du W3C ni de ses membres. Elle peut encore être modifiée, remplacée ou abandonnée. Le nouvel instantané prouve donc qu’un texte nouveau existe. Il ne prouve pas, à lui seul, que ses exigences sont couvertes par des tests, que deux systèmes indépendants les satisfont ou qu’une transition de maturité est justifiée.

Le correctif a amélioré l’orientation, pas la mesure

Dire que le groupe « vise à avancer sur les tests » vaut mieux que laisser une cellule indéterminée sans explication. La phrase révèle une direction et évite une date fictive. Lorsque les ressources, les contributions d’implémenteurs ou le partage du travail entre groupes ne sont pas stabilisés, cette prudence peut être la formulation la plus honnête.

Elle n’est toutefois pas un jalon. Un jalon sert à répondre à une question fermable : quel état devait être atteint, par rapport à quelle base, et quelle preuve permet de le constater ? Ici, le lecteur ne sait pas quelle révision contrôle les tests, quelle liste de fonctions forme le dénominateur, quel commit de la suite est pertinent, ni quel résultat ferait passer « nous avançons » à « cette étape est atteinte ».

Le mot test recouvre d’ailleurs plusieurs faits. Écrire un premier cas de régression est une activité. Adopter un plan de test en est une autre. Relier chaque exigence normative à une assertion crée une mesure de couverture. Exécuter les assertions dans un navigateur précis produit un résultat d’implémentation. Obtenir des résultats comparables dans deux piles réellement indépendantes peut étayer l’interopérabilité. Enfin, un rapport d’implémentation peut réunir l’ensemble pour éclairer une décision de maturité.

Aucun de ces actes n’est négligeable. Aucun ne remplace les autres. Une formulation qui les réunit sous le seul verbe « progresser » ne permet pas de savoir lequel a eu lieu.

La règle générale existe déjà

Le projet de charte ne manque pas de doctrine sur les tests. Il cite une suite de tests et un rapport d’implémentation parmi les livrables. Ses critères généraux de succès demandent des tests publics pour chaque fonction, encouragent un plan de test dès les premiers brouillons et exigent au moins deux implémentations indépendantes et interopérables de chaque fonction avant de dépasser Candidate Recommendation.

Ces engagements contredisent l’idée d’un programme qui ignorerait les tests. Ils rejoignent le Processus du W3C sur l’expérience d’implémentation. Celui-ci ne réduit pas l’expérience à un score. Il demande notamment si toutes les fonctions sont implémentées, si elles interopèrent, si les implémenteurs sont indépendants, si l’usage dépasse l’expérimentation, quelles couches de l’écosystème sont représentées et quels problèmes ont été signalés. Il note aussi l’utilité d’une planification précoce des tests.

Le défaut se situe entre la règle générale et le livrable particulier. « Chaque fonction doit avoir des tests » ne dit pas ce qui compte aujourd’hui comme fonction normative de SVG AAM. « Deux implémentations » ne dit pas quels navigateurs, couches d’accessibilité du système et technologies d’assistance composent les environnements observés. « Une suite ouverte » ne fige pas le commit qui a produit le résultat invoqué.

Un total de tests peut augmenter sans élargir la couverture si les nouveaux cas portent sur un même comportement. Une couverture étendue peut exister sans indépendance si tous les résultats reposent sur le même moteur. Deux produits peuvent afficher un succès non reproductible si les versions et configurations ne sont pas consignées. La charte n’a pas besoin d’une nouvelle ambition ; elle a besoin d’un index vers les preuves auxquelles son ambition s’applique.

« Lorsqu’elles sont disponibles » protège contre la fausse précision

Les exigences du Processus relatives aux chartes mentionnent le périmètre, les critères de succès, la durée, les livrables et les dates prévisionnelles des jalons lorsqu’elles sont disponibles. Ces derniers mots interdisent une conclusion trop facile. Le dossier gelé ne permet pas de qualifier l’absence de date de violation procédurale.

La réserve est sensée. Dans un travail de normalisation, une difficulté découverte tardivement, une priorité d’implémenteur ou la disponibilité de contributeurs peut rendre un calendrier rapidement trompeur. Imposer une date décorative pourrait inciter à réduire artificiellement le périmètre, à déclarer une étape achevée trop tôt ou à accumuler une nouvelle promesse manquée.

Pour autant, l’indisponibilité d’une date n’empêche pas de publier un état. Il est possible de désigner la révision testée, l’inventaire des fonctions, la suite et son commit, les preuves existantes, les lacunes et le prochain événement de réexamen. Si même un rendez-vous calendaire est impossible, le reçu peut l’indiquer et nommer le déclencheur : publication d’une révision, livraison d’un implémenteur, résolution d’une question normative.

Le remède n’est donc pas une date arrachée à la charte. C’est une description vérifiable de l’étape, capable d’assumer que sa date finale reste inconnue.

Une publication n’exécute pas sa propre spécification

La note de Lu Heng sur la primauté du code en fonctionnement fournit ici une discipline de lecture, non une information sur les groupes W3C : publication, recommandation, implémentation, validation et usage doivent rester des états distincts.

Cette discipline évite de minimiser la Working Draft de 2026 au motif qu’elle n’est pas encore une preuve d’interopérabilité. Une publication datée coordonne la relecture, fixe les assertions éditoriales et peut mobiliser les implémenteurs. Elle a une valeur propre. Elle évite aussi l’erreur inverse : prêter au document la cohérence opérationnelle qu’il doit encore démontrer dans des systèmes indépendants. Un texte ne s’exécute pas lui-même.

Pour SVG AAM, la chaîne d’observation peut être particulièrement riche. La spécification décrit le passage de la sémantique SVG vers des API d’accessibilité. Un résultat peut donc dépendre du moteur de navigateur, de la couche d’accessibilité du système d’exploitation, de la technologie d’assistance, de leurs versions et de la configuration. Il ne s’agit pas ici de décider quelles combinaisons sont obligatoires ni de prétendre connaître celles qui réussissent. Il s’agit d’exiger que toute conclusion publique nomme les environnements sur lesquels elle repose.

La collaboration SVG–ARIA rend la garde visible nécessaire

Le dossier public traverse deux groupes et plusieurs emplacements. La page des publications d’ARIA inscrit la Working Draft du 27 août et désigne ARIA comme groupe livreur. La charte SVG proposée prévoit un développement en collaboration avec ARIA. En 2024, un commit du dépôt historique a déplacé le travail de spécification dans le monorepo ARIA tout en gardant l’ancien dépôt ouvert pour les issues et en préservant l’adresse de l’Editor’s Draft. Le répertoire SVG AAM d’ARIA expose aujourd’hui cette garde éditoriale.

Ces faits ne démontrent ni conflit ni transfert contesté d’autorité. Une collaboration et un déplacement de dépôt sont ordinaires. Ils créent cependant un besoin pratique : le reçu doit nommer le groupe ou la personne responsable de chaque action suivante. La responsabilité de la charte, l’édition, la revue des tests et la collecte des résultats peuvent rester distribuées. Elles ne doivent pas devenir introuvables.

Le reçu minimal du jalon

Une page versionnée, reliée à la ligne du livrable, pourrait suffire. Elle contiendrait dix éléments.

Elle commencerait par l’URL de la spécification de référence et une révision immuable. Elle fixerait ensuite l’inventaire des fonctions normatives et sa version, puis le dépôt et le commit de la suite de tests. Elle publierait une correspondance fonction–test distinguant couvert, partiellement couvert, non testé, exclu et bloqué.

Elle identifierait les implémentations, versions et environnements ; présenterait le résultat d’interopérabilité avec les éléments reproductibles ; conserverait les échecs, exclusions et questions ouvertes ; attacherait chaque action suivante à un groupe ou responsable nommé ; indiquerait une date de réexamen ou la raison explicite de son indisponibilité ; et préciserait enfin la décision que l’ensemble peut éclairer — revue d’Editor’s Draft, transition de maturité ou rapport d’implémentation.

Ce reçu ne devrait pas écraser son passé. Une nouvelle version pourrait remplacer l’état courant tout en laissant l’ancien consultable. Un échec peut devenir un succès, une fonction être retirée, une plateforme évoluer. La séquence explique comment la conclusion a été obtenue.

La Working Draft de 2026 mérite d’être reconnue pour ce qu’elle est : un retour substantiel dans le registre de publication et une invitation renouvelée à examiner et implémenter. Le jalon de test mérite la même honnêteté. Il n’a pas besoin de promettre une date inconnue. Il doit rendre visibles la base, les preuves, les lacunes et la prochaine décision.

Sources

  1. Répertoire SVG AAM dans le dépôt ARIA
  2. Projet de charte SVG au commit 806338
  3. Commit 806338 d’intégration des suggestions
  4. Issue stratégique 559 du W3C
  5. Commentaire demandant un jalon de test
  6. Commentaire annonçant la fin de l’affinement
  7. Commit déplaçant SVG AAM vers le monorepo ARIA
  8. Lu Heng, Running-Code Primacy
  9. Charte active du groupe SVG
  10. Publications du groupe ARIA
  11. Processus du W3C : chartes
  12. Processus du W3C : expérience d’implémentation
  13. SVG Accessibility API Mappings, Working Draft du 10 mai 2018
  14. SVG Accessibility API Mappings, Working Draft du 27 août 2026