Une maquette Figma magnifique, livrée sans aucune indication sur l’ordre de tabulation ni sur le comportement attendu au clavier, place l’intégrateur devant un choix par défaut : improviser. Et improviser signifie généralement reproduire l’ordre visuel de gauche à droite, de haut en bas, sans se poser la question de savoir si cet ordre correspond réellement au parcours logique attendu par le designer, notamment sur une mise en page en colonnes ou avec des éléments superposés.
Ce problème est structurel : Figma décrit une apparence, pas un comportement. Rien dans l’outil n’oblige un designer à préciser ce qui se passe lors d’une tabulation, ni quel rôle sémantique doit porter un composant qui ressemble visuellement à un bouton mais qui, dans certains cas, devrait être un lien. Sans annotation, cette information n’existe nulle part avant que le code ne soit écrit, au prix de plusieurs allers-retours coûteux entre designer et intégrateur.
Les cinq annotations minimales à exiger
Sur un projet WordPress avec composants sur mesure, la checklist suivante suffit à couvrir l’essentiel sans transformer le designer en expert technique :
- Ordre de tabulation : un numéro sur chaque élément interactif de la maquette, indiquant l’ordre attendu, particulièrement utile sur les mises en page en grille ou en colonnes multiples.
- Rôle attendu : préciser si un élément qui ressemble à un bouton doit se comporter comme un lien (navigation vers une autre page) ou comme un vrai bouton (action sur la page en cours), car ce choix détermine la balise HTML à utiliser.
- États du composant : au minimum l’état focus, l’état actif/ouvert pour un accordéon ou un menu, et l’état d’erreur pour un champ de formulaire, avec leur rendu visuel respectif.
- Texte alternatif prévu : pour chaque image porteuse d’information (pas les images purement décoratives), une proposition de texte alternatif ou au minimum l’intention informative de l’image.
- Comportement au clavier attendu pour les composants riches : un carrousel, un accordéon ou un menu déroulant doit préciser si les flèches, l’échap ou l’entrée sont censés déclencher une action particulière.
Comment intégrer ces annotations dans Figma
Ces informations peuvent être posées directement dans le fichier Figma via des calques annexes nommés explicitement (« annotation-tabulation », « annotation-role »), ou via le plugin de commentaires natif de l’outil, associé à chaque composant concerné. L’essentiel est que ces annotations vivent dans le même fichier que la maquette, pas dans un document séparé que personne ne consultera au moment de l’intégration.
Exemple de commentaire Figma sur un composant "carte produit" :
- rôle : lien (toute la carte mène à la fiche produit)
- ordre de tabulation : 3 (après le menu, avant le fil d'Ariane)
- image : décorative si le nom du produit est déjà affiché en texte
- état focus : contour bleu #1a4b8c, 2px, offset 2px
Ce que cette étape ne remplace pas
Ces annotations cadrent l’intention du designer, mais ne dispensent pas l’intégrateur de vérifier techniquement, une fois le composant codé, que le comportement réel correspond à l’intention annotée. Un ordre de tabulation demandé dans Figma peut nécessiter un ajustement de l’attribut tabindex ou, plus proprement, une réorganisation de l’ordre du DOM source, ce qui reste une décision purement technique à la charge du développeur.
Le bénéfice concret sur un projet
Sur un projet de thème sur mesure avec une dizaine de composants riches (carrousel, filtre de recherche, onglets), l’absence d’annotations se traduit généralement par plusieurs cycles de correction après recette, une fois que le client ou le testeur d’accessibilité signale des incohérences. Avec des annotations posées en amont, ces allers-retours diminuent nettement, car les choix structurants ont été validés avant l’écriture du code plutôt qu’après.
Demander une annotation d’accessibilité avant l’intégration coûte quelques minutes au designer ; l’absence de cette annotation coûte des heures de correction après recette.
En résumé
Une maquette Figma, aussi soignée soit-elle visuellement, ne transmet naturellement aucune information sur l’ordre de tabulation, les rôles sémantiques ou le comportement clavier attendu. Exiger un petit ensemble d’annotations avant intégration, plutôt que de laisser l’intégrateur improviser, réduit fortement les corrections tardives et clarifie la responsabilité de chaque décision d’accessibilité entre design et développement.
