Chapitre 15.2 — Un design system accessible

⏱️ TL;DR — Le design system est ton plus gros levier d’accessibilité. Si le Button, l’Input, la Modal et les Tabs partagés sont accessibles une fois pour toutes, chaque produit qui les consomme hérite de l’accessibilité gratuitement : tu corriges à un endroit, tu bénéficies partout. La contrepartie est réelle : un composant partagé bugué propage son défaut sur tous les écrans. D’où deux exigences : chaque composant doit documenter son comportement a11y (clavier, ARIA, états), et être testé en continu (Storybook + addon a11y). Le design system, c’est l’accessibilité qui passe à l’échelle.

🎯 Objectifs

• Voir le design system comme le point de correction unique de l’accessibilité.
• Intégrer clavier, ARIA et états dans les composants partagés, pas dans chaque page.
• Documenter le contrat a11y de chaque composant (clavier, rôles, états).
• Utiliser Storybook + addon a11y pour tester chaque composant isolément.
• Mesurer le risque inverse : un composant partagé défaillant propage le bug à grande échelle.

Le levier : corriger une fois, bénéficier partout

Sans design system, chaque équipe recode son bouton, sa modale, son onglet — et chacun refait les mêmes erreurs d’accessibilité. Avec un design system, il existe un seul Button, une seule Modal. Rendre ce composant accessible profite instantanément à tous ses consommateurs.

C’est le renversement d’échelle : l’a11y cesse d’être un travail répété sur chaque page pour devenir une propriété du composant. Un développeur qui consomme <Modal> n’a plus à connaître le piège du focus ou l’attribut aria-modal — il en hérite.

Encapsuler l’accessibilité dans le composant

Les patterns complexes (voir Composants interactifs) sont exactement ce qu’il faut encapsuler. Le consommateur écrit du code simple ; toute la mécanique a11y vit à l’intérieur.

{/* ❌ Sans design system : chaque page recâble la modale à la main
     (et oublie le piège de focus, Échap, aria-modal, le retour du focus…) */}
<div className="overlay">
  <div className="dialog">
    <h2>Confirmer</h2>
    ...
  </div>
</div>
 
{/* ✅ Le composant partagé porte tout le contrat a11y en interne */}
<Modal isOpen={open} onClose={close} titleId="confirm-title">
  <h2 id="confirm-title">Confirmer</h2>
  ...
</Modal>

À l’intérieur de Modal, une fois pour toutes : role="dialog", aria-modal="true", le libellé via aria-labelledby, le piégeage du focus, la fermeture par Échap, et le retour du focus sur l’élément déclencheur à la fermeture. Le consommateur n’a rien à savoir de tout ça — c’est le sens même d’un composant partagé.

Chaque composant a un contrat d’accessibilité documenté

Un composant partagé non documenté sera mal utilisé. Documente, à côté de chaque composant, son contrat a11y : quelles interactions clavier il gère, quels rôles/attributs ARIA il pose, quels états il expose, et ce que le consommateur doit fournir (un libellé, un id…).

Cette table est le mode d’emploi a11y de ta bibliothèque. Sans elle, un dev collera un <Button> avec une icône seule et sans libellé — le composant est accessible, son usage ne l’est pas.

⚠️ Piège — Le composant est accessible, mais mal utilisé. Un IconButton parfait reste muet pour un lecteur d’écran si le consommateur oublie l’aria-label. Le design system doit rendre le bon usage évident : rends le libellé obligatoire dans les props (TypeScript qui refuse le composant sans aria-label quand il n’y a pas d’enfant textuel), documente-le, et vérifie-le en test. L’accessibilité d’un composant partagé, c’est aussi celle de son API.

Le risque inverse : un bug qui se propage partout

Le levier joue dans les deux sens. Si la Modal partagée cesse de rendre le focus au déclencheur, ce n’est pas une page cassée : ce sont toutes les modales de tous les produits. La centralisation démultiplie autant les corrections que les régressions.

Conséquences pratiques :

• Les composants du design system méritent le plus haut niveau de tests a11y — ce sont eux qui portent le risque systémique.
• Toute modification d’un composant partagé passe par une revue a11y et une non-régression automatisée.
• Versionne et communique : un changement de comportement clavier de Tabs est un breaking change d’accessibilité, pas un détail.

Storybook + addon a11y : tester chaque composant isolément

Storybook rend chaque composant visible dans tous ses états, isolé de l’application. L’addon a11y (basé sur le moteur axe) analyse automatiquement chaque story et signale les violations (contraste, rôles manquants, libellés absents) — directement dans l’atelier du développeur.

• Une story par état : repos, focus, désactivé, erreur, chargement, vide (les états du chapitre précédent).
• L’addon a11y tourne sur chacune → le dev voit les violations avant même d’intégrer le composant.
• On automatise ensuite ces vérifications en CI (voir Tester l’accessibilité) : une story qui régresse casse la build.

Storybook devient ainsi à la fois la documentation vivante du contrat a11y et son banc de test.

💡 Réflexe — Quand tu croises un bug d’accessibilité dans une page, pose-toi toujours la question : « est-ce que ça vient d’un composant partagé ? » Si oui, ne le corrige pas dans la page — remonte la correction dans le design system. Tu répares le symptôme et tous les autres endroits où il se manifeste (souvent sans le savoir). Corriger dans la page, c’est traiter une fuite sans fermer le robinet.

🧭 Sur A11yLearn — A11yLearn a extrait sa bibliothèque de composants dans un paquet @a11ylearn/ui, documenté dans un Storybook public. Chaque composant (Button, Field, Modal, Tabs, Toast) y est livré avec ses six états, sa table de contrat a11y, et l’addon a11y actif sur chaque story. Le jour où l’on a corrigé le retour de focus de la Modal, la correction s’est propagée à l’app Next.js et aux blocs intégrés dans Moodle en une seule PR. C’est là que « corriger une fois, bénéficier partout » cesse d’être un slogan : c’est devenu la mécanique quotidienne de l’équipe.

✏️ Exercices

Exercice 1 — Rédige le contrat a11y d’un Tooltip. Ton design system ajoute un composant Tooltip (bulle d’aide au survol/focus d’un élément). Décris son contrat d’accessibilité : clavier, ARIA, et ce que le consommateur doit fournir.

Exercice 2 — Fuite ou robinet ? En recette, on te signale que sur trois écrans différents, le message d’erreur d’un formulaire n’est pas annoncé au lecteur d’écran. Les trois utilisent le même composant <Field>. Que fais-tu, concrètement ?

🧠 Quiz de révision

Chapitre suivant : Accessibilité cognitive — la famille de handicaps la plus large, qui se traite par la clarté plus que par l’ARIA.