Résumé

  • La Recommandation ARIA in HTML du 11 août 2026 cite un rapport d’implémentation portant sur trois outils de contrôle de conformité destinés aux auteurs de pages web.
  • La page annonce une dernière mise à jour au 22 mars. Pourtant, le fichier a reçu 311 ajouts et 126 suppressions le 20 mai, puis six changements supplémentaires le 27 mai.
  • Cette chronologie ne démontre aucune violation du Processus du W3C. Elle montre qu’une date d’arrêté des observations et une date de révision de l’artefact ne devraient pas partager la même étiquette.

Mars décrit-il les résultats ou le fichier ?

Le 11 août, le W3C a publié une version mise à jour de sa Recommandation ARIA in HTML. Le texte fixe les règles auxquelles les auteurs doivent se conformer lorsqu’ils emploient WAI-ARIA 1.2 et DPub-ARIA 1.1 sur des éléments HTML. Son objectif principal est explicite : fournir des exigences aux outils qui vérifient le code produit par les développeurs.

Parmi les références placées en tête du document figure un rapport d’implémentation. Il compare le validateur HTML du W3C, ARC Toolkit et IBM Accessibility Checker. Deux phrases en donnent la temporalité : « Last updated 22 March 2026 », puis l’affirmation qu’à cette date les fonctionnalités de la liste avaient été vérifiées face à l’état courant de la spécification et qu’aucune n’était menacée faute d’implémentations.

Pris seul, ce bandeau invite à comprendre que le rapport public n’a plus bougé depuis le 22 mars. L’historique Git précise autre chose. Le commit 89f8e75e9d35, daté du 20 mai, modifie 437 lignes : 311 ajouts et 126 suppressions. Il remplace l’ancienne date d’août 2021 par celle du 22 mars 2026, reformule la conclusion générale sur les fonctionnalités à risque et renouvelle de nombreuses lignes du tableau. C’est aussi à ce moment que la ligne selectedcontent entre dans le fichier.

Une seconde intervention, 7998c77749cf, est enregistrée le 27 mai. Elle change six lignes relatives aux deux formes de l’élément select, désormais décrites comme boîte déroulante et zone de liste. L’étiquette visible reste fixée au 22 mars. Au moment de notre relevé, ce commit du 27 mai est le dernier à avoir touché le rapport.

La situation peut avoir une explication parfaitement saine. Une équipe peut arrêter ses observations en mars, préparer le tableau, le publier en mai, puis corriger sa formulation sans rouvrir la campagne de tests. Dans ce cas, le 22 mars est une date de validité des données et non la dernière révision du fichier. Le problème vient justement de l’expression « dernière mise à jour », qui ne dit pas laquelle de ces deux réalités elle désigne.

selectedcontent rend l’ambiguïté vérifiable

La nouvelle ligne concerne l’élément HTML selectedcontent et les attributs ARIA admis selon son emplacement dans un select personnalisable. Le rapport joint un cas de test et trois tickets publics.

Le validateur du W3C est noté yes. Son ticket a été clos comme terminé le 17 mars 2026. ARC Toolkit apparaît in progress et son ticket était toujours ouvert à la date de coupure. IBM Accessibility Checker est marqué not yet implemented, avec un ticket lui aussi ouvert.

Ces états différents ne suffisent pas à conclure que la Recommandation aurait été publiée sans expérience adéquate. Le Processus du W3C ne fixe pas une formule universelle du type « trois outils sur trois ». Il demande une appréciation plus large : implémentation de chaque fonctionnalité, indépendance et interopérabilité, travaux réalisés au-delà des auteurs du texte, déploiement public, diversité des niveaux de l’écosystème et difficultés signalées. D’autres éléments peuvent donc participer à la décision.

Le tableau n’est pas davantage un certificat de fonctionnement dans les navigateurs et technologies d’assistance. Il suit des contrôleurs de conformité. La spécification impose ses règles aux contrôleurs qui déclarent la prendre en charge, tout en leur permettant d’employer leur propre vocabulaire et leurs propres niveaux de gravité. Un ticket ouvert ne décrit pas forcément un développement non publié ; un yes ne garantit pas l’expérience finale d’un utilisateur.

En revanche, la trace publique établit bien ceci : la ligne a été introduite dans le fichier en mai sous une date affichée de mars. À défaut de deux horloges, la page seule ne permet pas de savoir si le 22 mars correspond à la collecte, à la revue, à la vérification des tickets ou à l’édition du document.

Deux dates qui traversent la période de revue

La distinction compte aussi pour la procédure. Le 7 avril, le groupe ARIA a publié les modifications comme amendements proposés. La page marquait notamment selectedcontent et les nouvelles règles du select personnalisable. L’appel demandait des commentaires, y compris des retours d’implémentation, jusqu’au 8 juin.

Les commits des 20 et 27 mai se situent donc pendant cette période publique. Dans le texte final du 11 août, les ajouts ne sont plus présentés comme des propositions : ils figurent dans l’historique des changements substantiels.

Le Processus autorise cette intégration après traitement des commentaires, démonstration d’une expérience d’implémentation adéquate et satisfaction des autres conditions de la Recommandation. Les pages accessibles ne permettent toutefois pas de relier sans ambiguïté la décision à une révision immuable du rapport et à un arrêté précis des observations. Cette absence de jointure n’invalide pas la décision ; elle limite la capacité de la reproduire.

Un en-tête de provenance à deux horloges

Le correctif tient dans quelques champs. Révision du rapport devrait donner le commit immuable et sa date. Données valables jusqu’au devrait indiquer le dernier jour couvert par les observations. Chaque ligne pourrait ensuite préciser la version de l’outil, le test, le jour d’observation et le vocabulaire du résultat. Enfin, le rapport devrait nommer la version exacte de la spécification évaluée et la transition qui s’est appuyée sur cet ensemble.

Les changements ultérieurs gagneraient à être classés : résultat nouveau, test remplacé, règle réalignée ou simple correction éditoriale. Une preuve arrêtée en mars peut ainsi cohabiter honnêtement avec une présentation améliorée en mai.

Ce dispositif n’ajoute aucun vote et ne retire rien au jugement du groupe ou de l’équipe du W3C. Il empêche seulement le document de faire porter deux significations à une seule date.

Sources