Design system accessible : les bonnes pratiques (2026)

L'accessibilité ne doit pas être une "verrue" qu'on ajoute sur un produit fini. Pour être efficace et pérenne, elle doit être native. C'est là tout l'enjeu d'un Design System accessible. Si vos briques de base (boutons, champs, modales) sont conformes, 80% du travail est fait pour les développeurs.

Les 3 piliers d'un composant accessible

Pour chaque composant de votre bibliothèque (Figma ou code), vérifiez ces trois aspects :

1. La Sémantique (HTML natif)

C'est la règle d'or : utilisez les balises HTML pour ce qu'elles sont.

• Un bouton est un <button>, pas une <div> avec un onClick.
• Un lien est un <a>.
• Un champ de formulaire a toujours un <label> associé (attribut for / id).

Si vous devez créer un composant complexe (ex: un accordéon ou une modale), respectez les motifs de conception ARIA Authoring Practices du W3C.

2. Les États (Focus, Hover, Disabled)

Un composant n'est pas statique. Il vit.

• Focus visible : Ne supprimez jamais l'outline (outline: none) sans le remplacer par un style visible (bordure épaisse, changement de couleur). C'est vital pour la navigation au clavier.
• Disabled : Évitez les boutons désactivés sur une soumission de formulaire. Attention à l'argument souvent avancé : le contraste d'un bouton grisé n'est pas une non-conformité RGAA, le critère 3.3 déclarant explicitement non applicable tout composant d'interface inactif. Le vrai problème est ailleurs. L'attribut disabled retire le bouton de l'ordre de tabulation, donc l'utilisateur au clavier n'atteint ni la commande ni son explication. Nous détaillons ce piège dans notre article sur le bouton désactivé et les angles morts du RGAA. Préférez un bouton actif qui valide à la soumission et affiche une erreur explicite.

3. Les Contrastes (Couleurs)

Votre palette de couleurs doit être validée mathématiquement.

• Texte normal : Ratio de 4.5:1 minimum avec le fond.
• Texte large / Icônes : Ratio de 3:1 minimum.
• Ne jamais utiliser la couleur seule : Une erreur dans un formulaire ne doit pas être juste rouge. Ajoutez une icône ou un texte "Erreur".

Documentation : le chaînon manquant

Un Design System n'est pas qu'une librairie UI, c'est une documentation. Pour chaque composant, ajoutez une section "Accessibilité" :

• Usage clavier : "On entre avec Tab, on valide avec Espace".
• Annonces vocales : "Le lecteur d'écran doit annoncer 'Bouton, fermé'".
• Props obligatoires : "Ce composant nécessite une prop aria-label si le texte n'est pas visible".

L'approche "Shift Left"

En intégrant ces règles dès la phase de design (Figma) et de développement des composants (Storybook), vous réduisez la dette technique à la source. L'argument tient en une comparaison simple : un défaut corrigé dans un composant du design system disparaît partout où ce composant est utilisé, alors que le même défaut corrigé en production doit être repris page par page, écran par écran, à chaque occurrence.

Pour constituer les couleurs du système, le générateur de palette accessible produit des combinaisons qui respectent les seuils, et la matrice de couleurs montre d'un coup d'œil quelles associations passent. Pour ancrer ces valeurs dans le code plutôt que dans un fichier Figma, notre article sur les design tokens et l'accessibilité décrit la mise en place.

---

Conclusion

Un design system accessible ne rend pas votre produit conforme, il rend la conformité atteignable. Les briques de base traitées une fois pour toutes (sémantique, états, contrastes, documentation) retirent du chemin la majorité des défauts qui se répètent d'un écran à l'autre.

Le reste dépend de l'assemblage, et c'est là que l'audit reprend la main. Analysez une page réelle de votre produit pour voir ce que vos composants donnent une fois combinés, et ce qui demande encore un test humain.