# WordPress 5.8 : l’effet des widgets blocs sur l’accessibilité

> Depuis le passage de juillet 2021, les widgets ne sont plus des formulaires d'options mais des blocs Gutenberg. Nouveautés classées par leur impact réel sur l'accessibilité.

- Auteur : WordPress Développement
- Publié le : 2021-08-12
- Mis à jour le : 2021-08-12
- Catégorie : Accessibilité
- URL : https://www.wpmoderne.fr/accessibilite/effet-widgets-blocs-accessibilite/

## L’essentiel

- L'éditeur de widgets remplace le formulaire par bloc par un canevas Gutenberg
- Les zones de widgets deviennent navigables comme un contenu de bloc classique
- Certains anciens widgets tiers perdent leur balisage accessible en migrant

WordPress 5.8, sorti en juillet 2021, remplace l'écran classique de gestion des widgets, avec ses formulaires empilés par zone, par un éditeur construit sur la même base que l'éditeur de blocs de contenu. Chaque widget devient un bloc, la zone de widgets devient un canevas où l'on insère, déplace et configure ces blocs comme dans l'éditeur d'article. Ce changement de fond a des effets directs sur l'accessibilité, dans un sens qui n'est pas uniformément positif.

Ce billet classe les nouveautés de cette version selon leur impact réel sur l'accessibilité des zones de widgets, du plus favorable au plus problématique.

## Impact positif : une interface de configuration plus cohérente

L'ancien écran de widgets imposait une interface différente pour chaque type de widget, parfois avec des champs mal étiquetés selon l'extension qui l'avait enregistré. L'éditeur de blocs impose une structure commune : chaque bloc widget affiche ses réglages dans un panneau latéral standardisé, avec des champs correctement associés à leur étiquette. Cette homogénéisation profite directement à la navigation au clavier dans l'administration, puisque le comportement du panneau reste identique d'un widget à l'autre.

> L'essentiel à retenir : L'éditeur de widgets remplace le formulaire par bloc par un canevas Gutenberg ; Les zones de widgets deviennent navigables comme un contenu de bloc classique ; Certains anciens widgets tiers perdent leur balisage accessible en migrant

## Impact neutre à surveiller : le rendu final côté visiteur

Côté public, le rendu HTML final d'un widget bloc reste proche de celui d'un widget classique bien codé : un titre de widget en `<h2>` ou `<h3>` selon le thème, un conteneur avec une classe stable. Le passage aux blocs ne change donc rien, en soi, à l'expérience d'une personne qui consulte le site avec un lecteur d'écran, à condition que le thème continue de fournir la même structure de zone de widgets qu'auparavant.

## Impact négatif : la migration des widgets tiers mal préparés

Le point le plus problématique concerne les extensions qui enregistraient un widget classique avec un balisage accessible soigné (structure de titre correcte, attributs ARIA sur un composant interactif) sans avoir prévu de bloc équivalent. WordPress 5.8 conserve ces anciens widgets via un bloc de compatibilité nommé `Ancien widget`, mais certaines extensions publient rapidement une version bloc réécrite depuis zéro, parfois avec moins de soin que l'original sur les points d'accessibilité.

- Un widget de recherche tiers qui perd son `<label>` associé dans sa réécriture en bloc.
- Un widget de réseaux sociaux dont les icônes cliquables perdent leur texte alternatif lors du passage au format bloc.
- Un widget de newsletter dont le message de confirmation, auparavant annoncé par une région `aria-live`, redevient un simple changement visuel silencieux dans sa version bloc.

### Ce qu'il faut vérifier après la mise à jour

Sur un site déjà en production qui passe à WordPress 5.8, un test manuel de chaque widget tiers utilisé dans la zone latérale ou le pied de page reste indispensable. La commande WP-CLI suivante liste rapidement les widgets encore actifs sous forme classique après la mise à jour :

```
wp widget list sidebar-1 --fields=id,name,options
```

Chaque widget encore listé ici comme classique mérite un contrôle avant sa migration volontaire vers le bloc équivalent, plutôt qu'une conversion automatique subie sans vérification.

> Sur les mises à jour vers 5.8 que j'ai accompagnées, le widget de recherche tiers reste celui qui casse le plus souvent silencieusement : son formulaire perdait son étiquette dans la version bloc republiée quelques semaines après la sortie de WordPress.

### Le cas particulier du bloc de compatibilité

Quand un widget classique n'a pas encore de version bloc disponible, WordPress l'enveloppe automatiquement dans le bloc `Ancien widget`, qui restitue le formulaire de réglages d'origine à l'intérieur du nouvel éditeur. Ce mécanisme préserve le comportement exact du widget, y compris son balisage final côté visiteur, ce qui en fait une solution transitoire plus sûre qu'une migration précipitée vers une version bloc mal testée. Je recommande de garder ce bloc de compatibilité tant que la version bloc de l'extension concernée n'a pas été vérifiée manuellement au clavier.

## En résumé

Le passage aux widgets blocs de WordPress 5.8 uniformise l'interface d'administration au bénéfice de l'accessibilité, mais déplace le risque vers les extensions tierces dont la réécriture en bloc n'a pas toujours conservé le même soin que le widget classique original. Un contrôle manuel de chaque widget tiers après la mise à jour, associé au maintien prudent du bloc de compatibilité tant que la version bloc n'est pas vérifiée, reste la garantie la plus fiable.