Intégrer l’accessibilité dans un système de design
Corriger l'accessibilité page par page revient à vider la mer à la cuillère. Inscrite dans le système de design, elle se règle une fois, au bon niveau, et se propage à tous les écrans qui en dépendent.
Le scénario est connu des équipes qui ont déjà fait auditer un site : un rapport de quatre-vingts pages, des corrections réparties entre plusieurs équipes, une nouvelle version mise en ligne, puis, six mois plus tard, les mêmes défauts qui réapparaissent sur des écrans neufs. La cause n’est pas la négligence. C’est le niveau auquel on corrige. Quand les boutons, les champs et les fenêtres modales viennent d’une bibliothèque commune, c’est dans cette bibliothèque que l’accessibilité se joue. Relier accessibilité et design system, c’est cesser de réparer les symptômes pour traiter la source.
Le calendrier donne une raison supplémentaire de s’y mettre : l’European Accessibility Act s’applique à partir du 28 juin 2025 à de nombreux services privés (commerce en ligne, banque, transport, communications électroniques), en plus des obligations qui pèsent déjà sur les organismes publics.
Pourquoi le système de design est le bon niveau
Un système de design rassemble des jetons (couleurs, typographies, espacements), des composants (bouton, champ, menu, onglets), des gabarits et une documentation. Tout ce qui y est décidé se répète sur chaque écran qui l’utilise. C’est son intérêt, et c’est aussi son danger : un menu déroulant inutilisable au clavier n’est pas un défaut, c’est un défaut multiplié par le nombre de pages où il apparaît.
L’inverse est vrai. Un champ de formulaire qui associe correctement son libellé, annonce ses erreurs et respecte les contrastes règle plusieurs critères du RGAA sur l’ensemble des formulaires d’une organisation. Aucun audit de page n’a un tel rendement.
Encore faut-il savoir ce que le système peut garantir, et ce qu’il ne peut pas.
| Niveau | Ce qui s’y règle | Exemples de critères WCAG concernés | Qui en répond |
|---|---|---|---|
| Jetons | Couleurs et leurs combinaisons, tailles de texte, styles de focus, espacements | Contraste du texte (1.4.3), contraste des éléments d’interface (1.4.11), focus visible (2.4.7) | Équipe du système de design |
| Composants | Sémantique, nom accessible, états, comportement au clavier, annonces aux lecteurs d’écran | Nom, rôle, valeur (4.1.2), clavier (2.1.1), taille des cibles (2.5.8) | Équipe du système de design |
| Gabarits | Structure de page, régions, liens d’évitement, ordre de lecture | Contournement de blocs (2.4.1), parcours du focus (2.4.3) | Partagé avec les équipes produit |
| Contenu | Textes alternatifs, titres, libellés de liens, messages d’erreur, langue | Contenu non textuel (1.1.1), titres et étiquettes (2.4.6) | Équipes produit et éditoriales |
Les deux premières lignes sont le terrain naturel du système de design. La troisième se partage. La quatrième lui échappe presque entièrement : aucun composant ne rédigera à votre place une alternative textuelle pertinente.
Cinq chantiers, dans cet ordre
- Les jetons de couleur et de focusVérifier chaque combinaison texte-fond autorisée : au moins 4,5:1 pour le texte courant, 3:1 pour le grand texte et pour les bordures et icônes porteuses de sens. Ne documenter que les combinaisons conformes, plutôt que des couleurs isolées que chacun associera à sa guise. Définir un style de focus unique, visible sur tous les fonds, et qui ne soit jamais masqué par un en-tête collant (critère 2.4.11, nouveau dans les WCAG 2.2).
- Les composants les plus utilisésCommencer par les boutons, champs, cases à cocher, menus, fenêtres modales et onglets. Préférer les éléments HTML natifs (un vrai
button, un vraiselectquand il suffit) ; pour les composants complexes, suivre les motifs du guide de pratiques ARIA du W3C (ARIA Authoring Practices Guide), qui décrit le comportement clavier attendu de chacun. Prévoir des cibles d’au moins 24 × 24 pixels CSS (critère 2.5.8). - La documentation de chaque composantUne rubrique « Accessibilité » sur chaque fiche : touches prises en charge, annonces attendues au lecteur d’écran, attributs que l’équipe utilisatrice doit renseigner (libellé, texte d’aide, message d’erreur), erreurs d’usage à éviter. C’est elle qui transforme un composant accessible en écrans accessibles.
- Les testsTrois couches complémentaires. Des tests automatiques dans la chaîne d’intégration, qui bloquent les régressions évidentes. Des tests manuels au clavier à chaque nouvelle version d’un composant. Des tests avec les principaux lecteurs d’écran (NVDA, JAWS, VoiceOver) sur les composants interactifs. Les outils automatiques ne vérifient qu’une partie des critères : la pertinence d’une annonce ou la logique d’un parcours demandent un jugement humain.
- La gouvernanceInscrire l’accessibilité dans la définition de « terminé » d’un composant. Refuser une contribution qui ne la respecte pas, comme on refuserait une contribution qui casse l’affichage. Noter dans le journal des versions toute correction d’accessibilité, pour que les équipes produit sachent quand mettre à jour.
Le contrat avec les équipes produit
Le risque d’un système de design accessible est l’illusion qu’il suffit. Les équipes produit l’utilisent, voient la mention « conforme » sur la fiche du composant et en concluent que leur écran l’est aussi. Or un champ parfait sans libellé, ou avec le libellé « Champ 3 », reste inutilisable.
Chaque composant doit dire clairement ce qu’il garantit et ce qu’il laisse à la charge de celui qui l’emploie. « Ce bouton est accessible au clavier et annonce son état ; vous devez lui donner un intitulé qui décrit l’action. » Cette phrase vaut plus qu’une pastille verte.
Concrètement, le contrat porte sur quelques points : les propriétés obligatoires (un composant ne devrait pas pouvoir s’afficher sans nom accessible, et le développeur doit être averti dès la compilation ou dans la console), les exemples d’usage correct et incorrect, et un canal pour signaler un défaut. Les équipes produit gardent la responsabilité du contenu et de l’assemblage : hiérarchie des titres, ordre de lecture, cohérence des libellés d’une page à l’autre.
Le test au clavier reste l’outil le plus simple pour vérifier que le contrat est tenu. Notre guide naviguer au clavier : tester et corriger le décrit pas à pas.
Les erreurs qui reviennent
Quelques travers se retrouvent dans beaucoup de systèmes de design, quelle que soit leur maturité.
Des composants « accessibles » par ajout d’ARIA. Ajouter un rôle à un div ne lui donne ni le comportement clavier ni la gestion du focus d’un vrai bouton. Le guide du W3C le rappelle : la meilleure ARIA est souvent celle qu’on n’écrit pas.
Une palette conforme, des combinaisons qui ne le sont pas. Chaque couleur a été vérifiée sur fond blanc, mais l’équipe produit pose le texte gris sur le fond beige de la carte. D’où l’intérêt de documenter des paires, pas des teintes.
Le focus supprimé pour des raisons esthétiques. Le contour par défaut du navigateur déplaît ; on le retire sans le remplacer. C’est l’un des défauts les plus fréquents et les plus pénalisants pour les personnes qui naviguent au clavier.
Les composants dérivés. Une équipe copie un composant pour l’adapter, la copie s’éloigne de l’original et ne bénéficie plus de ses corrections. La règle doit être d’enrichir le composant commun, pas de le dupliquer.
Mesurer sans se raconter d’histoires
Un système de design ne se déclare pas accessible ; il se vérifie. Quelques indicateurs simples permettent de suivre la réalité plutôt que l’intention.
- La proportion de composants dont la fiche comporte une rubrique « Accessibilité » complète et testée.
- Le nombre de défauts d’accessibilité remontés par les audits de pages et dont la cause se trouve dans un composant commun.
- Le délai entre le signalement d’un défaut de composant et sa correction publiée.
- La part des écrans de production qui utilisent la dernière version des composants corrigés.
- Le résultat d’un audit RGAA ou WCAG sur un échantillon de pages réelles, renouvelé à chaque version majeure.
Le dernier indicateur est le seul qui compte pour l’usager. Les autres disent si le système progresse dans la bonne direction. Pour situer cette démarche dans l’ensemble des obligations et des chantiers, notre dossier complet sur l’accessibilité numérique fait le point. Notre expertise web accessible commence le plus souvent par l’audit d’un parcours clé et des composants qu’il mobilise : c’est le point d’entrée le plus rentable.
Questions fréquentes
Un système de design accessible rend-il un site conforme au RGAA ou aux WCAG ?
Non, pas à lui seul. Il couvre une part importante des critères techniques (contrastes, focus, sémantique des composants, comportement au clavier), mais la conformité dépend aussi du contenu et de l'assemblage des pages : textes alternatifs, titres, libellés des liens, ordre de lecture. Un audit de pages réelles reste nécessaire.
Faut-il viser les WCAG 2.1 ou les WCAG 2.2 ?
Le RGAA 4.1.2 et la norme européenne EN 301 549 s'appuient sur les WCAG 2.1, niveau AA. Les WCAG 2.2, publiées en octobre 2023, ajoutent des critères utiles (taille des cibles, focus non masqué, authentification accessible). Viser les WCAG 2.2 dans un système de design coûte peu et anticipe les prochaines révisions des référentiels.
Par où commencer quand le système de design existe déjà ?
Par un audit des composants les plus utilisés, pas de tout le catalogue : boutons, champs de formulaire, menus, fenêtres modales, onglets. Corriger ces quelques composants a un effet immédiat sur l'ensemble des produits qui les emploient.
Qui doit être responsable de l'accessibilité dans l'équipe du système de design ?
Toute l'équipe, avec une personne référente qui maîtrise les référentiels et les tests avec technologies d'assistance. La référente valide les composants ; elle ne doit pas devenir le seul endroit où l'accessibilité est pensée.