Ce site associatif venait tout juste de migrer d’un thème classique vers un thème compatible avec l’édition complète de site, disponible depuis WordPress 5.9 et désormais bien installée avec la sortie de WordPress 6.2. La migration avait été menée avec soin, gabarit par gabarit, dans l’éditeur de site. Un mois plus tard, un utilisateur de lecteur d’écran a signalé que le lien « passer au contenu », habituellement invisible et activé en première tabulation, ne faisait plus rien.
Ce billet détaille comment nous avons diagnostiqué cette régression, en apparence mineure mais réellement bloquante pour les utilisateurs qui en dépendent à chaque page visitée.
Symptôme : un lien présent mais inactif
En appuyant sur Tab dès l’arrivée sur la page, le lien « Passer au contenu » apparaissait bien visuellement, preuve qu’il existait toujours dans le HTML. Mais en appuyant sur Entrée, rien ne se produisait : le focus restait bloqué sur le lien lui-même, sans jamais se déplacer vers le contenu principal de la page.
Diagnostic : une ancre orpheline
En inspectant le code source, le lien pointait bien vers #contenu :
<a class="skip-link screen-reader-text" href="#contenu">Passer au contenu</a>
Mais en recherchant l’identifiant contenu dans le reste du gabarit généré par l’éditeur de site, celui-ci était introuvable. L’ancien thème classique posait cet identifiant directement sur la balise <main id="contenu"> dans son fichier header.php. Le nouveau thème FSE, construit à partir du template par défaut fourni par le générateur de thème, utilisait bien un bloc <!-- wp:template-part slug="content" --> et un élément <main>, mais sans reprendre cet identifiant, qui n’a rien d’automatique dans la génération de blocs.
Correctif : reposer l’ancre manuellement
La correction a consisté à ajouter manuellement l’identifiant manquant sur l’élément racine du contenu, via le bloc Groupe englobant la zone de contenu dans le template index.html du thème, en utilisant l’attribut HTML personnalisé disponible dans les réglages avancés du bloc :
<!-- wp:group {"tagName":"main","anchor":"contenu"} -->
<main id="contenu" class="wp-block-group">
<!-- wp:template-part {"slug":"content"} /-->
</main>
<!-- /wp:group -->Ce même identifiant devait être répété à l’identique sur chacun des templates du thème, y compris le template de la page d’accueil, du blog et de la page d’archive de produit, chacun généré indépendamment par l’éditeur de site.
Vérification sur l’ensemble des gabarits
Nous avons dressé la liste de tous les templates actifs du thème depuis l’écran Apparence > Éditeur, puis vérifié un par un que l’ancre #contenu était bien présente et que le focus se déplaçait correctement à l’activation du lien d’évitement :
- Template Accueil : ancre manquante, corrigée
- Template Article simple : ancre manquante, corrigée
- Template Page : ancre manquante, corrigée
- Template Archive : ancre manquante, corrigée
- Template 404 : ancre manquante, corrigée
Les cinq templates du thème présentaient la même régression, ce qui confirme qu’il s’agissait bien d’un défaut structurel du gabarit de départ fourni par le générateur, et non d’un oubli isolé sur une seule page.
Un focus programmatique en complément
Nous avons également ajouté un court script pour renforcer la fiabilité du lien, certains navigateurs ne déplaçant pas systématiquement le focus clavier sur un élément qui n’est pas nativement focusable comme <main> :
document.querySelector('.skip-link').addEventListener('click', function (event) {
const cible = document.getElementById('contenu');
if (cible) {
cible.setAttribute('tabindex', '-1');
cible.focus();
}
});Une migration de thème, même soignée visuellement, peut casser silencieusement des mécanismes qui ne se voient jamais à l’écran. Le lien d’évitement en est l’exemple parfait : personne ne le remarque tant que personne n’en a besoin.
Prévention pour les prochaines migrations
Depuis cet incident, notre check-list de recette après migration vers un thème FSE inclut désormais un test systématique et rapide : sur chaque template actif du site, appuyer sur Tab puis Entrée dès l’arrivée sur la page, et vérifier que le focus atteint effectivement le début du contenu principal. Ce test prend moins d’une minute par gabarit et aurait permis de détecter cette régression avant la mise en ligne plutôt qu’après le signalement d’un utilisateur concerné.
