Figma vers HTML accessible : le guide pratique

Réponse rapide : l'accessibilité dans un workflow Figma vers HTML n'est pas un réglage qu'on active — c'est une série de décisions précises : de vrais éléments sémantiques plutôt que des <div> stylisées, un ordre de titres qui correspond à la structure du contenu (Figma n'a aucune notion native de niveaux de titre), des champs de formulaire et des boutons icône-seule correctement étiquetés, des états de focus visibles, un contraste de couleur suffisant, et de l'ARIA utilisé avec parcimonie — uniquement là où le HTML sémantique ne peut pas exprimer l'interaction à lui seul. Le résultat automatisé vous amène déjà la plus grande partie du chemin ; une courte relecture manuelle rattrape encore ce qu'un fichier de design ne peut pas transporter.

Pourquoi l'accessibilité se perd dans la traduction Figma vers HTML

Un fichier Figma décrit à quoi ressemble un design. Il ne décrit pas ce qu'un lecteur d'écran doit annoncer, quel élément doit recevoir le focus ensuite, ni si une paire de couleurs est lisible pour une personne malvoyante. Cet écart est la vraie raison pour laquelle l'accessibilité se casse pendant la conversion — non par négligence, mais parce qu'une partie de ce dont l'accessibilité a besoin n'est tout simplement pas une information que contient un fichier de design. Une correspondance visuelle parfaite au pixel près peut malgré tout être un échec d'accessibilité si le balisage sous-jacent n'est que des <div> génériques, sans structure, sans étiquettes et sans support clavier.

La solution n'est pas une seule passe automatisée. C'est comprendre quelles parties de l'accessibilité un bon convertisseur gère déjà correctement en générant une vraie structure plutôt qu'un balisage purement visuel, et quelles parties exigent toujours une décision délibérée — d'un designer, d'un développeur, ou des deux — parce que le fichier de design ne transporte réellement pas cette information.

Décisions de design dans Figma qui affectent l'accessibilité

Quelques habitudes courantes dans Figma créent des problèmes d'accessibilité en aval, avant même qu'un outil de conversion n'entre en jeu :

• La couleur comme seul signal. Un champ de formulaire obligatoire marqué en rouge, ou un bouton désactivé qui n'est qu'une nuance plus claire de la même couleur — tous deux invisibles pour quelqu'un incapable de distinguer ces teintes. La distinction a besoin d'un second signal (une icône, une étiquette, un motif), pas seulement d'un changement de couleur.
• Du texte figé dans des images. Un titre exporté en PNG aplati peut avoir l'air identique à un vrai calque de texte, mais il ne peut être lu par un lecteur d'écran, redimensionné par le navigateur, ni indexé par un robot.
• Aucun état de focus visuel conçu. La plupart des ensembles de composants Figma ont un état par défaut, un état de survol et parfois un état désactivé — un état de focus (pour les utilisateurs clavier qui naviguent avec Tab) n'est souvent tout simplement jamais conçu, donc il n'y a rien que la conversion puisse reprendre.
• Des boutons icône-seule sans nom accessible nulle part dans le fichier. Une icône de corbeille qui signifie « supprimer » est évidente visuellement. Rien dans le calque Figma ne dit à un convertisseur — ou à un lecteur d'écran — ce que signifie l'icône, à moins que le calque lui-même ne soit nommé de façon explicite.
• Des tailles de titre incohérentes. Figma n'a pas d'élément « Titre 2 » comme un CMS ou un traitement de texte — les calques de texte ne sont que du texte, stylisé pour avoir une certaine taille. Deux titres visuellement similaires dans des frames différentes peuvent représenter des niveaux complètement différents dans la hiérarchie réelle du contenu.

Aucun de ces cas n'est un bug de conversion. Ce sont des décisions qui doivent être prises quelque part dans le pipeline, et mieux vaut le savoir dès le départ plutôt que de supposer qu'un outil les déduira tout seul.

HTML sémantique et repères (landmarks)

C'est la partie de l'accessibilité qu'un bon convertisseur Figma vers code doit gérer correctement par défaut : de vrais éléments <header>, <nav>, <main>, <article>, <section>, <aside> et <footer> plutôt qu'une page entièrement construite à partir de <div> sans étiquette. Les repères (landmarks) comptent parce que c'est ainsi qu'un utilisateur de lecteur d'écran saute directement vers « le contenu principal » ou « la navigation » plutôt que de naviguer linéairement à travers toute la page avec Tab. Voir Figma to Semantic HTML pour ce à quoi ressemble structurellement le résultat de MarkupGen, et Is Figma-to-HTML Output SEO-Ready? pour le recoupement entre balisage sémantique et capacité d'indexation — les deux problèmes partagent une cause racine commune et, en grande partie, une même solution.

Hiérarchie des titres

Un seul <h1> par page, et des titres qui descendent d'un niveau à la fois — un <h3> doit se trouver dans une section qui a déjà un <h2>, pas y arriver directement parce qu'un calque de texte avait cette taille-là dans le design. Comme indiqué plus haut, Figma n'a aucune notion native de niveaux de titre, donc un calque de texte stylisé en grand ne devient pas automatiquement un <h1> — cela vaut la peine d'être vérifié manuellement, quel que soit l'outil qui a généré le balisage, car cela dépend de la compréhension de la structure réelle du contenu, pas seulement de sa taille visuelle.

Boutons vs liens

C'est l'une des erreurs d'accessibilité les plus courantes dans un balisage converti, et la structure des composants Figma ne la résout pas pour vous : un <button> sert à une action sur la page actuelle (soumettre, ouvrir une modale, supprimer un élément) ; un <a href> sert à naviguer vers une autre page ou vue. Un fichier de design plein de formes en pilule stylisées de façon similaire ne donne aucune indication sur laquelle est laquelle — c'est une décision sémantique, pas visuelle, et cela affecte directement à la fois le comportement clavier (boutons et liens répondent par défaut à des touches différentes) et ce qu'annonce un lecteur d'écran.

Formulaires et étiquettes

Chaque champ a besoin d'un véritable <label> associé de façon programmatique — pas d'un placeholder qui en tient lieu. Le texte de placeholder disparaît dès que l'utilisateur commence à taper, a un contraste notoirement faible par défaut, et n'est pas lu de façon fiable par tous les lecteurs d'écran en remplacement d'une étiquette. Si un formulaire doit visuellement paraître sans étiquette pour des raisons de design, utilisez une étiquette masquée visuellement plutôt que de la retirer entièrement du balisage. Les messages d'erreur doivent être associés à leur champ (généralement via aria-describedby), pas simplement placés à proximité avec la seule couleur pour signaler le problème.

Images et texte alternatif

Les images exportées ont besoin d'attributs alt pertinents, pas de chaînes vides ni d'un nom de fichier. C'est un domaine où une relecture manuelle est véritablement incontournable : à quoi sert une image de fond décorative, par rapport à ce qu'une photo de produit a besoin de voir décrit, n'est pas toujours évident à partir du seul frame Figma — le fichier de design ne transporte pas l'intention, seulement les pixels. Les images purement décoratives doivent recevoir un alt="" vide (pour que les lecteurs d'écran les ignorent), tandis que les images porteuses de sens ont besoin d'une véritable description de ce qu'elles transmettent, pas seulement de ce qu'elles montrent.

Navigation au clavier

Chaque élément interactif — liens, boutons, champs de formulaire — doit être atteignable et utilisable au clavier seul, dans un ordre qui correspond à l'ordre de lecture visuel. C'est là qu'Auto Layout aide vraiment : parce que la structure de l'Auto Layout se répercute dans un ordre DOM logique plutôt qu'en fragments positionnés en absolu, l'ordre de tabulation tend à suivre automatiquement l'ordre de lecture au lieu de sauter de façon imprévisible comme cela peut arriver avec des mises en page libres, positionnées en absolu.

États de focus

Comme les ensembles de composants Figma incluent rarement un état de focus conçu, c'est généralement la lacune d'accessibilité la plus commune dans une page convertie : un utilisateur clavier navigue avec Tab dans l'interface et ne peut pas voir visuellement où il se trouve. Au minimum, ne supprimez pas le contour de focus par défaut du navigateur (outline: none) sans le remplacer par quelque chose d'aussi visible — une erreur courante, facile à laisser passer, commise au nom de la fidélité à un design qui n'en tenait jamais compte.

Contraste des couleurs

Figma vous laisse choisir n'importe quelle paire de couleurs, qu'elles soient lisibles ensemble ou non, donc cela demande une vérification explicite plutôt qu'une supposition. Le WCAG AA demande un contraste d'au moins 4,5:1 pour le texte courant et de 3:1 pour le grand texte (18px+ en gras, ou 24px+ normal) ainsi que pour les composants d'interface porteurs de sens comme les icônes et les bordures de champs. Passez les vraies paires de couleurs du design dans un vérificateur de contraste avant la conversion — corriger un token dans Figma coûte bien moins cher que de le traquer ensuite dans tout le balisage généré.

ARIA — quand ça aide, quand ça nuit

La première règle de l'ARIA reste la bonne : pas d'ARIA vaut mieux qu'un mauvais ARIA. Un <button> natif a déjà le bon rôle, est focusable, et répond par défaut à Entrée et Espace — lui ajouter role="button" n'apporte rien d'utile et risque d'entrer en conflit avec la sémantique réelle de l'élément. L'ARIA se justifie précisément là où le HTML sémantique ne peut pas exprimer l'interaction à lui seul :

• À utiliser : aria-label sur un bouton icône-seule sans texte visible (une icône de corbeille signifiant « supprimer »), aria-expanded sur un interrupteur contrôlant une section repliable, aria-live="polite" sur une zone qui se met à jour sans rechargement de page (un message de validation de formulaire, un compteur de panier).
• À éviter : ajouter des rôles ARIA à des éléments qui ont déjà une sémantique native correcte, de l'ARIA décoratif qui duplique ce qui est déjà visible et annoncé, ou aria-live="assertive" sur tout ce qui n'est pas véritablement urgent — cela interrompt la sortie du lecteur d'écran et est facile à surutiliser.

Accessibilité en responsive

Les problèmes d'accessibilité ne restent pas résolus à tous les breakpoints simplement parce qu'ils ont été traités à une seule taille. Les cibles tactiles doivent rester d'au moins environ 44×44px sur mobile même quand les mises en page se compressent — un bouton confortablement cliquable sur desktop peut devenir trop petit pour être touché de façon fiable une fois que les contraintes de redimensionnement de l'Auto Layout le réduisent. Le texte doit se reformer (reflow) plutôt que d'être tronqué ou de se chevaucher aux largeurs étroites, et l'ordre du contenu ne doit pas changer de façon déroutante entre les breakpoints, au point de casser l'ordre de lecture logique dont dépend un lecteur d'écran.

Erreurs d'accessibilité courantes lors du passage de Figma à HTML

• Chaque élément cliquable converti en <div onclick> plutôt qu'en un vrai <button> ou <a>.
• Des boutons icône-seule sans aria-label, parce que le calque Figma s'appelait simplement « Icon 4 ».
• La couleur comme seul moyen de communiquer un état (erreur, désactivé, sélectionné).
• outline: none sur les états de focus sans rien de visible mis à la place.
• Le texte de placeholder utilisé comme seule étiquette d'un champ de formulaire.
• Des images décoratives auxquelles on a donné un nom de fichier comme texte alt plutôt qu'un alt="" vide.
• Des niveaux de titre choisis selon la taille de police dans le design plutôt que la structure réelle du contenu.

Avant / après : un bouton icône-seule

Avant — visuellement correct, pas accessible :

<div class="icon-btn" onclick="deleteItem()">
  <svg><!-- trash icon --></svg>
</div>

Après — même résultat visuel, réellement utilisable :

<button type="button" class="icon-btn" aria-label="Delete item" onclick="deleteItem()">
  <svg aria-hidden="true"><!-- trash icon --></svg>
</button>

La différence n'est pas du tout visuelle — c'est un vrai élément <button> (focusable, utilisable au clavier, annoncé correctement par un lecteur d'écran), un aria-label donnant à l'icône un nom accessible, et aria-hidden="true" sur le SVG décoratif pour qu'il ne soit pas annoncé deux fois.

Checklist pratique d'accessibilité

• Un seul <h1> par page ; les titres descendent d'un niveau à la fois, pas selon la taille de police
• De vrais éléments de repère (header, nav, main, footer) présents
• Chaque action cliquable est un <button> ; chaque lien de navigation est un <a href>
• Chaque champ de formulaire a un vrai <label> associé — pas seulement un placeholder
• Les images porteuses de sens ont un texte alt descriptif ; les images décoratives ont alt=""
• Les états de focus sont visibles sur chaque élément interactif
• L'ordre de tabulation correspond à l'ordre de lecture visuel
• Le contraste du texte et des composants d'interface respecte le WCAG AA (4,5:1 / 3:1)
• La couleur n'est jamais le seul signal pour un état ou une signification
• L'ARIA n'est utilisé que là où le HTML sémantique ne peut pas exprimer l'interaction
• Les cibles tactiles restent utilisables aux breakpoints mobiles
• La mise en page se reforme sans tronquer ni chevaucher le texte aux largeurs étroites

Comment relire le code généré avant la mise en production

Le résultat de MarkupGen privilégie par défaut les éléments sémantiques et une vraie structure de titres, plutôt que comme un réglage à activer soi-même, et le fait que la structure de l'Auto Layout se répercute dans un ordre DOM logique est l'essentiel de ce qui rend possible un ordre de tabulation correct dès le départ. Le score de qualité IA automatique que reçoit chaque export est un premier signal réellement utile — mais c'est explicitement un score de correspondance visuelle, comparant l'aperçu rendu au design original. Il n'audite ni la validité de l'ARIA, ni les ratios de contraste, ni le comportement clavier, parce que rien de tout cela n'est visible dans une comparaison de captures d'écran. Considérez la checklist ci-dessus comme la relecture manuelle qui vient après un score visuel élevé, pas à sa place — voir How to Evaluate AI-Generated HTML Before You Ship It pour le même principe appliqué plus largement à la relecture de code.

Essayez-le sur votre propre design

La façon la plus rapide de voir où un design a besoin d'une relecture d'accessibilité est de le convertir et d'ouvrir le vrai balisage. Essayez MarkupGen gratuitement, ou commencez par le guide complet de conversion Figma vers HTML pour le workflow de bout en bout sur lequel s'appuie ce guide.