Intégrer l'accessibilité dans un produit basé sur un plan de travail

À l'image d'un jeu vidéo, le plan de travail de Figma se charge du rendu à la place du navigateur pour maximiser les performances. Nous pouvons ainsi offrir des fonctionnalités puissantes telles que le zoom infini et le mode multijoueurs en temps réel. Mais comme nous n'utilisons pas de données HTML et DOM traditionnelles pour restituer le plan de travail de Figma, nous ne bénéficions d'aucune des fonctionnalités d'accessibilité intégrées au navigateur par défaut.

Afin que Figma soit accessible à plus de personnes, nous avons créé une structure DOM miroir pouvant demeurer synchronisée avec n'importe quel design Figma. Ici, nous vous faisons découvrir comment nous avons fait en sorte que n'importe quel utilisateur puisse naviguer dans un fichier Figma avec un lecteur d'écran, entendre les modifications à mesure qu'elles sont annoncées et se servir de l'éditeur avec un clavier.

En savoir plus sur les améliorations de l'accessibilité au clavier et au lecteur d'écran de Figma.

Synthèse du modèle DOM

Les moteurs de navigation sont associés à un concept appelé arbre d'accessibilité : une structure de données dérivée du document et contenant les informations non visuelles nécessaires au fonctionnement des technologies d'assistance. Lorsque l'utilisateur d'un lecteur d'écran exécute la commande « accéder au champ de formulaire suivant », l'arbre d'accessibilité indique au lecteur d'écran où aller. Le navigateur conçoit cet arbre à partir du modèle DOM, des données HTML sémantiques, des attributs ARIA et de certains états calculés supplémentaires.

Dans une application web standard, chaque composant possède son propre élément DOM (par exemple, <button>, <p> ou <img>). Mais comme Figma n'utilise pas de code HTML pour le rendu, le plan de travail ne dispose que d'un seul élément <input> qui demeure focalisé quel que soit le nombre de calques figurant dans le design. Cela signifie que l'arbre d'accessibilité du navigateur est pratiquement vide pour un fichier Figma.

Pour résoudre ce problème, nous avons réintroduit des éléments DOM synthétiques pour le plan de travail afin que les lecteurs d'écran puissent naviguer dans les fichiers et les modifier.

Fonctionnement du système

Derrière le plan de travail, invisible pour les utilisateurs voyants, nous effectuons le rendu d'éléments DOM reflétant les parties du graphe de scène importantes pour la technologie d'assistance. Il existe quatre systèmes collaboratifs :

• Un arbre d'accessibilité interne à Figma qui met en cache les détails d'accessibilité de chaque calque de design et effectue des mises à jour chirurgicales au lieu de reconcevoir à partir de zéro lors des modifications.
• Un composant React DOM miroir ayant pour responsabilité d'intégrer les éléments dans le modèle DOM, en se référant à l'arbre d'accessibilité interne.
• Un système de synchronisation bidirectionnelle pour la sélection. Lorsque vous sélectionnez un nœud sur le plan de travail, l'élément DOM correspondant devient actif. Inversement, nous mettons à jour la sélection du plan de travail lorsque les outils de lecteur d'écran sont utilisés pour naviguer dans le modèle DOM miroir.
• Un système d'annonce qui alerte l'utilisateur sur les modifications et autres changements non liés à la navigation (ajustement, changement d'outil et autre opération qui pourrait être évidente pour un utilisateur voyant).

L'arbre d'accessibilité interne

Pour déterminer le rendu de quels éléments DOM effectuer et comment, nous avons travaillé à rebours à partir de ce que le navigateur doit savoir pour concevoir son arbre d'accessibilité. Nous avons donc créé notre propre arbre d'accessibilité interne, qui capture les informations non visuelles dont les lecteurs d'écran ont besoin pour un document Figma donné.

Pour chaque calque du document, nous créons un « résumé accessible » qui sera lu par les lecteurs d'écran. Ce résumé peut dépendre du contexte et du type d'application dans lequel l'utilisateur se trouve. Par exemple, dans les prototypes, nous pouvons omettre la plupart des fonctionnalités d'édition et uniquement émuler le contenu pour l'observateur final : simplement le texte des champs de texte ou le rôle de bouton d'un élément avec interaction par clic. En revanche, les frames de mise en page automatique, qui sont exclues de l'arbre d'accessibilité pour les prototypes, doivent être incluses lorsque l'utilisateur édite un document.

Après avoir résumé les calques un par un, nous parcourons l'arbre de haut en bas, en aplatissant les nœuds omis. Bien que nous concevions entièrement notre arbre d'accessibilité interne au premier chargement d'un document, nous surveillons les modifications au fur et à mesure que la session se déroule afin de pouvoir apporter des mises à jour chirurgicales à notre arbre, évitant ainsi des reconstructions coûteuses.

Le modèle DOM miroir

Notre arbre d'accessibilité étant prêt, nous pouvons générer le modèle DOM. Cette opération est gérée par un composant React qui effectue son propre rendu récursivement, chaque instance de ce composant s'abonnant aux changements dans l'arbre d'accessibilité d'un calque de design spécifique.

function ScreenReaderElement({ layerId }: { layerId: string }) {
  const { label, role, children } = useAccessibleSummary(layerId);
  return <div role={role} ariaLabel={label}>
    {children.map((c) => <ScreenReaderElement key={c} layerId={c}>)}
  </div>
}

Tout en apportant des modifications minimales et progressives à l'arbre d'accessibilité pour suivre les modifications, nous faisons appel à React afin que les modifications apportées au modèle DOM soient aussi minimes que possible.

Un détail du modèle DOM miroir qui peut être surprenant est que nous n'utilisons pas de style visuellement masqué typique pour ce contenu accessible mais visuellement masqué. Alors que de telles techniques permettent aux technologies d'assistance d'interpréter le contenu sans affecter la mise en page de la page, nous avons en fait besoin que les éléments DOM miroir soient mis en page. En effet, la mise en page spatiale d'un document Figma est essentielle à sa signification, et même sans affichage visuel, la position de ces éléments alimente les technologies d'assistance : les amplificateurs d'écran peuvent se déplacer pour que l'élément actif reste dans le champ de vision, les lecteurs d'écran génèrent un contour à contraste élevé pour les utilisateurs malvoyants et les outils de commande vocale peuvent également afficher des indications à l’écran.

Ce calcul de positionnement comporte quelques étapes. Chaque calque d'un design Figma présente une transformation affine : une structure de données de taille fixe qui suit le décalage, l'échelle et la rotation. Les transformations affines sont un outil puissant pour les graphiques informatiques car une séquence de transformations peut être concaténée en une seule transformation. Nous utilisons ces fonctionnalités pour positionner des éléments dans le modèle DOM miroir à l'aide du langage CSS, y compris les rotations ou les déformations.

Assurer la synchronisation entre le focus et la sélection

Les caractéristiques ci-dessus nous permettent de prendre en charge la navigation dans les prototypes et autres contenus « publiés » via un lecteur d'écran. L'étape suivante consistait à prendre en charge la navigation dans les applications « d'édition » dans Figma. Pour ce faire, nous devions rajouter un autre élément que les navigateurs gèrent généralement pour nous : la sémantique de sélection et de focus à laquelle les technologies d'assistance peuvent se relier.

Lors de la navigation dans le plan de travail Figma, la touche Tab change le nœud sélectionné sans changer le focus du clavier système. Cela signifiait que le plan de travail ressemblait à une grosse cible de navigation pour les lecteurs d'écran. Nous devions nous assurer que le focus se déplace vers le nœud sélectionné à l'intérieur du plan de travail, comme s'y attendent les utilisateurs.

Nous avons donc intégré une synchronisation bidirectionnelle (entre la sélection sur le plan de travail et le focus du clavier système) dans notre système DOM miroir. Lorsque vous cliquez sur le plan de travail, l'élément correct est ciblé par le lecteur d'écran, et lorsqu'une action du lecteur d'écran déplace le focus, nous mettons à jour les surlignages de sélection visibles. Grâce à ce système, même les commandes de lecteur d'écran telles que le rotor VoiceOver peuvent sélectionner des nœuds dans le plan de travail de Figma.

Annonce des actions et des changements

Les systèmes d'arbre d'accessibilité interne et de modèle DOM miroir exposent le contenu des fichiers Figma aux technologies d'assistance. Cependant, ces outils seuls ne sont pas suffisants pour l'édition, où l'application doit confirmer en retour à l'utilisateur les actions qu'il effectue. Les gestes tels qu'ajuster, dont les résultats sont évidents pour un utilisateur voyant, doivent également fournir un contexte textuel pouvant être annoncé de façon audible. Il n'existe vraiment qu'une seule façon d'effectuer cela : nous faisons appel aux régions en direct fournies par les navigateurs web dans le cadre de la norme ARIA.

Notre implémentation ajoute un balisage de région dynamique à chaque notification toast dans le produit et prend en charge les annonces invisibles pour les événements qui seraient probablement perçus comme superflus par les utilisateurs voyants (par exemple, la plupart des utilisateurs ne trouveraient probablement pas utile de voir une notification toast confirmer chaque petit déplacement à la touche fléchée, mais ces notifications sont importantes pour l'accessibilité). Nous prenons également en charge la « coalescence » automatique : si plusieurs événements d'une même catégorie surviennent coup sur coup, nous pouvons les fusionner. En reprenant l'exemple des petits déplacements à la touche fléchée, si vous bougez d'un pixel cinq fois de suite, nous pouvons émettre une annonce confirmant « Déplacé de cinq pixels » au lieu de répéter « Déplacé d'un pixel » cinq fois.

Ce qui est en place, et ce qui vient ensuite

Notre travail pour rendre Figma plus accessible s'est développé sur plusieurs années, influencé par le feedback des utilisateurs de technologies d'assistance dans le cadre de notre partenariat avec Fable. Cela a commencé par l'Aperçu du prototype en 2022, puis FigJam en 2023, et nous avons ensuite réalisé des progrès significatifs en 2024 et 2025 : nous avons déployé le paramètre d'adaptation du contenu aux lecteurs d'écran dans Design, Dev Mode et Slides, lancé la première version des commandes clavier du plan de travail, ajouté un mode de contraste amélioré et apporté plus de 15 améliorations supplémentaires axées sur l'accessibilité.

Nous intégrons l'accessibilité dans notre manière de concevoir, de créer et de livrer de nouveaux produits. Chaque fonctionnalité nouvelle est examinée pour s'assurer qu'elle est accessible, et notre équipe investit également dans des outils internes tels qu'un agent IA offrant un contexte spécifique à Figma et des conseils de l'équipe des design systems pour aider à étendre le contexte d'accessibilité à toute l'organisation de développement de produits Figma.

Nous voulons également qu'il soit plus facile de concevoir des produits accessibles dans Figma. Aujourd'hui, vous pouvez déterminer si une combinaison de couleurs répond aux directives d'accessibilité dans le sélecteur de couleurs et renommer les calques visibles pour transmettre ces noms aux lecteurs d'écran. Et nous avons récemment lancé la vérification de design, une nouvelle fonctionnalité de Figma Design qui permet aux designers de comparer les designs à leur design system pour détecter les incohérences et les corriger en un clic, y compris en signalant les contrastes faibles et en suggérant des couleurs conformes à la norme WCAG 2.0 AA ou AAA avant la remise de leur travail aux ingénieurs.

Le travail sur l'accessibilité ne prend jamais vraiment fin. Chaque amélioration contribue à lever un autre obstacle, permettant à plus de personnes de participer au processus créatif, de partager leurs idées et de donner forme aux produits que nous utilisons tous. Nous continuerons d'écouter, d'apprendre et de concevoir en vue d'un avenir plus accessible.