Restaurer une révision d’article efface un attribut aria-label ajouté à la main

« Cette révision a été restaurée » : le message de confirmation de WordPress s’affiche, rassurant, après qu’un rédacteur a récupéré un paragraphe supprimé par mégarde trois jours plus tôt. Ce qu’il ne dit pas, c’est qu’un attribut aria-label ajouté à la main sur un bloc HTML personnalisé, entre-temps, vient de repartir avec l’ancienne version du contenu.

Ce billet explique ce mécanisme, rencontré sur un article enrichi manuellement en code HTML pour améliorer l’accessibilité d’un composant de navigation intégré au corps du texte. Il ne traite pas de la restauration de médias, comportement distinct qui suit sa propre logique dans la bibliothèque.

Symptôme

L’article concerné contient un bloc HTML personnalisé, structuré ainsi dans l’éditeur, pour offrir un jeu de liens de navigation rapide vers d’autres articles de la même série :

<nav aria-label="Articles de la série accessibilité WordPress">
  <ul>
    <li><a href="/article-precedent/">Article précédent</a></li>
    <li><a href="/article-suivant/">Article suivant</a></li>
  </ul>
</nav>

Un rédacteur, en modifiant un paragraphe voisin, restaure ensuite une révision plus ancienne pour récupérer une phrase supprimée par erreur la veille. La restauration fonctionne comme prévu pour le texte visé. Mais l’attribut aria-label, ajouté deux jours après la révision restaurée, n’existait pas encore dans cette version : il disparaît donc du bloc, sans avertissement ni message spécifique.

Diagnostic

Le système de révisions de WordPress ne fonctionne pas par différence ciblée sur un attribut ou un fragment précis : chaque révision représente un instantané complet du contenu de l’article, stocké dans la table wp_posts avec le type revision. Restaurer une révision remplace intégralement le contenu courant par celui de l’instantané choisi, quel que soit le nombre de modifications intervenues entre les deux, y compris celles qui n’ont aucun rapport avec la raison de la restauration.

Concrètement, l’historique des révisions ressemblait à ceci au moment de l’incident :

Révision A (lundi)   : paragraphe supprimé par erreur présent, aria-label absent
Révision B (mardi)   : paragraphe corrigé manuellement, aria-label absent
Révision C (mercredi): aria-label ajouté au bloc de navigation
Révision D (courante): paragraphe supprimé par erreur, aria-label présent

Le rédacteur, en cherchant à récupérer le contenu de la révision A pour le paragraphe, restaure en réalité l’intégralité de cette révision, y compris l’absence d’aria-label qu’elle contenait. Rien dans l’interface de comparaison des révisions n’attire l’attention sur cette perte, car l’écran de comparaison de WordPress se concentre sur le texte visible, pas sur les attributs HTML des balises qui l’entourent.

Correctif

La récupération, une fois le problème identifié, s’est faite en deux temps. D’abord une restauration ciblée : plutôt que de restaurer la révision A dans son ensemble, le rédacteur copie manuellement le seul paragraphe manquant, puis le colle dans la version courante de l’article, sans toucher au reste du contenu.

1. Ouvrir l'écran « Révisions » et repérer la révision A dans la comparaison.
2. Copier uniquement le paragraphe manquant depuis le panneau de gauche.
3. Revenir à l'article courant (révision D) sans cliquer sur « Restaurer cette révision ».
4. Coller le paragraphe copié au bon endroit dans l'éditeur.
5. Enregistrer un brouillon, puis publier après relecture.

Ensuite, une vérification systématique : après toute restauration de révision sur un article contenant du HTML personnalisé enrichi d’accessibilité, une relecture du bloc concerné confirme que les attributs ajoutés manuellement sont toujours présents. Sur l’article en question, l’équipe a dû remonter à travers trois révisions successives avant de confirmer que le retour de l’attribut aria-label ne cachait pas une autre perte passée inaperçue ailleurs dans l’article.

Prévention

Trois mesures ont été retenues pour éviter que l’incident ne se reproduise sur d’autres articles enrichis de la même façon :

• Documenter, dans un commentaire visible pour l’équipe éditoriale, les blocs HTML personnalisés qui portent des attributs d’accessibilité ajoutés à la main, pour que toute restauration de révision sur ces articles déclenche une vérification réflexe.
• Préférer, quand c’est possible, la copie ciblée d’un fragment plutôt que la restauration complète d’une révision, en particulier pour un article publié depuis longtemps et enrichi progressivement.
• Envisager, pour les blocs de navigation récurrents comme celui de cet exemple, la création d’un bloc réutilisable WordPress plutôt qu’un bloc HTML dupliqué article par article, ce qui centralise l’attribut aria-label à un seul endroit, non soumis aux révisions individuelles de chaque article.

Conseil maison : avant toute restauration de révision sur un contenu enrichi, comparer d’abord visuellement les deux versions dans l’écran « Révisions » de WordPress plutôt que de cliquer directement sur « Restaurer » — l’aperçu révèle rarement les attributs HTML, mais il évite au moins les surprises sur le texte lui-même.

En résumé

Le système de révisions de WordPress traite un article comme un tout indivisible, sans distinguer une correction éditoriale ponctuelle d’un enrichissement technique ajouté séparément. Pour tout contenu HTML personnalisé porteur d’attributs d’accessibilité, une restauration de révision mérite donc une vérification systématique après coup, faute de quoi un attribut ajouté avec soin peut disparaître sans que personne ne s’en aperçoive avant longtemps.