vendredi 25 septembre 2026

À propos

Contact

Tests

Tester le parcours clavier complet de l’éditeur de blocs avec Playwright

Automatiser la navigation au Tab et les raccourcis pour vérifier qu'aucune mise à jour ne rend l'éditeur inutilisable sans souris.

Par Clément Hadrot • 15 octobre 2023 • 4 min de lecture • Aucun commentaire
Tester le parcours clavier complet de l'éditeur de blocs avec Playwright

Un client agence de communication nous a signalé, après une mise à jour de son thème bloc, qu’un de ses rédacteurs ne parvenait plus à ajouter une image sans passer par la souris. La régression venait d’un composant personnalisé qui interceptait la touche Tab pour un usage interne, cassant ainsi tout le parcours clavier natif de Gutenberg. Ce genre de régression ne se voit jamais dans une revue de code classique : il faut littéralement naviguer au clavier pour la sentir.

Depuis cet incident, nous avons ajouté à notre suite Playwright un scénario dédié qui rejoue mécaniquement ce parcours clavier, du chargement de l’éditeur jusqu’à la publication, sans jamais cliquer une seule fois. C’est ce test que nous détaillons ici, étape par étape.

Étape 1 : préparer un éditeur propre

On ouvre l’éditeur sur un article vierge et on s’assure qu’aucun panneau latéral inattendu ne capture le focus au chargement, ce qui fausserait le comptage des tabulations.

import { test, expect } from '@playwright/test';

test('navigation clavier complète dans l’éditeur', async ({ page }) => {
  await page.goto('/wp-admin/post-new.php');
  await page.waitForSelector('.editor-post-title__input');
  await page.click('body'); // retire le focus initial du navigateur
});

Étape 2 : atteindre le titre puis le premier bloc au clavier

On simule un Tab unique depuis le corps de la page jusqu’au champ de titre, puis un second Tab pour entrer dans la zone de contenu.

L'essentiel à retenir : Simuler Tab, Shift+Tab et les flèches comme un vrai clavier ; Vérifier le focus visible à chaque étape ; Couvrir les raccourcis spécifiques à l'éditeur
await page.keyboard.press('Tab');
await expect(page.locator('.editor-post-title__input')).toBeFocused();

await page.keyboard.type('Article testé au clavier');
await page.keyboard.press('Tab');
await expect(page.locator('.block-editor-default-block-appender')).toBeFocused();

C’est précisément à cette étape que la régression du client se manifestait : le focus sautait directement à un composant de la barre latérale au lieu du premier bloc de contenu.

Étape 3 : insérer un bloc image sans souris

Le raccourci / (slash) ouvre le sélecteur de blocs inline dans Gutenberg. On le combine aux flèches et à Enter pour choisir le bloc Image :

await page.keyboard.type('/image');
await page.keyboard.press('Enter');
await expect(page.locator('.wp-block-image')).toBeVisible();

On vérifie ensuite que la touche Escape referme correctement toute boîte de dialogue ouverte par erreur, un point souvent négligé qui piège les utilisateurs de lecteurs d’écran autant que les power users clavier.

Étape 4 : atteindre la barre latérale des réglages du bloc

Le raccourci Ctrl+Shift+, (ou Cmd+Shift+, sur macOS) bascule la visibilité des réglages. On le teste explicitement, car c’est un raccourci que beaucoup de rédacteurs ignorent, mais que Playwright peut vérifier sans ambiguïté :

await page.keyboard.press('Control+Shift+Comma');
await expect(page.locator('.interface-interface-skeleton__sidebar')).toBeVisible();
  • Tab / Shift+Tab : circulation entre les blocs et les contrôles.
  • Alt+F10 : accès direct à la barre d’outils du bloc, un raccourci moins connu mais testé par WordPress lui-même dans sa propre suite e2e.
  • Ctrl+S : enregistrement du brouillon, à vérifier séparément du bouton Publier.

Étape 5 : atteindre et actionner le bouton Publier

On termine le parcours par la séquence de tabulations jusqu’au bouton de publication, en comptant explicitement le nombre d’étapes pour détecter toute régression future :

for (let i = 0; i < 14; i++) {
  await page.keyboard.press('Tab');
}
await expect(page.locator('.editor-post-publish-button')).toBeFocused();
await page.keyboard.press('Enter');
await expect(page.locator('.components-snackbar')).toContainText('publié');

Ce compteur fixe est volontairement fragile : s'il change, c'est le signal qu'un nouveau panneau ou composant a été inséré dans le parcours, et l'équipe doit se demander si c'est justifié.

Pour aller plus loin

Ce test ne remplace pas un audit d'accessibilité complet : il ne vérifie ni les attributs ARIA, ni le contraste, ni la cohérence des annonces pour lecteur d'écran. Il vérifie une seule chose, mais essentielle : qu'un utilisateur qui n'a que son clavier peut, de bout en bout, écrire et publier un article. C'est un filet peu coûteux à maintenir une fois écrit, et qui a déjà évité deux régressions similaires sur d'autres projets de la même agence depuis sa mise en place.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi