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 viaaria-controls. - Pour un champ de formulaire : association explicite entre le champ et son
label, message d’erreur relié pararia-describedby. - Pour un menu de navigation : ordre de tabulation logique, annonce correcte de l’état ouvert ou fermé par un lecteur d’écran.
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.
