# Auditer l’accessibilité d’un composant isolé avant qu’il parte en production

> Auditer l'accessibilité sur une page entière en fin de projet arrive souvent trop tard pour corriger sans tout reprendre. Isoler chaque composant pour l'auditer seul change la donne.

- Auteur : Clément Hadrot
- Publié le : 2025-06-30
- Mis à jour le : 2025-06-30
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/auditer-accessibilite-composant-isole/

## L’essentiel

- Auditer un composant seul, avant son intégration dans une page complète
- Des règles ciblées selon le rôle du composant, pas une liste générique
- Un correctif appliqué à la source une seule fois, répercuté partout où le composant est utilisé

Pourquoi corriger le même défaut d'accessibilité sur douze pages différentes alors qu'il provient d'un seul et même composant ? C'est la question qu'une équipe front s'est posée en découvrant, lors d'un audit final avant mise en ligne, qu'un accordéon utilisé sur douze gabarits partageait tous le même défaut : impossible à ouvrir au clavier, sans attribut `aria-expanded` mis à jour lors du changement d'état.

L'audit intervenait à la toute fin du projet, sur la page assemblée complète, ce qui rendait le correctif coûteux à situer précisément : fallait-il corriger le composant source, ou chacune des douze intégrations qui semblaient légèrement différentes en apparence ? Auditer chaque composant isolément, bien avant son intégration dans une page, aurait évité cette confusion et ce retard.

## Ce qu'un audit de page entière ne permet pas de faire

Un audit mené sur une page complète assemblée mélange les responsabilités : un problème de contraste peut venir d'une variable de couleur globale, un problème de navigation clavier peut venir d'un composant précis, et un problème d'ordre de tabulation peut venir de l'agencement de la page elle-même. Démêler ces causes après coup demande du temps, et corriger un composant partagé directement dans le contexte d'une page particulière risque de casser son comportement ailleurs, dans les onze autres pages qui l'utilisent aussi.

## Isoler le composant dans un environnement dédié

Un environnement de développement de composants isolés, tel que Storybook, permet d'afficher l'accordéon seul, sans dépendre du reste de la page, avec ses différents états représentés côte à côte :

```
export const AccordeonFerme = {
  args: { titre: 'Livraison et retours', ouvert: false },
};

export const AccordeonOuvert = {
  args: { titre: 'Livraison et retours', ouvert: true },
};
```

Chaque état devient une cible d'audit indépendante, ce qui permet de vérifier précisément le comportement attendu à chaque transition, plutôt qu'un seul instantané figé de la page complète.

### Définir des règles ciblées selon le rôle du composant

Un accordéon n'a pas les mêmes exigences d'accessibilité qu'un champ de formulaire ou qu'un menu de navigation. Plutôt qu'une liste générique de règles RGAA appliquée sans discernement, l'audit d'un composant isolé se concentre sur les critères pertinents pour son rôle précis :

- Pour un accordéon : gestion du focus clavier, mise à jour de `aria-expanded`, association correcte entre l'en-tête et le contenu via `aria-controls`.
- Pour un champ de formulaire : association explicite entre le champ et son `label`, message d'erreur relié par `aria-describedby`.
- Pour un menu de navigation : ordre de tabulation logique, annonce correcte de l'état ouvert ou fermé par un lecteur d'écran.

> L'essentiel à retenir : Auditer un composant seul, avant son intégration dans une page complète ; Des règles ciblées selon le rôle du composant, pas une liste générique ; Un correctif appliqué à la source une seule fois, répercuté partout où le composant est utilisé

## Automatiser une partie du contrôle, composant par composant

Une bibliothèque comme `axe-core` peut s'exécuter directement contre chaque histoire du composant isolé, sans attendre l'assemblage complet de la page :

```
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('accordéon fermé sans violation critique', async ({ page }) => {
  await page.goto('/iframe.html?id=accordeon--ferme');
  const resultats = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa'])
    .analyze();

  expect(resultats.violations).toEqual([]);
});
```

## Le correctif se propage sans nouvelle vérification page par page

Une fois le composant corrigé à la source, avec l'ajout de la gestion du focus clavier et de l'attribut `aria-expanded` manquant, les douze pages qui l'utilisent héritent automatiquement du correctif, sans qu'aucune d'entre elles n'ait besoin d'un traitement séparé. Un second passage d'audit sur les pages assemblées sert alors uniquement à confirmer que le contexte d'intégration, comme un ordre de tabulation particulier à une page, n'introduit pas de problème supplémentaire propre à cette page.

| Étape | Portée | Objectif |
| --- | --- | --- |
| Audit du composant isolé | Un composant, tous ses états | Détecter et corriger à la source |
| Audit de la page assemblée | Une page complète | Vérifier le contexte d'intégration |

> Un défaut d'accessibilité corrigé sur un composant partagé vaut mieux qu'un correctif appliqué douze fois : le premier se maintient tout seul, le second se désynchronise à la première modification oubliée.

## En résumé

Auditer l'accessibilité au niveau du composant isolé, avant son intégration dans une page complète, permet de corriger une seule fois ce qui serait sinon répété autant de fois qu'il existe de pages concernées. Cette approche ne remplace pas l'audit final de la page assemblée, elle le rend plus rapide et plus ciblé, en éliminant en amont les défauts qui n'ont rien à voir avec le contexte d'intégration.