Audit d’accessibilité de design system

Nous auditons votre design system au regard du RGAA 4.1 et des WCAG 2.2, à l’échelle du composant. Car un composant inaccessible propage son défaut partout où il est réutilisé : le corriger une fois, c’est le corriger partout et c’est rendre votre interface accessible “by design”.

Auditer votre design system Explorer nos composants accessibles
Quel périmètre

Fondations, composants, documentation :ce que recouvre l’audit

Un design system ne se résume pas à une maquette. Nous auditons ce que vos équipes utilisent réellement pour construire vos interfaces :

Les fondations (tokens)

Couleurs, typographie, espacements, Indicateurs d’état (hover, focus, selected...) : les règles de base dont héritent tous les composants.

Les composants rendus

Boutons, champs, modales, menus, onglets, tableaux, carrousels, notifications… tels qu’ils existent en code (Storybook, bibliothèque intégrée), et pas seulement dessinés.

La documentation d’accessibilité

Les consignes d’usage fournies aux intégrateurs (Zeroheight) : alternatives, ARIA, ordre de lecture. Un composant accessible mais mal documenté peut être mal utilisé.

Un design system accessible met en conformité tout ce qui en hérite

La loi n'impose pas l'accessibilité au design system lui-même, mais aux sites et applications qui en héritent (article 47 de la loi du 11 février 2005, European Accessibility Act). C'est ce qui en fait le point de levier le plus rentable : un composant corrigé à la source, c'est un défaut évité sur chaque page, chaque écran, chaque produit qui le réutilise. Vous ne réparez pas cent fois la même erreur, vous la supprimez à l'origine. C’est devenir accessible « by design ».

Comprendre vos obligations légales
Quelle méthode

Comment nous auditons chaque composant, dans tous ses états

Un composant n’est pas accessible « en général » : il l’est - ou non - dans chacun de ses états. Nos experts testent chaque composant de l’échantillon :

  • Dans tous ses états par défaut, survol, focus, actif, désactivé, erreur. Un champ peut être parfait par défaut et perdre son message d’erreur au lecteur d’écran.
  • Au clavier et au lecteur d’écran ordre de tabulation logique, focus visible, rôle et état correctement annoncés.
  • Sur le composant rendu Vie le code (storybook, bibliothèque intégrée), et non la maquette, car c’est le code qui dialogue avec les technologies d’assistance.

C’est un audit mené par des experts. Les composants ARIA personnalisés - modale, accordéon, combobox - concentrent les risques et échappent largement à la détection automatique : ils exigent un test humain.

Corrigez une fois, partout

Un composant non accessible se répète sur chaque écran qui l'utilise. Faites auditer votre design system pour corriger "by design" (à la source) et rendre conformes tous les produits qui en héritent.

Faire auditer mon design system
Quel test

Ce que nous testons, concrètement

Trois couches, du plus global au plus fin :

  • Les fondations (tokens)

    • Contrastes - couleurs de texte, d'icônes et d'états respectant les ratios des référentiels RGAA 4.1 ou WCAG 2.2 ; l'information n'est jamais portée par la seule couleur.
    • Typographie - tailles minimales et redimensionnement du texte sans perte de contenu ni de fonction.
    • Focus - un indicateur de focus visible et suffisamment contrasté, hérité par tous les composants.
    • Cibles de pointage - taille suffisante : les WCAG 2.2 fixent un minimum de 24×24 px CSS (critère 2.5.8).

  • Les composants

    • Rôles et états ARIA - chaque composant interactif expose son rôle, son nom et son état aux technologies d'assistance.
    • Composants personnalisés - modale, accordéon, combobox, onglets : les patrons ARIA sont implémentés correctement (focus piégé dans la modale, navigation aux flèches dans un menu…).

  • La documentation

    Consignes d'usage accessible - le kit indique-t-il aux intégrateurs comment utiliser chaque composant sans casser son accessibilité ? Alternatives, ordre de lecture, attributs ARIA à renseigner et utilisation au clavier.

Quelles erreurs

Les erreurs qui se propagent depuis un composant

Une erreur logée dans un seul composant se répète sur des centaines de pages. Les plus fréquentes :

  • Champ de formulaire sans étiquette le lecteur d'écran dit « champ de saisie » sans préciser quoi saisir, sur chaque formulaire.
  • Icône-bouton sans intitulé une icône « fermer » ou « panier » sans texte : l'action existe partout, mais n'est jamais annoncée.
  • Modale qui ne retient pas le focus au clavier, l'utilisateur sort de la fenêtre sans s'en apercevoir et se perd derrière.
  • Focus rendu invisible dans les tokens plus aucun repère visuel : impossible de savoir où l'on se trouve en tabulant.
  • Erreur signalée par la seule couleur le champ passe au rouge, sans texte : invisible pour une personnedaltonienne ou au lecteur d'écran.
  • Composant riche (carrousel, onglets) sans structure ARIA un contenu inaccessible, reproduit partout où le composant est posé.
  • Contraste insuffisant dans les guidelines des associations de couleurs illisibles, appliquées à tous les textes.

À la clé : un rapport composant par composant, des recommandations correctives priorisées et des consignes d’intégration accessible pour vos équipes. Le détail de notre méthodologie et de nos livrables figure sur la page Audit d’accessibilité numérique.

Un audit n’est qu’un point de départ. Nous vous accompagnons ensuite dans la remédiation de vos composants et le pilotage de votre mise en conformité, pour faire de l’accessibilité un levier de performance durable - « by design » (à la source), puis « on the way » (sur le chemin) et pour longtemps.

faq

Questions fréquentes

Les deux. Nous auditons les composants conçus afin de prémunir des erreurs en développement et rendus (storybook, bibliothèque intégrée) et leur documentation, car le code reflète la conception initiale et les manquements dans la documentation des maquettes. Nous proposons ainsi une méthodologie d’annotations pour vos maquettes.

Pas directement : l’obligation vise les sites et applications qui l’utilisent (loi de 2005, EAA apprécié au regard de l’EN 301 549). Mais rendre le design system accessible met en conformité, à la source, tout ce qui en hérite. Les échéances et les seuils sont détaillés sur notre page législation.

Oui, en priorité. Modales, accordéons, comboboxes : ces composants sur-mesure concentrent les risques et échappent largement aux outils automatiques. Ils sont audités manuellement, au clavier et avec les logiciels d’assistance.

Les critères RGAA 4.1 et WCAG 2.2 appliqués à l’échelle du composant, en cohérence avec la norme EN 301 549. Le RGAA reste le référentiel légal français ; le RGAA 5, attendu fin 2026, fera évoluer ce cadre.

Un site web s’audite sur un échantillon de pages ; un design system s’audite composant par composant, dans tous ses états, en amont des interfaces qui en héritent. C’est l’accessibilité corrigée à la source.

Découvrez notre audit de site web.

Non. Une bibliothèque de référence, comme celle qu'Ipedis met en accès libre sur design.ipedis.com, montre les bonnes pratiques. Mais chaque design system a ses propres composants, états et variantes : seul un audit vérifie que les vôtres sont réellement conformes, et que les produits qui les utilisent le sont aussi.

Dimensionnons l'audit de votre design system

Composants, fondations, documentation, frameworks : décrivez-nous votre design system, nous calibrons l'audit au plus juste et vous adressons une proposition sur mesure.

Demander mon devis