--- title: Le contraste ne se vérifie pas seulement dans la maquette description: 'Un test vert, une couleur qui n''existait nulle part et trente écrans trop pâles : comment vérifier le contraste réel et empêcher les régressions.' url: https://sxnlabs.com/web/2026/07/30/accessibilite-ne-se-verifie-pas-dans-la-maquette/ lang: fr date: '2026-07-30T09:00:00+02:00' tags: - Accessibilité - Design system - Tests - Front-end --- # Le contraste ne se vérifie pas seulement dans la maquette Une charte graphique peut être magnifique sur le papier et produire des écrans qu'une partie de vos utilisateurs n'arrive pas à lire. Ça m'est arrivé récemment, sur une interface que je développe : des centaines de textes trop pâles sur leur fond, dont le libellé du bouton principal et la barre d'onglets, sur une trentaine d'écrans. Aucune revue de design ne l'avait vu. Je ne parle ici que d'un morceau de l'accessibilité : le contraste des textes et des indicateurs. Il est visible, mesurable, et pourtant étonnamment facile à rater.
Le même écran présenté deux fois : à gauche dans la maquette, contrasté et lisible ; à droite en plein soleil, délavé, le bouton principal et la barre d'onglets presque invisibles
À gauche, l'écran validé en revue. À droite, le même écran dehors, celui que l'utilisateur a vraiment sous les yeux.
## Ce que la maquette ne montre pas Une revue regarde une intention, sur un bel écran, dans de bonnes conditions. La vraie vie, c'est aussi le même écran en plein soleil, sur un téléphone d'entrée de gamme, ou lu par quelqu'un de soixante ans. Un texte gris clair sur fond coloré peut sembler « stylé » dans le fichier de design et devenir invisible dehors. Dans cette interface, beaucoup de textes sont posés sur un dégradé, une transparence ou un mélange de teintes. La couleur à juger est celle obtenue une fois les couches composées, dans chaque thème et chaque état, pas seulement celle inscrite dans le fichier. La maquette peut et doit éliminer une partie des erreurs. Elle ne peut pas, à elle seule, prouver que l'implémentation finale reste lisible partout.
À gauche, un aplat orange portant la couleur déclarée dans le code ; à droite, le même libellé blanc posé sur le dégradé réellement peint, dont l'extrémité claire tombe à 1,5:1
La couleur écrite dans le fichier n'est qu'un aplat. Ce qui est peint, c'est un dégradé, et le texte blanc y descend jusqu'à 1,5:1 là où AA en demande 4,5.
## Ce qu'un score vert ne prouve pas Le réflexe suivant consiste à lancer Lighthouse, obtenir un joli score vert et cocher la case. Mais un score vert ne prouve pas que chaque texte est lisible. Il signifie que les contrôles automatisables n'ont pas détecté de problème. Les dégradés, les images de fond et certaines superpositions restent difficiles à analyser : ils demandent une vérification dédiée. Le piège le plus instructif venait de notre propre contrôle. Pour juger un dégradé, il en calculait la couleur moyenne. Une plaque qui va du sombre au clair donnait donc une moyenne rassurante, une couleur peinte nulle part sur l'écran. Le test passait au vert sur une fiction.
Un dégradé du violet foncé au corail clair : la moyenne des deux extrémités atteint 4,51:1 et passe le test, alors que le point le plus clair tombe à 3,24:1 et échoue
Le même dégradé jugé de deux façons. Sur la moyenne, le contrôle passe au vert. Sur l'endroit le plus défavorable, il échoue.
Un contrôle qui affiche vert sur une couleur qui n'existe pas vend de la tranquillité sans rien garantir. Nous l'avons corrigé pour qu'il juge l'endroit le plus défavorable du dégradé, pas sa moyenne. ## Pourquoi c'était un problème de produit Les pires cas n'étaient pas des détails décoratifs. C'était le bouton sur lequel tout le monde clique, la barre de navigation, et le petit cadre qui indique où on se trouve quand on navigue au clavier. Les éléments que tout le monde touche, à peine visibles pour une partie des gens. Un texte trop pâle, ce n'est pas « un peu moins joli ». C'est un utilisateur qui ne trouve pas le bouton, qui abandonne, qui appelle le support. Sur un produit grand public, la lisibilité est un chiffre de conversion avant d'être une case de conformité. ## Ce que nous avons corrigé, et ce qui reste Nous avons combiné les trois niveaux qui manquaient : la revue de design, le contrôle automatique et l'inspection de l'interface réellement rendue dans le navigateur. Aucun ne suffit seul. Ensemble, ils permettent de trouver les erreurs évidentes, les erreurs d'implémentation et les cas que l'automatisation ne sait pas trancher. Le point qui compte pour un dirigeant : aucune couleur de marque n'a bougé. Ce qui a changé, c'est l'encre posée dessus. Chaque type de fond a désormais sa couleur de texte dédiée, décidée une fois dans le système de design plutôt que choisie à l'œil écran par écran. Nous sommes passés de centaines de cas insuffisants à une poignée. Cette poignée est constituée de textes blancs sur le dégradé de marque, là où aucune couleur de texte unique ne respecte le seuil sur toute la surface. Les connaître ne les rend pas conformes : ce sont des écarts résiduels qu'il reste à traiter en faisant évoluer la composition, par exemple avec un fond local ou un placement différent, sans nécessairement toucher à la palette. ## Un garde-fou, pas un audit Le garde-fou tient dans un petit test qui tourne en quelques secondes à chaque modification. Il ne remplace pas un audit d'accessibilité : il ne couvre même pas toute l'accessibilité. Il fait une chose plus étroite et très utile. Il empêche une nouvelle couleur, un composant refait ou un écran ajouté de repasser sous la barre sans que personne s'en aperçoive. ## La bonne question n'est pas « quel est notre score ? » L'accessibilité n'est pas une faveur rendue à une minorité. Elle rend le produit utilisable par des gens qui vieillissent, qui lisent au soleil ou qui ont simplement une vue moyenne : autrement dit, tout le monde un jour ou l'autre. Depuis juin 2025, l'[European Accessibility Act](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_fr) impose aussi des exigences d'accessibilité à des catégories précises de produits et de services, notamment le commerce électronique, la banque, les transports et les communications électroniques. Mais la conformité n'est pas la meilleure raison de s'en occuper, et ce test de contraste ne suffit évidemment pas à l'établir. Pour un dirigeant, les questions utiles sont plus simples : combien de nos utilisateurs arrivent réellement à lire nos écrans ? Qu'est-ce qui nous empêche de redevenir illisibles le mois prochain ? Si la réponse est « la vigilance de l'équipe », c'est qu'il n'y a pas de réponse. Dans ce cas précis, un premier diagnostic et le garde-fou ont demandé une demi-journée. Si vous avez un produit grand public et que personne n'a jamais vérifié le contraste de l'interface réellement livrée, nous pouvons regarder cela ensemble.