# Un thème bloc qui résiste au reflow à 400 % de zoom, critère WCAG 1.4.10
> À 400 % de zoom, une grille de blocs mal pensée force un défilement horizontal que le critère WCAG 1.4.10 interdit. Voici comment vérifier et corriger un thème de blocs.
- Auteur : WordPress Développement
- Publié le : 2023-08-19
- Mis à jour le : 2023-08-19
- Catégorie : Accessibilité
- URL : https://www.wpmoderne.fr/accessibilite/theme-bloc-reflow-400-pourcent-zoom-wcag-1410/
## L’essentiel
- Le critère 1.4.10 interdit le défilement horizontal à 400 % de zoom sur une fenêtre standard
- Les colonnes en largeur fixe sont la cause la plus fréquente
- Le bloc Groupe et le bloc Colonnes doivent basculer en empilement vertical
Une fenêtre de navigateur réglée à 1280 pixels de large, zoomée à 400 %, revient à simuler un espace effectif de 320 pixels de large : c'est exactement la méthode que décrit le critère de succès WCAG 2.1 1.4.10, « Contenu réajusté » (Reflow en anglais), pour vérifier qu'un contenu reste utilisable sans défilement horizontal à un fort niveau de zoom, sur un axe du moins — le défilement vertical, lui, reste autorisé.
Ce tutoriel vérifie et corrige un thème de blocs, construit avec l'éditeur de site introduit par WordPress 5.9, dont une page d'accueil affiche un défilement horizontal gênant une fois zoomée à ce niveau. Il ne traite pas du contraste des couleurs, sujet couvert par d'autres critères du même référentiel.
## Repérer le problème
La méthode de test la plus simple consiste à régler le zoom du navigateur à 400 % — un raccourci clavier classique permet d'y arriver rapidement par incréments — sur une fenêtre de largeur standard, puis à observer si une barre de défilement horizontale apparaît en bas de la page. Sur le thème examiné, une section « Nos réalisations » construite avec un bloc Colonnes affichant trois colonnes de largeur fixe provoque exactement ce défilement, alors que le reste de la page se comporte correctement.
## Étape 1 : identifier la structure de blocs responsable
Dans l'éditeur de site, la section fautive repose sur ce type de structure, visible dans l'inspecteur de code du bloc :
```
```
Chaque colonne porte une largeur fixe en pixels, définie via `flex-basis`. Trois colonnes de 400 pixels, plus les espaces intercolonnes, réclament plus de 1200 pixels de largeur totale, indépendamment de la largeur réelle de la fenêtre. À 320 pixels effectifs, ce total dépasse largement l'espace disponible, ce qui force le navigateur à ouvrir un défilement horizontal pour ne rien couper.
> L'essentiel à retenir : Le critère 1.4.10 interdit le défilement horizontal à 400 % de zoom sur une fenêtre standard ; Les colonnes en largeur fixe sont la cause la plus fréquente ; Le bloc Groupe et le bloc Colonnes doivent basculer en empilement vertical
## Étape 2 : corriger avec des largeurs relatives
Le bloc Colonnes de WordPress bascule nativement en empilement vertical sur mobile, à condition que ses colonnes utilisent des largeurs relatives, exprimées en pourcentage, plutôt que des largeurs fixes en pixels. La correction consiste à retirer la largeur fixe et à laisser le comportement par défaut du bloc s'appliquer :
```
```
Sans largeur explicite, chaque colonne se répartit à parts égales dans l'espace disponible, puis le bloc Colonnes empile automatiquement les colonnes verticalement en dessous d'un certain seuil de largeur, comportement géré par les styles par défaut du thème et de l'éditeur de blocs.
## Étape 3 : vérifier le bloc Groupe et les images fixes
Le bloc Colonnes n'est pas le seul suspect habituel. Un bloc Groupe configuré avec une largeur minimale fixe, ou une image insérée avec une largeur en pixels codée en dur plutôt qu'en pourcentage, produisent le même type de défilement forcé. La vérification systématique consiste à parcourir chaque section de la page à 400 % de zoom, en notant celles qui provoquent une apparition de la barre de défilement horizontale, puis à examiner leurs styles associés un par un.
```
.wpm-image-realisation {
width: 600px; /* à corriger */
max-width: 100%;
height: auto;
}
```
Ici, la propriété `width` fixe imposait une largeur minimale de 600 pixels à l'image, malgré la présence de `max-width: 100%` juste en dessous. En CSS, la propriété `width` déclarée explicitement l'emporte sur `max-width` dans certains contextes de mise en page ; la correction consiste à retirer la déclaration `width` fixe et à ne conserver que `max-width: 100%`.
## Étape 4 : revérifier après correction
Une fois les colonnes et les images corrigées, le même test de zoom à 400 % confirme l'absence de défilement horizontal sur l'ensemble de la page d'accueil. Le défilement vertical, lui, reste tout à fait normal et attendu : le critère 1.4.10 porte spécifiquement sur l'axe horizontal pour un contenu qui se lit verticalement.
> Conseil maison : intégrer ce test de zoom à 400 % dans la checklist de recette de chaque nouvelle page construite avec l'éditeur de site évite de découvrir le problème après publication, au moment où la correction coûte plus de temps.
## En résumé
Le critère WCAG 1.4.10 se vérifie simplement, avec un raccourci de zoom et une fenêtre de navigateur de largeur standard, mais sa cause la plus fréquente sur un thème de blocs reste la même : une largeur fixe en pixels, sur une colonne, un groupe ou une image, qui empêche le contenu de se réajuster correctement à un espace réduit. Privilégier systématiquement les largeurs relatives et les comportements natifs des blocs WordPress évite l'essentiel de ces régressions.