WPBakery et l’accessibilité clavier : ce que le page builder ne corrige jamais

Tab, tab, tab, rien ne se passe visuellement, puis soudain le focus saute trois éléments plus bas sans prévenir. C’est le symptôme le plus fréquent rencontré sur des pages construites avec WPBakery Page Builder (anciennement Visual Composer) : la navigation clavier fonctionne « à moitié », suffisamment pour donner l’illusion que tout va bien en testant rapidement, mais avec des trous qui rendent certains blocs totalement injoignables.

Le page builder est populaire justement parce qu’il masque la complexité technique derrière une interface visuelle. Le problème, c’est que cette abstraction ne s’étend pas à l’accessibilité clavier : chaque élément interactif ajouté par un shortcode WPBakery hérite du comportement JavaScript fourni par l’extension, et ce comportement n’a jamais été conçu avec le clavier comme méthode d’interaction principale.

Diagnostic : pourquoi l’illusion de fonctionnement

Un développeur qui teste rapidement une page avec WPBakery constate souvent que la tabulation « avance » d’un élément à l’autre sans erreur visible. Le piège est là : avancer n’est pas la même chose qu’atteindre tout ce qui est cliquable à la souris. Un onglet (élément vc_tta_tabs) peut très bien recevoir le focus visuellement sur son libellé sans que la touche Entrée ou les flèches ne permettent de l’activer, ni que le contenu associé devienne accessible.

Les composants à vérifier systématiquement

Après plusieurs projets construits sur WPBakery, une short-list de composants revient invariablement en tête des anomalies clavier :

• Les onglets (Tabs) : le changement d’onglet au clic ne déclenche pas toujours le même événement au clavier ; il faut vérifier que Entrée et Espace fonctionnent identiquement.
• Les accordéons (Accordion) : le focus reste parfois sur l’en-tête après ouverture, sans jamais atteindre le contenu déplié, qui doit pourtant être lu ensuite.
• Le carrousel d’images : les flèches de navigation précédente/suivante sont fréquemment des <div> avec un gestionnaire de clic JavaScript, sans tabindex ni rôle button.
• Les fenêtres modales (Popover, Message Box) : le focus n’est pas piégé à l’intérieur, ce qui permet de tabuler « derrière » la fenêtre sans s’en rendre compte.
• Les boutons personnalisés (VC Button) : générés parfois en <span> plutôt qu’en <a> ou <button>, selon la configuration du thème parent.

Corriger sans réécrire le composant entier

La bonne nouvelle, c’est que WPBakery permet d’ajouter du CSS et du JavaScript personnalisé via l’éditeur de shortcodes, sans devoir recompiler l’extension. Pour un carrousel dont les flèches ne sont pas focusables, un correctif ciblé suffit :

document.querySelectorAll('.vc_carousel-control').forEach((fleche) => {
  fleche.setAttribute('tabindex', '0');
  fleche.setAttribute('role', 'button');
  fleche.addEventListener('keydown', (e) => {
    if (e.key === 'Enter' || e.key === ' ') {
      e.preventDefault();
      fleche.click();
    }
  });
});

Ce genre de correctif, ajouté une fois dans le functions.php du thème enfant ou dans un plugin maison, s’applique à toutes les pages du site sans devoir reconstruire chaque bloc individuellement.

Prévenir plutôt que corriger après coup

La vraie difficulté avec un page builder, c’est que chaque nouvelle page ajoutée peut réintroduire les mêmes anomalies, car rien n’empêche un rédacteur d’ajouter un nouveau carrousel demain. La prévention passe par deux réflexes : documenter dans le thème enfant les composants WPBakery jugés « sûrs » à utiliser, et exclure ou déconseiller ceux qui posent problème sans correctif simple, comme certains carrousels tiers ajoutés par des extensions complémentaires.

Un page builder gère la mise en page, jamais l’accessibilité clavier de ses propres composants : c’est toujours au développeur de vérifier, composant par composant.

En résumé

WPBakery ne garantit aucune navigation clavier fiable par défaut sur ses éléments interactifs les plus riches : onglets, accordéons, carrousels, popovers. Un audit clavier systématique après chaque page construite, ciblé sur ces composants précis, permet de détecter les blocages avant qu’ils n’atteignent la production. Les correctifs restent le plus souvent légers, à condition d’être appliqués une bonne fois dans le thème plutôt que rustinés page par page.