# Migrer un site Joomla vers WordPress sans perdre l’accessibilité acquise

> Les étapes pour auditer un site Joomla existant avant reprise et transposer ses landmarks et ses textes alternatifs dans le nouveau thème WordPress.

- Auteur : WordPress Développement
- Publié le : 2023-10-27
- Mis à jour le : 2023-10-27
- Catégorie : Accessibilité
- URL : https://www.wpmoderne.fr/accessibilite/migrer-joomla-wordpress-accessibilite-acquise/

## L’essentiel

- Auditer avant de tout supprimer
- Cartographier landmarks et alt existants
- Vérifier après migration, pas seulement avant

Douze ans de contenu, quatre extensions Joomla d'accessibilité installées au fil du temps, et un mandat clair : reprendre le site sous WordPress sans régresser sur ce qui fonctionnait déjà. Ce cas s'est présenté sur le site d'une fédération sportive régionale, dont le CMS Joomla original datait de 2011 et avait été retouché par plusieurs prestataires successifs.

La tentation la plus fréquente dans ce genre de projet consiste à considérer la migration comme une occasion de tout reconstruire à neuf, en ignorant l'existant. C'est une erreur : un site Joomla ancien contient souvent des correctifs d'accessibilité ajoutés à la main, invisibles dans une maquette mais précieux pour les utilisateurs qui en dépendent.

## Étape 1 : auditer l'existant avant d'y toucher

Avant d'écrire la moindre ligne de thème WordPress, l'audit du site Joomla a porté sur trois points : la structure des landmarks (souvent posée via les positions de module du template Joomla), les textes alternatifs des images du gestionnaire de médias, et les libellés de formulaires générés par des composants comme Kunena ou des extensions de contact personnalisées.

Cet audit a été mené à la fois avec l'inspecteur du navigateur et avec une lecture au clavier seul, page par page pour les gabarits principaux : accueil, page de club, fiche d'événement, formulaire d'adhésion. Chaque anomalie corrigée par le passé (un `role="navigation"` ajouté manuellement, un `alt` renseigné à la main sur un logo de sponsor) a été consignée dans un tableau, avec l'URL et le gabarit concernés.

## Étape 2 : cartographier les landmarks du template Joomla

Un template Joomla organise sa page en positions (`position-7`, `position-8`, etc.) qui ne correspondent à aucune norme d'accessibilité en soi, mais dont l'ordre visuel donnait déjà une hiérarchie de contenu cohérente : en-tête, navigation principale, contenu, barre latérale des prochains événements, pied de page. Reproduire cette hiérarchie dans le thème WordPress signifiait choisir les bonnes balises sémantiques HTML5 dès le squelette du thème, sans attendre que Gutenberg ou un constructeur de pages ne les ajoute automatiquement.

> L'essentiel à retenir : Auditer avant de tout supprimer ; Cartographier landmarks et alt existants ; Vérifier après migration, pas seulement avant

```
<header>
  <nav aria-label="Navigation principale">…</nav>
</header>
<main>
  <article>…</article>
  <aside aria-label="Prochains événements">…</aside>
</main>
<footer>…</footer>
```

## Étape 3 : transposer les textes alternatifs sans les perdre

Le gestionnaire de médias Joomla stocke les textes alternatifs directement dans le contenu de l'article, sous forme d'attribut HTML dans l'éditeur TinyMCE. La migration de contenu, réalisée avec un export XML puis un script d'import personnalisé plutôt qu'un plugin universel, devait donc préserver cet attribut lors de la conversion vers la bibliothèque de médias WordPress.

Un contrôle systématique a suivi l'import : une requête directe en base pour lister les images sans `alt` renseigné dans `wp_postmeta`, croisée avec la liste des images qui en possédaient un côté Joomla. Les écarts ont révélé une trentaine de photos de podiums sportifs dont le texte alternatif avait été perdu lors du script d'import, faute d'avoir géré un cas particulier de balise imbriquée.

## Étape 4 : les formulaires, le point le plus fragile

Les formulaires d'adhésion, initialement gérés par une extension Joomla tierce avec des libellés associés programmatiquement, ont été recréés avec Gravity Forms. Ce changement d'outil imposait de revérifier chaque libellé, chaque message d'erreur et chaque regroupement de champs (numéro de licence, coordonnées, choix de club) plutôt que de supposer qu'un nouvel outil reproduirait automatiquement le comportement de l'ancien.

- Chaque champ obligatoire porte un attribut `required` natif plutôt qu'une simple validation JavaScript.
- Les messages d'erreur sont associés au champ via `aria-describedby`, et non plus simplement affichés en couleur au-dessus du formulaire comme dans l'ancien composant.
- Le regroupement des champs de licence sportive utilise `<fieldset>` et `<legend>`, une structure absente de l'ancien formulaire Joomla.

### Ce qu'il ne fallait pas migrer

Deux extensions Joomla d'accessibilité installées par un précédent prestataire injectaient un widget de survol permettant d'agrandir le texte ou de changer les couleurs. Ces widgets, souvent appelés à tort des solutions d'accessibilité, n'ont pas été repris : le nouveau thème WordPress s'appuie sur les préférences natives du navigateur et sur un contraste suffisant par défaut, ce qui rend ce type de surcouche inutile et parfois contre-productif.

> Une migration de CMS n'efface pas les bonnes pratiques accumulées par accident : elle les rend invisibles si personne ne prend le temps de les chercher avant de tout supprimer.

## Notre verdict

Trois passes d'audit ont structuré ce projet : avant la migration pour cartographier l'existant, pendant pour vérifier que chaque import préservait les attributs critiques, et après pour comparer le site final au site d'origine gabarit par gabarit. Ce déroulé, plus long qu'une reprise à l'aveugle, a évité de faire regresser un site qui, malgré son âge et son CMS obsolète, respectait déjà un socle d'accessibilité que personne dans l'équipe n'avait documenté formellement.