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

> Le European Accessibility Act s'applique depuis juin 2025 aux fronts découplés qui consomment WordPress : ce que cela change concrètement pour un rendu React.

- Auteur : Clément Hadrot
- Publié le : 2025-06-30
- Mis à jour le : 2025-06-30
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/eaa-2025-accessibilite-front-headless-obligatoire/

## L’essentiel

- L'EAA s'applique depuis le 28 juin 2025 à de nombreux services numériques
- Un rendu React mal construit casse l'accessibilité même avec un WordPress conforme
- La conformité se vérifie au niveau du front, pas seulement du back-office

« 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

> L'essentiel à retenir : L'EAA s'applique depuis le 28 juin 2025 à de nombreux services numériques ; Un rendu React mal construit casse l'accessibilité même avec un WordPress conforme ; La conformité se vérifie au niveau du front, pas seulement du back-office

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.