Migrer un site depuis Wix vers WordPress redonne l’occasion de corriger des défauts d’accessibilité hérités de l’ancienne plateforme, mais seulement si l’on prend le temps de les identifier avant l’import plutôt que de reproduire le contenu tel quel. L’export de contenu Wix, qu’il passe par une extraction manuelle ou par un outil tiers, ne préserve presque jamais correctement trois choses : la hiérarchie de titres, les textes alternatifs des images, et la gestion du focus des composants interactifs.
La hiérarchie de titres à reconstruire entièrement
Les éditeurs visuels par glisser-déposer comme celui de Wix laissent souvent choisir la taille du texte indépendamment de son niveau sémantique : un visiteur voit un « gros titre » qui, dans le code source, n’est parfois qu’un paragraphe stylé en grand, sans balise <h2> ou <h3> sous-jacente. Lors de la reprise du contenu dans l’éditeur de blocs WordPress, il ne suffit donc pas de copier le texte tel quel : chaque section doit être réexaminée pour identifier son vrai niveau de titre voulu, puis reformatée avec le bloc Titre au niveau approprié.
- Repérer chaque section visuellement identifiée comme un titre sur le site Wix d’origine.
- Vérifier, dans le code source exporté ou affiché via l’inspecteur, si cette section porte réellement une balise de titre ou seulement un style de paragraphe.
- Reconstruire la hiérarchie complète (un seul
<h1>, des<h2>qui structurent les grandes sections, des<h3>pour les sous-parties) dans le nouvel éditeur de blocs.

Les textes alternatifs à ressaisir systématiquement
La plupart des méthodes d’export de contenu Wix (capture manuelle des textes, export via une extension tierce) ne récupèrent pas les textes alternatifs saisis sur chaque image. Le résultat : des images réimportées dans la médiathèque WordPress sans aucun champ « texte alternatif » renseigné. Une vérification image par image reste indispensable, avec la commande WP-CLI suivante pour repérer rapidement les pièces jointes qui n’ont pas encore de texte alternatif défini :
wp post list --post_type=attachment --post_mime_type=image --fields=ID,post_title --format=table
Cette liste croisée avec les métadonnées _wp_attachment_image_alt permet de prioriser les images qui portent une information (schéma, capture d’écran, photo de produit) et qui nécessitent donc une description soignée, par opposition aux images purement décoratives qui peuvent recevoir un texte alternatif vide en toute légitimité.
Le focus des composants interactifs à revérifier entièrement
Un accordéon, un carrousel ou un onglet qui fonctionnait sur Wix, avec le moteur JavaScript propre à cette plateforme, ne se comporte pas nécessairement de la même façon une fois reconstruit avec un plugin WordPress différent ou du code natif de l’éditeur de blocs. Chaque composant interactif recréé sur le nouveau site doit repasser un test clavier complet, sans supposer qu’un comportement accessible sur l’ancienne plateforme se reproduira automatiquement.
- Tester chaque accordéon reconstruit avec la touche
Tabet la barre d’espace ou la toucheEntréepour l’ouverture. - Vérifier qu’aucun
outline: nonehérité d’une feuille de style de reset n’a été réintroduit par le nouveau thème. - Contrôler le mega-menu ou le menu mobile du nouveau thème indépendamment de son comportement sur l’ancien site, puisque le code sous-jacent change entièrement.
Un point annexe : les ancres de navigation interne
Les sites Wix construits en une seule longue page avec des ancres de défilement ne se transposent pas telles quelles dans une architecture WordPress classique à plusieurs pages. Si cette structure en ancre est conservée volontairement, chaque lien d’ancre doit être revérifié pour s’assurer qu’il pointe vers un identifiant réellement présent dans le nouveau gabarit, faute de quoi on retrouve exactement le problème d’un lien d’évitement mort.
Sur les migrations Wix que j’ai accompagnées, la perte des textes alternatifs reste systématique et passe le plus souvent inaperçue tant qu’aucune vérification image par image n’a été programmée dans le planning du projet.
En résumé
Une migration depuis Wix ne transporte ni la hiérarchie de titres réelle, ni les textes alternatifs, ni la garantie que les composants interactifs resteront utilisables au clavier une fois reconstruits. Traiter ces trois points comme des tâches à part entière du projet de migration, plutôt que comme un simple import de contenu, évite de reproduire ou d’aggraver les défauts de l’ancien site.