# Elementor et l’éditeur de blocs natif : l’accessibilité générée par défaut

> Avant de choisir son outil de construction de pages pour un nouveau client, une agence doit savoir ce que chaque éditeur produit par défaut, sans aucune intervention manuelle sur le code.

- Auteur : Clément Hadrot
- Publié le : 2022-07-15
- Mis à jour le : 2022-07-15
- Catégorie : Accessibilité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/accessibilite/elementor-editeur-blocs-accessibilite-par-defaut/

## L’essentiel

- Le HTML natif du bloc reste plus prévisible à l'audit
- Elementor exige plus de vigilance manuelle sur les titres
- Aucun des deux outils ne dispense d'un contrôle final

Une agence qui démarre un nouveau projet WordPress doit choisir un outil de construction de pages avant même de commencer la maquette. Ce choix a des conséquences directes sur l'accessibilité du rendu final, bien avant que le contenu ne soit relu par un humain. Nous avons comparé, sur des gabarits de page équivalents, ce que produit l'éditeur de blocs natif de WordPress face à Elementor, l'un des constructeurs de pages les plus utilisés du marché.

L'objectif n'était pas de désigner un vainqueur universel, mais de documenter les pièges par défaut de chaque outil, pour qu'une équipe sache où porter son attention selon la solution retenue pour un projet donné.

## Méthode de comparaison

Nous avons reconstruit la même page d'accueil de site vitrine, avec une bannière, trois blocs de mise en avant, un formulaire de contact et une grille d'images, une fois avec l'éditeur de blocs natif de WordPress 5.9, une fois avec Elementor en version gratuite complétée du plugin Elementor Pro. Chaque page a ensuite été passée dans l'inspecteur d'accessibilité du navigateur puis testée au clavier et avec NVDA.

## Structure des titres

L'éditeur de blocs natif impose par défaut une hiérarchie relativement disciplinée : le bloc « Titre » propose un niveau par défaut cohérent avec sa position, et un avertissement visuel apparaît dans l'éditeur lorsqu'un niveau est sauté. Avec Elementor, chaque widget de titre est indépendant et ne tient aucun compte de ce qui l'entoure : rien n'empêche techniquement d'enchaîner un `<h2>` puis un `<h5>` sans niveau intermédiaire, simplement parce que le style visuel du `<h5>` plaisait davantage à l'intégrateur.

> L'essentiel à retenir : Le HTML natif du bloc reste plus prévisible à l'audit ; Elementor exige plus de vigilance manuelle sur les titres ; Aucun des deux outils ne dispense d'un contrôle final

## Formulaires de contact

Le bloc natif de formulaire (via le plugin officiel Contact Form 7 ou le formulaire des blocs plus récents) associe correctement chaque champ à son étiquette dès la configuration standard. Le widget de formulaire d'Elementor Pro fait de même par défaut, à condition de renseigner le libellé de chaque champ : nous avons constaté que l'option « masquer le libellé » proposée dans l'interface, souvent activée pour des raisons esthétiques au profit d'un simple texte de substitution, supprime purement et simplement l'étiquette accessible du champ si elle n'est pas complétée par un attribut ARIA de remplacement.

## Comparatif synthétique

| Critère | Éditeur de blocs natif | Elementor |
| --- | --- | --- |
| Hiérarchie des titres | Alerte visuelle en cas de saut | Aucun garde-fou intégré |
| Formulaires | Étiquette liée par défaut | Risque si le libellé est masqué |
| Navigation clavier des menus | Dépend du thème | Widget dédié généralement correct |
| Poids de page généré | Plus léger | Plus lourd, CSS additionnel |
| Contrôle du HTML produit | Prévisible | Variable selon les widgets |

## Navigation clavier et carrousels

Sur les composants interactifs comme les carrousels ou les onglets, les deux outils dépendent largement de la qualité du widget ou du bloc tiers utilisé plutôt que du cœur de l'éditeur. Le widget d'onglets d'Elementor Pro gère correctement les flèches directionnelles et l'attribut `aria-selected`, ce qui nous a agréablement surpris. À l'inverse, certains blocs de carrousel disponibles pour l'éditeur natif, issus de bibliothèques tierces mal maintenues, se sont révélés moins soignés que prévu, ce qui illustre bien qu'aucun des deux écosystèmes n'est homogène.

- Un widget Elementor bien conçu peut surpasser un bloc natif mal choisi
- Le cœur de l'éditeur de blocs impose un cadre plus strict, mais pas absolu
- La qualité finale dépend toujours du choix précis des composants, pas seulement de l'outil général

> Choisir un éditeur de pages, ce n'est jamais choisir un niveau d'accessibilité garanti : c'est choisir un ensemble de garde-fous plus ou moins présents, qu'il faudra de toute façon vérifier un par un.

## Notre verdict

L'éditeur de blocs natif nous a semblé plus prévisible à l'audit, car son HTML de sortie varie moins d'un projet à l'autre et ses garde-fous par défaut limitent certaines erreurs grossières de structure. Elementor reste un outil solide, mais il exige une vigilance supplémentaire de la part de l'intégrateur, en particulier sur les options qui masquent visuellement du texte sans prévoir d'équivalent pour les technologies d'assistance. Dans les deux cas, un audit manuel après intégration reste indispensable : aucun éditeur, natif ou tiers, ne garantit à lui seul la conformité d'un site.