Le signalement était vague au départ : « un utilisateur dit que le clavier ne fonctionne plus vers le bas de la page ». Sur un site WordPress d’étude notariale avec un en-tête collant reprenant le thème visuel du cabinet, rien ne semblait anormal à l’œil au premier essai. Ce billet documente le diagnostic complet, du symptôme flou jusqu’à la ligne CSS manquante, sans revenir sur le critère WCAG théorique concerné, déjà détaillé dans un article dédié au focus non masqué.
Symptôme : le focus « disparaît » à partir d’un certain point de défilement
En reproduisant la navigation au clavier depuis le haut de la page, tout fonctionnait normalement sur les premiers éléments. Le problème apparaissait uniquement après un défilement suffisant pour que l’en-tête collant se superpose au contenu : à partir de ce point, chaque nouvel appui sur Tab déplaçait bien le focus (vérifiable dans les outils de développement, onglet Accessibilité, propriété activeElement), mais l’élément focalisé n’était plus visible à l’écran, cachée sous la bande de l’en-tête. Une personne malvoyante utilisant un fort grossissement, ou naviguant uniquement au clavier sans souris pour réorienter son regard, perdait alors toute repère sur sa position dans la page.
Diagnostic : mesurer, pas supposer
Première étape du diagnostic : mesurer précisément la hauteur de l’en-tête collant avec les outils de développement. Sur ce site, l’en-tête mesurait 96 pixels une fois les marges internes comptées, une valeur qui n’était documentée nulle part dans le code du thème — elle résultait de l’empilement du logo, du menu et d’un padding hérité d’une ancienne version de la feuille de style.
Deuxième étape : identifier précisément quels éléments étaient concernés. En parcourant la page bloc par bloc, seuls les liens situés dans le corps de contenu (pas ceux du menu principal, déjà correctement gérés par le thème) et les liens du pied de page étaient affectés. Cette asymétrie a orienté le diagnostic vers une règle CSS présente sur certains éléments et absente sur d’autres, plutôt que vers un problème global de structure.
Cause : un scroll-margin-top appliqué de façon incomplète
L’inspection de la feuille de style du thème a montré qu’une règle scroll-margin-top avait bien été ajoutée lors d’une intervention précédente, mais uniquement sur les liens du menu de navigation principal :
.main-navigation a {
scroll-margin-top: 110px;
}Cette règle, trop spécifique, ne s’appliquait qu’aux liens du menu et laissait de côté tous les autres éléments focalisables de la page — liens de contenu, boutons, champs de formulaire, liens de pied de page — qui restaient sans aucune marge de défilement réservée pour l’en-tête collant.
Correctif : généraliser la règle à tous les éléments focalisables
La correction a consisté à remplacer le sélecteur trop restrictif par une règle couvrant l’ensemble des éléments interactifs de la page, avec une valeur calculée dynamiquement à partir de la hauteur réelle de l’en-tête :
:root {
--hauteur-en-tete-collant: 96px;
}
a, button, input, select, textarea, summary, [tabindex] {
scroll-margin-top: calc(var(--hauteur-en-tete-collant) + 12px);
}La variable CSS a ensuite été reliée à la valeur définie dans theme.json côté personnalisation de l’en-tête, pour qu’un changement futur de hauteur (ajout d’un bandeau, modification du logo) ne fasse pas réapparaître le même bug sans qu’on s’en rende compte.
Prévention : un test automatisé simple, mais efficace
Pour éviter que ce type de régression ne revienne à la faveur d’une future mise à jour du thème, un test Playwright a été ajouté au pipeline de vérification : il déplace le focus sur une série de liens répartis sur toute la longueur de la page, puis vérifie que le rectangle de chaque élément focalisé ne chevauche pas le rectangle de l’en-tête collant.
- Tester des éléments à différentes hauteurs de page, pas seulement en haut.
- Inclure systématiquement le pied de page dans le test, zone souvent oubliée.
- Faire échouer le test si un seul élément est concerné, pas seulement en cas de chevauchement massif.
Ce bug n’a jamais généré de rapport d’erreur visible dans la console ni d’alerte d’un outil de scan automatisé : il ne se voit qu’en naviguant réellement au clavier, sur toute la longueur de la page. C’est un bon rappel que certains défauts d’accessibilité échappent complètement aux audits purement automatisés.
En résumé
Le symptôme signalé, vague et intermittent, cachait une cause précise et localisée : une règle scroll-margin-top appliquée à un seul sous-ensemble d’éléments plutôt qu’à l’ensemble des éléments focalisables de la page. La correction elle-même tient en quelques lignes de CSS, mais le diagnostic a demandé de mesurer la hauteur réelle de l’en-tête et de tester systématiquement à différentes positions de défilement, pas seulement en haut de page.
