Un design system se juge souvent à l’élégance de ses composants finis : boutons, cartes, formulaires. Mais sa robustesse en matière d’accessibilité se joue une couche plus bas, au niveau des tokens déclarés dans theme.json. Un token de focus mal pensé, ou absent, se répercute sur des dizaines de composants qui l’utiliseront plus tard. Ce billet ne revient pas sur les classes globales de couleur, déjà traitées en détail par ailleurs ; il porte sur les autres familles de tokens qui déterminent la solidité accessible d’un design system.
Voici l’architecture retenue sur un projet récent pour une agence qui construit son propre design system, destiné à être décliné sur plusieurs sites clients.
L’arborescence générale des tokens
Cinq familles de tokens ont été identifiées comme prioritaires pour l’accessibilité, en plus de la couleur : le focus, l’espacement, la typographie, le mouvement et les zones tactiles. Chacune trouve sa place dans theme.json, sous settings.custom, avec sa propre logique de nommage :
design-system/
├── theme.json
│ └── settings.custom
│ ├── focus
│ │ ├── epaisseur: "2px"
│ │ ├── decalage: "2px"
│ │ └── couleur: "var(--ds-couleur-focus)"
│ ├── espacement
│ │ └── echelle: ["4px", "8px", "16px", "24px", "40px"]
│ ├── typographie
│ │ └── echelleFluide: true
│ ├── mouvement
│ │ └── dureeMax: "200ms"
│ └── zoneTactile
│ └── minimum: "44px"
├── styles/
│ └── blocks/
└── patterns/
Le token de focus, jamais laissé au navigateur par défaut
Beaucoup de design systems laissent le focus visuel au bon vouloir du style par défaut du navigateur, ou pire, le suppriment pour des raisons esthétiques. Le token de focus défini ici impose une épaisseur, un décalage et une couleur cohérents sur l’ensemble des composants, appliqués via une classe utilitaire générée depuis ce token plutôt que déclarés composant par composant :
:where(.wp-site-blocks) *:focus-visible {
outline: var(--wp--custom--focus--epaisseur) solid var(--wp--custom--focus--couleur);
outline-offset: var(--wp--custom--focus--decalage);
}
L’échelle typographique fluide, sans piéger le zoom
L’échelle typographique fluide, popularisée depuis WordPress 6.1, calcule des tailles de police qui varient selon la largeur de la fenêtre. Le risque d’accessibilité, mal anticipé sur certains projets, tient à des formules qui plafonnent la taille de police sans laisser de marge suffisante pour le zoom utilisateur. Le token retenu ici fixe une taille plancher et un taux de croissance testés jusqu’à un zoom de 200 %, condition du critère RGAA sur la mise à l’échelle du texte.
Le mouvement, encadré dès la déclaration du token
Plutôt que de laisser chaque composant définir sa propre durée de transition, une durée maximale est fixée au niveau du token, et systématiquement respectée par les styles de blocs. Cela facilite aussi la bascule vers le mode mouvement réduit : une seule variable à surcharger plutôt qu’une chasse aux animations dispersées dans des dizaines de fichiers CSS.
Les zones tactiles comme contrainte transversale
Comme pour un thème mobile-first classique, la taille minimale de zone tactile est déclarée comme token unique, repris par tous les composants interactifs du design system, du bouton principal au lien de pied de page.
Documenter l’intention de chaque token
Chaque token du design system est accompagné, dans la documentation interne, d’une ligne qui explique son intention d’accessibilité, pas seulement sa valeur technique. Un futur designer qui voudrait réduire l’épaisseur du focus pour des raisons esthétiques tombe directement sur l’explication du choix, ce qui évite bien des régressions décidées sans connaissance de cause.
| Famille de token | Risque évité |
|---|---|
| Focus | Composant interactif sans indicateur visuel au clavier |
| Typographie fluide | Texte illisible ou plafonné en zoom élevé |
| Mouvement | Animations non maîtrisées et non réductibles globalement |
| Zone tactile | Cibles interactives trop petites sur mobile |
Un design system qui traite l’accessibilité au niveau des composants la traite toujours trop tard. Elle doit être une propriété du système de tokens, héritée automatiquement par tout ce qui sera construit dessus.
Pour aller plus loin
Construire un design system accessible dès la couche de tokens de theme.json demande d’identifier, en amont du premier composant, les familles de tokens qui portent une responsabilité d’accessibilité directe : focus, typographie fluide, mouvement, zones tactiles. C’est un effort d’architecture initial, mais il évite de devoir rattraper, composant par composant, des choix qui auraient dû être tranchés une seule fois à la racine.
