Accessibilité
Le contrat WCAG 2.2 AA auquel chaque composant ePassLive est confronté en revue — et comment nous le vérifions.
Déclaration de conformité
Le design system ePassLive vise WCAG 2.2 niveau AA comme plancher d'accessibilité. Chaque page de composant porte des assertions ARIA et aucun composant ne livre avec une violation AA connue. Les vérifications automatisées tournent à chaque push ; les passes manuelles en technologie d'assistance sont trimestrielles.
• Automatisé : axe-core dans Playwright sur Chromium, Firefox et WebKit, thèmes clair et sombre, locales EN et FR (pnpm check:all --playwright).
• Manuel : passes VoiceOver (macOS) et NVDA (Windows) sur les parcours phares, chaque trimestre.
• Contrat : les surfaces interactives exposent un nom accessible stable (WCAG 4.1.2), le contraste des couleurs atteint 4,5:1 pour le corps de texte / 3:1 pour le texte large, et rien ne dépend de la couleur seule.
Modèle de navigation clavier
Chaque composant interactif est entièrement opérable au clavier. Le modèle est uniforme dans toute la bibliothèque :
| Touche | Comportement |
|---|---|
Tab / Shift+Tab | Avance/recule dans l'ordre de tabulation. Les anneaux de focus sont toujours visibles (focus-visible:ring-2 ring-ep-teal) — nous ne supprimons jamais un indicateur de focus sans le remplacer. |
Entrée | Active les liens et les boutons par défaut (sémantique native préservée). |
Espace | Active les boutons et bascule les interrupteurs (role="switch"). |
Échap | Ferme la superposition la plus haute (dialogue, tiroir, menu de commandes, listbox) et rend le focus à son déclencheur. |
Flèches | Déplacement dans les widgets composites : items de menu, options de listbox, groupes radio (roving tabindex), barres d’onglets. |
Début / Fin | Saute à la première/dernière option dans les widgets composites qui le prennent en charge. |
Le focus n'est jamais piégé hors des portails : les superpositions ne piègent le focus qu'ouvertes, le restituent au déclencheur à la fermeture, et le layout de la documentation place un lien d'évitement comme premier élément tabulable.
Méthodologie de test avec lecteur d’écran
Les scans axe-core automatisés attrapent les violations mécaniques ; ils ne peuvent pas juger l’expérience. La méthodologie est à deux niveaux :
• Chaque push : axe-core via Playwright sur les trois moteurs — la porte locale qui doit rester verte avant la fusion.
• Passe manuelle trimestrielle : VoiceOver sur macOS et NVDA sur Windows parcourant les flux d’achat, de contrôle et d’administration, vérifiant noms, rôles et états annoncés.
• Chaque nouveau composant interactif : ses assertions a11y de patterns.ts sont revues dans l’ADR du composant avant que l’implémentation ne soit marquée complète.
Motifs intégrés
Cibles tactiles de 44 px (--ep-tap-min)
Chaque atome interactif consomme min-h-[var(--ep-tap-min)] (WCAG 2.5.5). Les affordances compactes (ex. pommeau de Switch, bouton de suppression de Tag) obtiennent quand même une zone de clic de 44 px via leur rangée englobante ou une hauteur minimale explicite.
Jetons de contraste des couleurs
Les couleurs interactives viennent des espaces de noms --ep-btn-* et --ep-semantic-*, calibrés pour passer 4,5:1 en thèmes clair et sombre. Les jetons de marque décrivent l’identité ; les jetons interactifs décrivent les surfaces — ne réutilisez jamais un jeton de marque comme fond de CTA.
Le motif sr-only
Le texte masqué visuellement (l’utilitaire .sr-only) apporte le contexte que les icônes ou les layouts omettent — ex. associer un Badge de comptage à « 3 nouveaux événements ». Préférez les étiquettes visibles ; utilisez sr-only quand le contexte visuel suffit réellement.
Signaler un problème d’accessibilité
Ouvrez une tâche ClickUp dans l’espace DS avec l’étiquette « a11y », la route, le critère de succès WCAG et les étapes de reproduction (navigateur + technologie d’assistance + thème). Joignez une transcription axe-core ou lecteur d’écran si possible. Les défauts d’accessibilité passent avant le travail de fonctionnalité — un composant avec une violation AA connue n’est pas terminé.