EAA 2025 : l’accessibilité d’un front headless devient obligatoire

« Notre WordPress est accessible, donc notre site l’est aussi. » Cette phrase, entendue lors d’un point de conformité en juin 2025, contient une erreur qui coûte cher dans une architecture headless : un WordPress bien configuré, avec un thème accessible et des textes alternatifs renseignés, ne garantit strictement rien sur l’accessibilité du front qui consomme son API REST. Le European Accessibility Act, entré en application le 28 juin 2025, s’intéresse au service final rendu à l’utilisateur, pas à la brique technique qui produit le contenu en coulisses.

Pour de nombreux services numériques vendant des produits ou services au grand public dans l’Union européenne, l’accessibilité n’est plus une option de confort : c’est une obligation réglementaire, avec des conséquences juridiques en cas de manquement caractérisé. Un site headless, parce qu’il reconstruit l’interface à partir de zéro avec un framework JavaScript, doit reprendre à son compte tout ce que WordPress gérait auparavant nativement dans son thème.

Ce que WordPress fait bien, et que le front doit refaire

Un thème WordPress classique, correctement codé, structure le HTML avec des balises sémantiques, gère la navigation au clavier des menus, et associe correctement les libellés de formulaire à leurs champs. Rien de tout cela ne se transmet automatiquement à un front headless : l’API REST renvoie du contenu structuré en JSON, mais c’est bien le code React (ou tout autre framework) qui décide comment ce contenu se transforme en HTML final, avec ou sans les attributs d’accessibilité nécessaires.

Les pièges les plus fréquents d’un rendu React non accessible

Sur plusieurs projets headless audités après l’entrée en application du EAA, les mêmes défauts reviennent :

• Le contenu riche renvoyé par l’API REST (champ content.rendered) est injecté tel quel via dangerouslySetInnerHTML, en conservant parfois des balises <div> imbriquées sans structure de titres cohérente.
• Les images issues de la médiathèque WordPress perdent leur texte alternatif en cours de route, si le composant front ne relit pas le champ alt_text de l’objet média.
• Les menus personnalisés, reconstruits en composants React, oublient la gestion du focus clavier que le thème natif de WordPress gérait via son propre script de navigation.
• Les formulaires de contact, reconstruits côté front, perdent l’association explicite entre un champ et son message d’erreur, pourtant simple à corriger avec l’attribut aria-describedby.

Vérifier que le texte alternatif survit au voyage API

Un exemple concret : l’endpoint wp/v2/media retourne un champ alt_text distinct du champ caption. Un composant front qui ne récupère que l’URL de l’image, sans requêter cette information, produit une balise img sans alternative textuelle, alors même que le contenu a été correctement renseigné dans WordPress.

const reponse = await fetch(`${apiUrl}/wp/v2/media/${idImage}`);
const media = await reponse.json();
// media.alt_text doit être reporté sur l'attribut alt du composant image

Ce que l’EAA n’impose pas ici

Le règlement ne fixe pas de méthode d’audit unique ni de norme technique obligatoire pour vérifier la conformité : il pose une obligation de résultat pour les services concernés, à documenter par l’organisation elle-même. Un audit détaillé selon les critères WCAG reste un exercice à part entière, qui dépasse le cadre de cet article.

Ce que cela change dans la conduite de projet

Sur les projets headless lancés après juin 2025, l’accessibilité doit désormais figurer dans la recette technique au même titre que la performance ou le référencement, avec des tests de navigation clavier systématiques sur les composants dynamiques (menus, accordéons, carrousels), plutôt qu’une vérification tardive juste avant la mise en ligne.

Un exemple de correction sur un menu de navigation

Le menu principal du site, reconstruit en React sans gestion du focus clavier, a été corrigé en ajoutant une gestion explicite de la touche Échap pour fermer un sous-menu ouvert, ainsi qu’un déplacement du focus vers le premier lien du sous-menu à son ouverture. Ce correctif, minime en volume de code, a suffi à rendre navigable au clavier une fonctionnalité jusque-là uniquement pensée pour une utilisation à la souris.

Un front headless hérite de zéro accessibilité par défaut : chaque composant React doit reconstruire ce qu’un thème WordPress offrait gratuitement.

Notre verdict

Depuis le 28 juin 2025, l’accessibilité d’un site headless ne se délègue plus à WordPress : elle se construit explicitement dans le front, composant par composant, en particulier sur tout ce qui touche au texte alternatif, à la structure des titres et à la navigation clavier.