wp.components.Popover apparaît dans une quantité impressionnante d’extensions qui ajoutent des panneaux contextuels à l’éditeur de blocs : sélecteurs de couleur personnalisés, pickers de médias maison, menus d’options avancées pour un bloc sur mesure. Le composant est réutilisé tel quel, avec la conviction implicite qu’il gère correctement le focus clavier puisqu’il fait partie du cœur de Gutenberg. Cette conviction mérite d’être vérifiée composant par composant, plutôt qu’admise une fois pour toutes.
Le Popover de l’éditeur repose sur @wordpress/components et utilise en interne des mécanismes de positionnement dynamique (souvent via une bibliothèque de calcul de position) combinés à une gestion de montage/démontage React. Le comportement de focus qui en résulte dépend fortement de la manière dont le composant appelant configure ses props, en particulier focusOnMount et onFocusOutside.
Ce que montre un test clavier pas à pas
Sur trois intégrations tierces examinées dans des extensions différentes, le comportement observé n’était pas identique. Dans la première, un panneau de réglages avancés pour un bloc personnalisé, l’ouverture du Popover déplaçait correctement le focus sur le premier champ du panneau, et la touche Échap refermait le panneau en restituant le focus au bouton déclencheur. Ce comportement correspond à ce qu’on attend d’un composant de superposition correctement outillé.
Dans la deuxième intégration, un sélecteur de couleur personnalisé, le Popover s’ouvrait sans déplacer le focus du tout : celui-ci restait sur le bouton déclencheur, ce qui obligeait un utilisateur au clavier à appuyer sur Tab à l’aveugle pour atteindre le contenu du panneau, sans annonce préalable de son ouverture par le lecteur d’écran. Dans la troisième, un menu d’actions contextuelles, la touche Tab en fin de panneau ramenait le focus en dehors du panneau, dans la barre d’outils du bloc, sans jamais refermer le Popover, laissant un panneau ouvert visuellement pendant que le focus naviguait ailleurs.
Où se situe la responsabilité
Le composant Popover expose les leviers nécessaires à un focus correctement géré, mais ne les active pas systématiquement par défaut selon la version et le contexte d’appel :
import { Popover } from '@wordpress/components';
function MonPanneau( { isOpen, onClose, anchorRef } ) {
if ( ! isOpen ) return null;
return (
<Popover
anchor={ anchorRef.current }
onClose={ onClose }
focusOnMount="firstElement"
>
<div>{ /* contenu du panneau */ }</div>
</Popover>
);
}
La prop focusOnMount="firstElement" demande explicitement au composant de déplacer le focus sur le premier élément focalisable du panneau à l’ouverture. Omise, ou définie à false, elle laisse le focus où il se trouvait, ce qui correspond exactement au comportement observé dans la deuxième intégration testée.
Le vrai piège clavier n’est pas toujours celui qu’on croit
Le critère WCAG 2.1.2 « Pas de piège au clavier » interdit qu’un utilisateur reste bloqué dans un composant sans pouvoir en sortir avec le seul clavier. Ce n’est pas le défaut le plus fréquent observé ici : la sortie fonctionne presque toujours (Échap ou clic extérieur). Le défaut le plus fréquent est inverse et plus subtil : un focus qui s’échappe du panneau ouvert sans le refermer visuellement, ce qui relève plutôt du critère 2.4.3 « Ordre de focus » et de la cohérence générale de navigation attendue par le critère 4.1.2 « Nom, rôle, valeur » sur l’état exposé du composant (ouvert/fermé).
Checklist avant de réutiliser un Popover tel quel
- Vérifier que
focusOnMountest explicitement défini selon le besoin (firstElementpour un panneau de formulaire, parfois inutile pour un simple message d’information) - Tester la sortie par Tab en fin de panneau : le focus doit soit revenir au début, soit sortir en refermant proprement le composant
- Tester Échap et vérifier qu’il referme le panneau ET restitue le focus au déclencheur
- Ne jamais supposer qu’un composant issu du cœur de l’éditeur est accessible par construction dans toutes ses configurations possibles
Ce que cela implique pour une extension
Réutiliser un composant du cœur n’exonère jamais d’un test clavier complet sur l’intégration finale. Le composant fournit les briques ; la configuration précise (props, contenu du panneau, ordre des éléments focalisables à l’intérieur) reste sous la responsabilité de l’extension qui l’assemble. Un audit d’accessibilité qui se contente de vérifier « le projet utilise des composants natifs de Gutenberg, donc c’est accessible » passe à côté de ce genre d’écart, qui n’apparaît qu’à l’usage réel au clavier.
Notre règle interne avant de livrer une extension qui ouvre un Popover : trois passages clavier complets, ouverture, navigation interne, fermeture, sans jamais toucher la souris entre les trois.
En résumé
Le Popover de l’éditeur de blocs n’emprisonne pas le focus au sens strict du critère WCAG 2.1.2, mais son comportement de gestion du focus à l’ouverture et à la sortie dépend entièrement de la configuration choisie par l’extension qui l’intègre. Faire l’économie d’un test clavier réel sur chaque intégration, au prétexte que le composant vient du cœur de WordPress, revient à parier sur un comportement qui, à l’expérience, varie sensiblement d’une extension à l’autre.
