Figma Sites, une belle promesse… encore inaccessible ?

Also available in: English

Le 08 mai dernier, Figma a levé le voile sur plusieurs nouveautés dont Figma Sites, une fonctionnalité qui promet de révolutionner la création de sites web directement depuis leur interface de design. À ses côtés, Figma Make (AI & Code) , Figma Buzz (composant communautaire à la Canva) et Figma Draw (dessin vectoriel) ajoutent de nouvelles cordes à l’arc de la plateforme.

Pourtant, en tant que designer attentif à l’accessibilité numérique, une chose saute aux yeux dès les premières minutes de test : si l’intention est belle, la base même de l’accessibilité est encore très bancale, voire bâclée. Certes, Figma permet déjà d’utiliser quelques balises sémantiques comme <header>, <footer>, <section> ou encore les niveaux de titres (h1, h2, h3). Mais bien d’autres éléments essentiels brillent par leur absence : pas de balises de liste (ul, ol, li), pas de tableau (table, thead, th, td), pas d’attributs personnalisés (hreflang, lang, dir, etc.) et surtout, pas de formulaire (form, input, label, button, etc.). Côté attributs ARIA ? C’est le désert.

Pour effectuer mon test, j’ai ouvert l’un des exemples fourni par Figma Sites, et j’ai utilisé un maximum d’outils mis à disposition par Figma pour rendre le site moins inaccessible.

Cet article n’a pas pour but de fustiger un outil encore en bêta, mais bien de souligner des priorités essentielles. Car pendant que du temps est investi dans des effets de rotation ou d’animation cosmétique, l’accès à l’information – fondement même du web – est négligé. Il serait dommage que ce nouvel outil, aussi prometteur soit-il, parte sur des bases excluantes dès sa naissance.

Voici donc une lecture critique et constructive de Figma Sites, avec pour ambition d’aider la plateforme à évoluer dans le bon sens : celui de tous les utilisateurs.

---

L’importance de l’accessibilité en design web

Mais avant d’attaquer sur le sujet même de Figma Sites, revenons un peu sur les bases et fondements du design moderne, et de l’accessibilité.

Pourquoi l’accessibilité n’est pas une option

L’accessibilité, ce n’est pas une “feature” à activer plus tard. C’est un fondement du web, au même titre que la compatibilité mobile, la performance ou la sécurité. L’ignorer, c’est priver une partie de la population de l’accès à l’information ou aux services proposés ; en soit, c’est priver l’individu de son autonomie. C’est aussi une manière de renforcer les inégalités, volontairement ou non.

D’un point de vue légal, plusieurs pays, dont ceux de l’Union européenne, imposent désormais des standards d’accessibilité pour les services publics et les entreprises. Le RGAA, le RAWeb, le WCAG, et le European Accessibility Act ne sont plus de simples recommandations. À partir de 2025, ignorer ces exigences, c’est aussi prendre un risque juridique.

Mais surtout, l’accessibilité est une marque de respect. Respect pour la diversité des usages, des corps, des esprits. Elle est un levier d’inclusion, d’opportunités, une obligation morale et non pas une contrainte technique.

Ce que les designers attendent d’un outil « moderne »

Un outil de création de sites en 2025 ne peut plus faire l’impasse sur l’accessibilité. Ce que les designers attendent d’un outil dit « moderne », ce n’est pas juste une interface fluide ou un onboarding avec des micro-interactions léchées. C’est la possibilité de construire des fondations solides : du balisage sémantique, des formulaires accessibles, une navigation clavier cohérente, des labels visibles et compréhensibles.

En clair, un outil moderne doit être capable de faire émerger de bonnes pratiques, pas d’encourager des effets cosmétiques au détriment de l’essentiel. Nous, designers, proposons des interfaces pour que des êtres humains puissent accéder à un contenu, service ou produit, et pas uniquement pour satisfaire nos egos artistiques. C’est aux outils que nous utilisons de montrer l’exemple.

Les bénéfices pour les utilisateurs

Quand un site est accessible, tout le monde y gagne :

• Les personnes non-voyantes peuvent naviguer avec un lecteur d’écran ;
• Les personnes avec un handicap moteur peuvent tabuler dans les interfaces ;
• Les personnes neuro-divergentes accèdent à une interface plus claire et plus prévisible ;
• Les personnes âgées ou peu technophiles trouvent un site plus lisible et rassurant.
• etc.

Mais plus globalement, l’accessibilité bénéficie à tous les utilisateurs : un contraste bien pensé, une structure claire, un formulaire bien labellisé… ce sont aussi des atouts pour les utilisateurs pressés, distraits, sur mobile, ou dans des environnements bruyants ou instables.

Rappelez-vous que c’est aussi un bénéfice pour vous : en vieillissant, vous perdez certaines de vos facultés. Penser accessibilité maintenant, c’est investir dans votre propre avenir.

Les bénéfices pour les entreprises

Investir dans l’accessibilité, ce n’est pas une perte de temps. C’est un levier de performance :

• Vous touchez un public plus large (vieillissement de la population, situations temporaires de handicap, utilisateurs mobiles) ;
• Vous améliorez votre référencement naturel. Les balises sémantiques et les alternatives textuelles sont aussi utiles à Google ou aux IA qui vont pousser vos contenus et service ;
• Vous réduisez les coûts de maintenance en structurant mieux votre code et vos composants ;
• Vous valorisez votre image de marque en vous engageant sur un sujet sociétal fort.

En clair : un site accessible, c’est un site plus inclusif, plus clair, plus efficace, et plus durable.
Pourquoi s’en priver alors que c’est un gain sûr contre la concurrence ?

---

Ce que Figma Sites propose aujourd’hui

Voyons un peu ce que Figma Sites propose du côté accessibilité, et le chemin qu’il lui reste encore à parcourir.

Une base sémantique en cours de construction

L’arrivée de Figma Sites introduit une fonctionnalité attendue depuis longtemps par les designers : la génération de sites avec une structure HTML intégrée, sans quitter l’univers de Figma. Dans sa version actuelle (bêta), l’outil permet d’ajouter certains éléments sémantiques directement via l’interface :

• Des balises de structure comme <article>, <header>, <footer>, <section>, <aside>, <main>, <nav> et <section> ;
• Des niveaux de titres jusqu’à h6 (de h1 à h6) ;
• Un attribut alt parfois interprété.

Cette initiative est saluée, car elle permet une première couche de compréhension du contenu par les technologies d’assistance, et donc une approche un peu plus responsable qu’une soupe de <div>. (voir plus loin pour les manques à ce propos)

Ce qui est dommage, c’est de voir cette option rangée dans Accessibility, là où, selon moi, c’est la base d’un web sémantique qui sert bien plus de fonctions que l’accessibilité.
Le HTML et CSS, c’est tellement simple, que la plupart des développeurs front-end aujourd’hui n’ont même plus les bases de connaissances utiles pour éviter leur soupe de <div>.

Ce que cela permet déjà de faire

Avec ces premiers outils, un designer peut :

• Structurer visuellement et sémantiquement une page ;
• Marquer les zones principales du site (navigation, contenu, pied de page) ;
• Hiérarchiser le contenu textuel à l’aide des balises de titres ;
• Anticiper une meilleure indexation et accessibilité des contenus pour le web.

Autrement dit, Figma Sites dépasse le simple prototype : il amorce la création de sites prêts à être explorés par des utilisateurs – humains ou machines. Mais ce n’est pas suffisant.

Ce que cela laisse espérer ? Que Figma Sites est un terrain fertile, mais encore très peu cultivé côté accessibilité. La promesse est là, mais la mise en œuvre ne répond pas (encore) aux exigences minimales d’un web pour tous.

---

Les manques flagrants dans Figma Sites (à date)

Une fois passé l’enthousiasme des premières heures, un constat s’impose : l’accessibilité est loin d’être au rendez-vous. Beaucoup d’éléments essentiels à la navigation, à l’interaction (pas au sens que Figma lui donne) et à la compréhension du contenu sont encore absents.

Si Figma Sites amorce une structuration HTML bienvenue, il reste encore largement insuffisant pour produire des sites réellement accessibles. Voici une revue des principaux manques, à la fois techniques et fonctionnels, que l’on rencontre dans cette version bêta.

Pas de listes sémantiques

Il est actuellement impossible de structurer un groupe d’éléments en liste (<ul>, <ol>, <li>) de manière personnalisée. Cela empêche :

• de rendre compte d’un contenu répétitif (services, étapes, points-clés, etc.) ;
• de fournir aux lecteurs d’écran une information sur le nombre d’éléments ou leur ordre ;
• de permettre une navigation fluide pour les personnes utilisant un lecteur d’écran.

C’est un manque fondamental pour la lisibilité, la navigation, et la compréhension du contenu.

Bien sûr, vous pouvez utiliser la fonction textuelle de base de Figma créant automatiquement des listes non-ordonnées ou ordonnées, mais il vous sera impossible de définir qu’un ensemble de logo est une liste de logos, ou qu’un ensemble de liens de navigation principale est une liste de liens.

Pas de tableaux pour les données

Aucune possibilité de créer des tableaux structurés (<table>, <thead>, <th>, <td>…). On ne peut donc pas :

• présenter proprement des données chiffrées, horaires, comparatifs ;
• fournir les bonnes associations entre cellules d’en-tête et de contenu ;
• rendre ces informations compréhensibles pour les technologies d’assistance.

L’information reste alors « visuelle », mais perd toute sa logique structurelle.

Créer des tableaux dans Figma a toujours été plus ou moins un challenge suivant les périodes (qui se souvient d’avant auto-layout ? :D), nous restons dans la même trempe, mais avec un problème technique et sémantique ici.

Peut-être que la mise en page en grille (Grid Layout) nouvellement arrivée pourrait proposer cette option.

Formulaires : les grands absents

L’absence totale de composants de formulaires (<search>, <form>, <label>, <input>, <textarea>, <button>, <fieldset>, <legend>, etc.) est un véritable frein à toute interaction :

• impossible de créer une prise de contact accessible ;
• aucune structure pour associer un champ à son libellé ;
• aucune gestion du focus, des états d’erreur, ou des retours utilisateurs.

On ne peut tout simplement pas envisager un site fonctionnel sans formulaire accessible. Même si les formulaires vont venir avec un ensemble d’autres questions, comme « où stocker la donnée envoyée ? » ou encore « quel service traite ou récupère la donnée ? », il va être nécessaire pour Figma de pousser ces fonctionnalités pour être concurrentiels.

D’ailleurs, pour mieux construire vos formulaires, j’ai une checklist et un livre sur les formulaires web pour vous.

Aucune prise en charge des attributs ARIA

Les attributs ARIA (rôles, états, propriétés) permettent d’enrichir la sémantique, notamment dans les cas où le HTML ne suffit pas. Figma Sites ne propose à ce jour :

• aucun moyen d’assigner un role ou un attribut ARIA à un élément personnalisés,
• aucun repère dynamique pour les lecteurs d’écran,
• aucun moyen de cacher certains contenus aux lecteurs d’écrans, notamment les éléments décoratifs ou redondants.

C’est un manque critique pour des composants complexes comme des menus, onglets, accordéons ou modales. Cependant, j’ai vu un label-ARIA sur un composant démo, sans savoir comment il est apparu, ni comment en proposer davantage.

Pas de gestion du focus clavier

Le focus clavier, c’est un peu la base de l’accessibilité en navigation alternative à la souris. Des personnes avec des handicaps moteurs ou visuels, peuvent n’utiliser que des assistants proches du clavier, et jamais de souris.

L’équivalent sur votre clavier, c’est d’utiliser la touche Tab pour prendre le focus sur l’élément suivant dans la page, ou Shift + Tab pour l’élément précédent. Pour savoir où vous vous trouvez, il est donc indispensable de proposer une sorte de focus ring autour de l’élément pour le mettre en exergue.

Cependant, à ce jour :

• impossible de gérer l’ordre de tabulation ; (nécessaire puisque Figma place en fin de code les éléments en position Fixed)
• pas de visibilité d’état actif au clavier (focus ring ou autre) ;
• aucune assurance que les composants soient navigables sans souris puisque beaucoup d’intéraction « lien » sont en fait des role=link avec un href sur un <div> et un événement onlick. (pour les non-techniciens : des éléments non sémantiques, non focusable, ou non activable au clavier)

Cela rend l’usage au clavier (ou avec des aides techniques) très aléatoire, voire impossible.

Titres de pages en doublon

On observe également un manque de contrôle sur les balises de titres, qui peuvent se retrouver dans un ordre incohérent (h1 puis h3, sans h2 par exemple), mais également de contrôle de titre de page (titre de l’onglet) qui doit toujours être unique pour des raisons de repère. Cela nuit à :

• la hiérarchie du contenu ;
• la compréhension globale de la page ;
• la navigation par titres, très utilisée en accessibilité ;
• la compréhension de l’utilité de la page.

Un aspect qui va peut-être au-délà des classiques manques, mais que Webflow gère dans son audit avant publication, dont Figma semble s’être inspiré. D’ailleurs j’ai écrit un article sur Webflow sur ce blog.

Visibilité réduite de la structure HTML

Enfin, l’interface actuelle de Figma Sites ne permet pas de visualiser facilement quelles balises sont utilisées. Il faut cliquer sur chaque élément pour voir sa nature sémantique, sans vue d’ensemble. Cela complique, la vérification rapide de la structure, l’audit d’accessibilité éventuel, la cohérence entre les composants et risque de noyer les efforts dans un ensemble d’autres éléments non sémantiques.

Voici une idée, fortement inspirée de ce que fait WordPress, pour mettre en avant les éléments sémantiques utilisés.

D’autres informations d’accessibilité pourraient alors ainsi être transmises via la représentation graphique du calque.

---

Quand l’esthétique prend le pas sur l’essentiel

Dites-moi que vous avez ignoré les recommandations de vos spécialistes en accessibilité sans me dire que vous avez ignoré les recommandations de vos experts.

Des effets visuels soignés… mais accessoires

Dès les premières minutes avec Figma Sites, une chose saute aux yeux : l’attention portée aux options d’effets visuels et inversement proportionnelle à celle portée à l’indispensable accessibilité. Transitions soyeuses, composants en “spinning” lors du chargement, animations micro-interactives… on sent que le soin des effets visuels a mobilisé des ressources.

Mais posons-nous une question simple : à quoi servent ces animations si l’information n’est pas accessible ? Ces animations, et non interactions, visent à créer une sensation dynamisme ou de “modernité”, mais ils ne répondent à aucun besoin fonctionnel ou universel.

Les vraies interactions « Hover effect » et « Press effect », qui sont des interactions entreprisent par l’utilisateur, sont un bon début. Il manquerait juste un « Focus effect » pour compléter ces interactions utiles.

Des “interactions” qui n’en sont pas

Autre dérive constatée : l’usage du terme “interaction” pour désigner en réalité… des animations d’entrée ou de scroll, ou de spin.
Ce type de fonctionnalités, bien que séduisant à première vue, peut poser plusieurs problèmes :

• elles ralentissent ou masquent temporairement l’information, ce qui gêne particulièrement les personnes ayant des troubles cognitifs ou de la concentration ;
• elles n’ont pas de sens fonctionnel (aucune action réelle n’est déclenchée) ;
• elles perturbent la navigation si mal gérées (et elles le sont souvent).

Il serait temps de rappeler que l’accessibilité, c’est aussi éviter l’inutile. Une interface efficace ne cache pas l’information derrière une chorégraphie.

Autre chose que Figma peut mettre en place : le respect des préférences utilisateur. Grâce aux API navigateur disponibles aujourd’hui, il est possible de limiter les animations si les utilisateurs ont déclaré ne pas en vouloir. Figma devrait utiliser cette fonction pour limiter les animations.

Vous en saurez plus en lisant mon livre et checklist sur l’accessibilité pour les designers.

Des priorités qui interrogent

Le plus troublant, ce n’est pas qu’il y ait des animations. C’est l’ordre des priorités produit que cela suggère :

• L’équipe a consacré du temps à peaufiner ces effets destinés à un petit pourcentage d’utilisateurs très à l’aise avec le visuel, dans un contexte calme, connecté, sans contrainte.
• Pendant ce temps, trop peu a été prévu pour les 20% de la population mondiale en situation de handicap, qui attendent des fondations minimales : lisibilité, navigation clavier, balises sémantiques, rôle ARIA.

Vous allez me dire que c’est normal, d’un point de vue marketing, c’est plus facile de vendre des animations, plutôt que de vendre les bénéfices direct pour les êtres humains. Si vous pensez cela, alors peut-être qu’il manque une forme d’éducation plus générale sur l’inclusion et les bénéfices que l’accessibilité apportent, même pour les personnes sans handicaps 😉

Peut-être aussi que c’est moins vendeur pour les financeurs ? Mais ça serait dommage de les insulter d’idiots en leur faisant croire que des animations sont plus utiles que l’accès à l’information, non ?

L’accessibilité n’est pas un luxe qu’on ajoute après, c’est la fondation du web sur laquelle nous devrions tous et toutes construire. Créer des effets sans structure, c’est comme peindre un mur avant d’avoir coulé les fondations.

Le problème ici n’est pas d’avoir mis des animations, mais d’avoir oublié d’abord les fondamentaux.
L’accessibilité n’est pas un plugin ou une « option pro » : c’est la base d’un produit responsable, durable, et réellement utile.

---

Figma, vous tenez quelque chose : suggestions concrètes

Il est temps de penser à une roadmap plus sérieuse sur l’accessibilité, mais la base est déjà là, il faut juste l’étendre un peu et renforcer ces fondations.

Une base est là, mais il manque des briques fondamentales

Si Figma Sites a initié un socle sémantique, il reste incomplet. Voici une liste de compléments essentiels à intégrer dans un court/moyen terme pour ouvrir le champ de l’accessibilité réelle :

Balises HTML structurantes à intégrer

• Listes : <ul>, <ol>, <li>
• Tableaux : <table>, <thead>, <tbody>, <tr>, <th>, <td>
• Formulaires : <form>, <label>, <input>, <textarea>, <select>, <button>, <fieldset>, <legend>
• Ancres internes : <a href=""> aujourd’hui les ancres dans une page sont des liens sans href, ils ne sont donc jamais rendu navigables au clavier.

Attributs (ARIA) et sémantique enrichie

• l’attribut alt est proposé partout dans Figma, mais n’est pas récupéré dans le code source, notamment pour les SVG (qui ne devraient pas avoir d’attribut alt, mais un nom accessible ou une alternative textuelle)
• role (ex: role="navigation" par défaut pour les <nav>, role="dialog", etc.)
• aria-label (pour nommer les différentes navigations par exemple), aria-labelledby, aria-describedby
• aria-hidden, aria-expanded, aria-controls, aria-live
• tabindex, aria-current (pour la page courante d’un site), aria-disabled

Cela permettrait d’aller au-delà des balises HTML et d’assurer un vrai dialogue avec les technologies d’assistance.

---

Une roadmap d’accessibilité simple et progressive

Figma n’a pas besoin de tout faire d’un coup. Mais il est urgent de structurer une feuille de route crédible, et de la partager avec la communauté. Si un outil de design qui se veut être le pont entre les designers et les développeurs ne peut pas faire cela, ça serait le comble.

 Étape 1 — Complétion sémantique

• Intégrer les balises HTML manquantes (listes, tableaux, formulaires)
• Structuration automatique ou semi-guidée des titres (h1 → h6)
• Avertissement en cas de titres désordonnés ou doublons

Étape 2 — Interactions accessibles

• Navigation clavier cohérente (ordre, focus, visibilité)
• Possibilité de tester les comportements à l’intérieur de Figma Sites

Étape 3 — Enrichissement ARIA

• Ajouter les rôles ARIA de base et une interface pour les manipuler
• Associer labels et inputs de manière explicite
• Créer des composants interactifs accessibles (modales, accordéons…)

Étape 4 — Accessibilité avancée (long terme)

• Intégration de tests automatiques (a11y linter ou axe-core)
• Simulation d’un rendu screen reader (lecteur d’écran virtuel)

---

Redéfinir ce qu’est un MVP en 2025

Il serait bon que Figma redéfinisse son concept de MVP (“Minimum Viable Product”). Car aujourd’hui, un produit “viable” ne peut plus se contenter d’un rendu esthétique. Il doit aussi :

• être lisible, navigable, compréhensible ;
• s’adresser à tous les publics, pas seulement les plus privilégiés.

Une bêta qui n’intègre pas un minimum d’accessibilité n’est pas un point de départ neutre : c’est une dette déjà créée, et une insulte envers les personnes handicapées.

Et une dette d’accessibilité, on le sait, coûte plus cher à corriger plus tard. Mieux vaut donc prévoir une vraie roadmap inclusive dès la phase bêta, avec des étapes claires, documentées, et ouvertes à la contribution.

---

En conclusion : une bêta, oui, mais pas une excuse

Figma Sites a des airs de révolution dans l’écosystème design. Pouvoir créer des sites sans quitter son outil de design, avec un rendu HTML/CSS en prime, c’est enthousiasmant. Mais cette révolution ne doit pas être à demi-inclusive.

Oui, nous sommes sur une version bêta. Mais une bêta, ce n’est pas un joker pour ignorer les bases. C’est justement le moment parfait pour poser des fondations solides. Ignorer l’accessibilité dès le départ, c’est créer une dette technique et humaine qu’il sera difficile de rembourser demain.

Ce que Figma Sites a montré jusqu’ici, c’est une volonté de bien faire… mais des priorités produit mal alignées. On a privilégié les paillettes visuelles là où on attendait un sol stable. On a investi du temps pour un effet “spinning” là où des millions de personnes n’ont toujours pas de balises pour lire ou remplir un formulaire.

Cet article n’est pas une plainte. C’est une main tendue.

Pour que Figma puisse devenir un outil réellement moderne, il devra aussi devenir un outil accessible. Et cela commence aujourd’hui, avec l’aide de toute une communauté prête à tester, proposer, documenter.

Il reste beaucoup à faire. Mais il est encore temps de revoir la feuille de route, et de construire un web que tout le monde pourra utiliser, et pas seulement admirer. Nous ne sommes pas des artistes, nous sommes des designers qui souhaitons aller plus loin que de simples concepts agréables à l’œil.