L’échantillon comprend 50 fichiers Figma issus de 28 équipes produit dans les secteurs SaaS, retail, fintech, secteur public et edtech. Nous avons négocié un accès en lecture seule sur la base d’une non-attribution : rien dans cet article n’identifie une marque, une équipe ou un designer. Les fichiers ont été choisis pour refléter ce qu’un développeur recevrait réellement lors d’un transfert — et non une étude de cas soignée tirée d’un portfolio — aussi avons-nous demandé à chaque équipe de partager le fichier depuis lequel la fonctionnalité la plus récente a été livrée, et non le fichier dont ils étaient le plus fiers. Douze des fichiers provenaient d’équipes disposant d’une pratique dédiée de design system ; les 38 autres étaient des fichiers de niveau produit qui importaient une bibliothèque système ou créaient leurs propres composants en ligne.

Nous avons parcouru chaque fichier en recherchant cinq propriétés d’accessibilité : la conception de l’état de focus sur chaque composant interactif, les annotations de texte alternatif sur chaque image ou icône non décorative, la documentation de l’ordre de lecture dans la mise en page, la gestion des préférences de mouvement pour tout élément animé ou en transition, et la spécification du contraste en mode sombre pour tout composant livré à la fois en thème clair et sombre. Pour chaque propriété, un fichier obtenait la note « documenté » uniquement si un développeur compétent pouvait implémenter le design sans avoir à inventer la réponse par lui-même. « Mentionné dans une note autocollante » ne comptait pas. « Hex spécifié dans un seul état de survol » ne comptait pas. Le critère était le suivant : la décision est-elle présente dans le fichier sous une forme sur laquelle le développeur peut agir sans avoir à poser de questions ?

La conclusion principale est que le transfert, selon ce critère, omet les décisions d’accessibilité bien plus souvent qu’il ne les inclut. La conception de l’état de focus apparaissait sur environ 40 % des composants interactifs du corpus. Les annotations de texte alternatif apparaissaient sur environ 22 % des images qui en avaient besoin. L’ordre de lecture était explicitement documenté dans 16 % des fichiers. Les préférences de mouvement étaient prises en compte dans 10 % des cas. Le contraste en mode sombre — pour les 31 fichiers livrant les deux thèmes — était spécifié pour 30 % des composants. L’écart ne se situe pas dans une seule propriété. Il est présent dans les cinq, et le développeur est laissé à les combler un jugement à la fois.

Sur les quelque 1 800 composants interactifs examinés dans le corpus — boutons, liens, champs de saisie, cases à cocher, interrupteurs, onglets, combobox, éléments de menu, cartes-boutons, tout ce qu’un utilisateur au clavier peut atteindre — environ 40 % étaient livrés avec un état de focus conçu. Les 60 % restants étaient livrés avec un état par défaut, un état actif et un état de survol, puis s’arrêtaient là. Le développeur qui crée le composant choisit un contour de focus au moment de l’implémentation, généralement en copiant le comportement par défaut du navigateur, généralement sans vérifier que ce défaut présente un contraste de 3:1 par rapport à la surface du composant dans les deux thèmes clair et sombre que le fichier livre.

À quoi ressemble « aucune conception d’état de focus » en pratique ? Cela ressemble à un composant bouton avec trois variantes sur le canevas — repos, survol, pressé — et pas de quatrième variante. Cela ressemble à un champ de saisie avec une bordure stylisée et aucun second style de bordure pour l’état de focus. Cela ressemble à un composant case à cocher avec un anneau de focus uniquement sur la variante repos, le développeur étant laissé à deviner si le même anneau doit apparaître sur la variante cochée ou indéterminée. Le schéma se répète d’un composant à l’autre, d’une équipe à l’autre, d’un secteur à l’autre. C’est le plus grand écart d’accessibilité dans le corpus et le plus facile à corriger dès la conception.

Les équipes qui ont bien conçu les états de focus disposaient de l’une de ces deux ressources. La première était une règle explicite du design system : chaque composant interactif doit être livré avec une variante dont le nom commence par focus-, et le composant n’est pas publié dans la bibliothèque tant que cette variante n’existe pas. La deuxième était une propriété de composant Figma appelée state avec focus, focus-visible et focus-within comme valeurs énumérées, de sorte que le navigateur de composants du fichier mette en évidence visuellement les variantes manquantes. Les équipes sans l’un de ces deux scaffolds ont laissé l’état de focus au développeur environ neuf fois sur dix.

Parmi les fichiers du corpus incluant des images de contenu — photographies de produits, illustrations hero, boutons avec icônes uniquement, figures infographiques — 78 % n’avaient aucune annotation de texte alternatif sur les calques d’image. L’image était placée, dimensionnée et stylisée ; l’équivalent textuel que le développeur était censé mettre sur l’élément <img> rendu n’était pas dans le fichier. Huit des 50 fichiers avaient un texte alternatif sur certaines images mais pas toutes, généralement avec l’illustration hero annotée et les images de contenu dans le corps vierges. Trois fichiers avaient un texte alternatif sur chaque image. Le développeur, dans 47 fichiers sur 50, était censé inventer le texte alternatif — et en pratique l’héritait souvent du nom de fichier, de la légende ou de la chaîne qui s’adaptait au rythme visuel.

L’écart est structurel au primitif image de Figma. Il n’existe pas de propriété native « alt » sur un remplissage image ou un calque image ; le texte alternatif doit être porté comme nom de calque, commentaire, note autocollante, document de spécification séparé ou champ ajouté par un plugin. Aucun de ceux-ci ne passe par le panneau d’inspection par défaut, de sorte que le développeur qui lit le fichier en vue d’inspection ne voit pas le texte alternatif même si le designer l’a écrit ailleurs. Les équipes qui ont comblé l’écart de manière cohérente ont utilisé l’une de ces trois solutions : champs de texte alternatif gérés par plugin sur chaque variante d’image, une convention documentée selon laquelle le nom du calque est le texte alternatif, ou une feuille de calcul de texte alternatif distincte associée aux noms de fichiers d’image livrée avec le fichier.

Les boutons avec icônes uniquement constituaient un échec secondaire à l’intérieur de ce mode d’échec. Dans 41 des 50 fichiers, les boutons avec icônes — la loupe de recherche, le hamburger de menu, la croix de fermeture, la flèche de partage — ne comportaient aucune annotation de nom accessible, laissant le développeur écrire aria-label=“Search” à partir du contexte visuel sans confirmation que « Search » était le bon mot dans la voix de la marque (était-ce « Find » ? était-ce « Lookup » ? était-ce vide parce que le bouton ouvre un panneau étiqueté ailleurs ?). La dénomination des icônes est exactement le type de micro-décision rédactionnelle qui bénéficie du regard du designer, et exactement le type que le transfert perd.

Les trois propriétés restantes présentaient des formes d’échec distinctes. L’ordre de lecture — l’ordre dans lequel un lecteur d’écran va narrer la page, qui dans les mises en page responsives modernes n’est plus garanti de correspondre à l’ordre visuel de haut en bas — était documenté dans 16 % des fichiers. La documentation, lorsqu’elle existait, était généralement une superposition numérotée sur le canevas (1, 2, 3…) ajoutée avec un plugin. Les 84 % restants laissaient le développeur mapper l’ordre de lecture à partir de l’ordre DOM qu’il avait écrit, ce qui sur une mise en page CSS Grid avec placement explicite en lignes et colonnes peut diverger de la mise en page visuelle d’une colonne entière.

Les préférences de mouvement s’en sont le plus mal tirées. Dix pour cent des fichiers mentionnaient prefers-reduced-motion du tout. Les 90 % restants spécifiaient des animations et des transitions — entrées de modal, expansions d’accordéon, glissements de snackbar, transitions de page — sans préciser ce que le même composant devrait faire quand l’utilisateur a activé la réduction de mouvement. Le développeur construisait soit le cas de mouvement réduit au moment de l’implémentation (souvent sans référence visuelle), soit livrait la même animation à tout le monde, ce qui est le comportement par défaut et qui viole le critère 2.3.3 Animation provoquée par une interaction pour les utilisateurs qui ont défini cette préférence.

Le contraste en mode sombre était spécifié pour 30 % des composants dans les fichiers livrant les deux thèmes. Les 70 % restants spécifiaient le contraste du thème clair — généralement avec une annotation Stark ou vérificateur de contraste dans le fichier — puis livraient le thème sombre avec une palette inversée, laissant au développeur le soin de vérifier si la paire inversée maintenait encore 4,5:1 pour le texte de corps et 3:1 pour les composants d’interface. Dans environ un cinquième des 31 fichiers à double thème, au moins un composant tombait sous le seuil de contraste en mode sombre parce que la surface sombre et le texte sombre étaient tous deux ajustés pour les calculs de contraste du thème clair, pas du thème sombre.

Les deux plugins qui apparaissent le plus souvent dans le corpus sont Stark et Able. Tous deux sont matures, bien considérés, et tous deux offrent des fonctionnalités qui comblent plusieurs des écarts documentés ci-dessus. Stark ajoute un vérificateur de contraste, une superposition d’ordre de focus, un aperçu en mouvement réduit et un champ d’annotation de texte alternatif sur les calques d’image. Able ajoute un inspecteur de contraste des couleurs, une superposition de simulation de vision et un vérificateur de cibles tactiles. L’un ou l’autre plugin, utilisé de manière cohérente dans un fichier, sortirait ce fichier du dernier quartile du corpus.

Utilisé de manière cohérente est la formule clé. Parmi les 50 fichiers, Stark était installé et visiblement utilisé dans 18, et Able dans 11. Dans les fichiers où le plugin était utilisé, il l’était généralement sur le composant hero et le CTA principal — les composants les plus susceptibles d’être sur le canevas lorsque le designer a ouvert le plugin — et seulement de manière ponctuelle ailleurs. Six fichiers utilisaient Stark dans une passe globale ; un utilisait Able dans une passe globale. Le schéma est le suivant : les plugins existent, les designers les connaissent, ils sont utilisés pour des vérifications ponctuelles, puis la vérification ponctuelle s’arrête aux composants que le designer regardait lorsque le plugin était ouvert.

Les deux équipes qui ont clos l’audit sur l’utilisation des plugins ont fait une chose différemment : elles ont exécuté la fonctionnalité d’audit du plugin sur chaque page du fichier comme étape de validation avant que le fichier soit partagé avec l’ingénierie. L’audit s’exécutait dans le fichier, produisait un rapport, et le rapport devait être vide (ou ses exceptions documentées) avant que le fichier passe de « en design » à « prêt pour l’ingénierie ». C’est le plugin comme workflow plutôt que comme vérification ponctuelle, et c’est la différence entre 80 % de couverture et 20 % de couverture dans notre échantillon.

L’audit produit une checklist et un contrat. La checklist est ce qu’un designer devrait pouvoir cocher avant que le fichier soit partagé avec l’ingénierie. Le contrat est la forme des design tokens qui accompagnent le fichier afin que le développeur mappe les variables Figma aux propriétés CSS personnalisées sans inventer de valeurs intermédiaires. Les deux sont courts intentionnellement : chaque élément de la checklist est une propriété que l’audit a mesurée, et chaque token du contrat est une valeur qui a comblé un écart dans le corpus.

L’audit de 50 fichiers se conclut par une trouvaille simple. Le transfert échoue sur l’accessibilité non pas parce que les designers ne s’en soucient pas et non pas parce que les développeurs ne s’en soucient pas, mais parce que le fichier — le fichier Figma, l’artefact unique que toutes les parties lisent — ne porte pas les décisions d’accessibilité comme propriétés de premier ordre. Les états de focus, le texte alternatif, l’ordre de lecture, les préférences de mouvement, le contraste en mode sombre : chacun est une décision de conception, chacun appartient au fichier, chacun se trouve actuellement ailleurs. Dans une note autocollante, dans un message Slack, dans une feuille de calcul séparée, dans la tête du développeur à 16 h un vendredi.

La solution n’est pas un designer héroïque ou un développeur héroïque. C’est un changement de workflow au niveau de l’équipe : chaque composant interactif est livré avec une variante de focus, chaque image porte un texte alternatif dans un emplacement géré par plugin, l’ordre de lecture est superposé sur toute page non triviale, les animations spécifient leur contrepartie à mouvement réduit, le contraste en mode sombre est vérifié séparément du mode clair, et le fichier est livré avec un contrat de tokens qui nomme chaque variable à laquelle l’implémentation se lie. Aucune de ces étapes n’est nouvelle, aucune ne nécessite un outil que nous n’avons pas déjà, et toute équipe qui les adopte comme étapes de validation comblera la plupart des écarts mesurés en un seul cycle de livraison.

La trouvaille la plus profonde est que les équipes design system le font déjà à un taux environ deux fois supérieur à celui des équipes produit. L’apport que les équipes design system fournissent est exactement l’apport que la discipline de construction d’un système impose : les composants sont nommés, les propriétés sont énumérées, les variantes sont visibles, les tokens sont explicites. Apporter la même discipline aux fichiers de niveau produit — même sans un design system complet en dessous — comble l’essentiel de l’écart de transfert. Ce n’est plus un problème d’outillage. C’est un choix de workflow.