# Elementor V4 pour collectivité territoriale : bilan RGAA après la migration

> Trois mois après la migration d'un Kit institutionnel vers l'éditeur V4, ce que l'architecture atomique a réellement changé pour l'accessibilité du site, en bien comme en mal.

- Auteur : Clément Hadrot
- Publié le : 2026-01-09
- Mis à jour le : 2026-01-09
- Catégorie : Elementor
- URL : https://wpmoderne.dev.wordpress-developpement.fr/elementor/elementor-v4-collectivite-bilan-rgaa/

## L’essentiel

- Le rendu atomique améliore le contrôle fin des états focus et hover accessibles
- Certains composants imbriqués compliquent la lecture par lecteur d'écran
- Le bilan global reste positif mais nécessite une vigilance nouvelle

Un bilan d'accessibilité honnête ne se limite jamais à un satisfecit global : il compare précisément ce qui fonctionnait avant un changement d'architecture et ce qui fonctionne après, critère par critère. C'est cet exercice qui a été mené, douze semaines après la bascule du site d'une collectivité territoriale vers l'éditeur V4 d'Elementor, sans reprendre un tutoriel RGAA complet ni les obligations légales déjà traitées ailleurs.

La méthode retenue pour ce bilan reprend le protocole de recette déjà utilisé pendant la migration elle-même : tests clavier, lecteur d'écran NVDA, mesure de contraste, complétés cette fois par un recul de trois mois d'usage réel, avec les retours des agents de la collectivité qui alimentent le site au quotidien.

## Ce qui s'est amélioré avec l'architecture atomique

Le point le plus net concerne le contrôle des états visuels des éléments interactifs. En architecture V3, gérer un état `focus` distinct d'un état `hover` sur un widget personnalisé demandait souvent une surcharge CSS peu maintenable, car les deux états partageaient les mêmes sélecteurs générés automatiquement par Elementor. L'architecture atomique de la V4 sépare ces états au niveau du composant lui-même, avec des propriétés dédiées configurables directement dans l'éditeur.

Concrètement, l'équipe éditoriale de la collectivité peut désormais ajuster elle-même le contraste d'un état focus sur un bouton, sans intervention développeur, ce qui n'était pas possible dans l'architecture précédente sans toucher au code personnalisé.

## Ce qui a régressé, temporairement ou durablement

> L'essentiel à retenir : Le rendu atomique améliore le contrôle fin des états focus et hover accessibles ; Certains composants imbriqués compliquent la lecture par lecteur d'écran ; Le bilan global reste positif mais nécessite une vigilance nouvelle

Quatre critères RGAA ont montré une régression détectée dans les semaines suivant la migration, un chiffre qui mérite d'être détaillé plutôt que simplement mentionné. Trois de ces régressions concernaient des attributs ARIA perdus lors de la réécriture des widgets personnalisés, déjà corrigés depuis. La quatrième s'est révélée plus structurelle : la décomposition en composants atomiques, en multipliant les niveaux d'imbrication du balisage HTML, complique la lecture de la structure de la page par certains lecteurs d'écran, qui annoncent désormais plus de niveaux de conteneurs avant d'atteindre le contenu réel.

Ce dernier point n'est pas propre à un bug corrigible rapidement : il découle directement du principe même de l'architecture atomique, qui privilégie la composition de petits éléments plutôt qu'un balisage plat. La parade partielle mise en place consiste à neutraliser certains conteneurs purement structurels pour les technologies d'assistance via `role="presentation"`, combiné à une révision du rôle sémantique de chaque niveau réellement porteur de sens, mais le sujet reste ouvert et suivi de près.

### Répartition des régressions constatées

| Critère RGAA concerné | Cause | Statut au bout de 3 mois |
| --- | --- | --- |
| Attributs ARIA sur filtres | Perte lors de la réécriture du widget annuaire | Corrigé |
| Ordre de tabulation sur formulaire | Composant imbriqué mal ordonné | Corrigé |
| Libellé de bouton dupliqué | Composant réutilisé sans variante de libellé | Corrigé |
| Profondeur de structure pour lecteur d'écran | Composition atomique multi-niveaux | Suivi, non résolu |

## Ce que ce bilan implique pour la suite

Le bilan global reste favorable : trois régressions sur quatre relevaient d'erreurs de réécriture ponctuelles, désormais corrigées et intégrées dans la checklist de recette utilisée pour toute nouvelle migration de widget. La quatrième régression, plus structurelle, appelle une vigilance différente : elle ne se résout pas par un correctif ponctuel mais par une discipline continue dans la conception des composants, en limitant les niveaux d'imbrication au strict nécessaire.

- Documenter systématiquement les attributs ARIA attendus avant toute réécriture de widget personnalisé
- Tester la profondeur de structure perçue par un lecteur d'écran, pas seulement la présence des attributs
- Impliquer les agents éditoriaux dans la détection de régressions au quotidien, en plus des audits ponctuels

> Notre lecture de ce bilan : l'architecture atomique n'est ni un progrès automatique ni un risque systématique pour l'accessibilité, elle déplace simplement les points de vigilance vers la profondeur de structure plutôt que vers la seule gestion des attributs.

## Notre verdict

Trois mois après la migration, le bilan RGAA de ce site de collectivité penche du côté positif, porté par un meilleur contrôle des états interactifs accessibles. Le point de vigilance qui subsiste, lié à la profondeur de structure introduite par la composition atomique, n'a rien d'anecdotique et mérite d'être suivi sur la durée avant de conclure définitivement à un gain net pour l'accessibilité de ce type de projet.