Contraste de couleurs accessible : WCAG sans grisaille.
Comment concevoir un design conforme aux WCAG 2.2 en matière de contraste sans uniformiser votre identité visuelle ? Ratios, APCA, exemples concrets de systèmes de conception et méthodologie de test par tokenisation.
Accessibilité et identité visuelle ne sont pas incompatibles. C'est le mythe que se racontent la plupart des équipes marketing lorsqu'elles évitent d'aborder la question du contraste, et c'est aussi pourquoi tant de refontes « accessibles » finissent par ressembler à de la signalétique d'aéroport.
Le contraste des couleurs pour l'accessibilité est un problème de mesure. Les systèmes de conception modernes l'ont déjà résolu au niveau jeton, ce qui signifie que vous n'avez pas à choisir entre cliquer sur WCAG et préserver l'attrait de la marque. Il suffit de connaître les règles, de savoir où elles sont erronées et où le travail se fait réellement.
Pourquoi le contraste est la règle incontournable
Environ 300 millions de personnes perçoivent les couleurs différemment de ce que suppose votre palette de base, et elles sont encore plus nombreuses à utiliser des interfaces dans des conditions de faible luminosité, sur des écrans de mauvaise qualité ou en raison d'une déficience visuelle partielle qui n'a jamais été signalée.
Un faible contraste est le problème d'accessibilité le plus fréquent sur le web. C'est aussi le plus facile à corriger. Zones d'ombre, déficiences chromatiques, reflets, vieillissement de la vue, écrans bas de gamme, lumière directe du soleil sur un écran de téléphone… Tout cela converge vers la même solution : un contraste suffisant entre le texte et l’arrière-plan pour que le message reste lisible même dans les conditions les plus difficiles, et pas seulement sur l’écran Retina du concepteur.
Le coût d’une erreur à ce niveau ne se limite pas à l’exclusion. Il s’agit d’un risque de non-conformité. La loi européenne sur l’accessibilité (UE), la section 508 aux États-Unis, la loi sur l’accessibilité pour les personnes handicapées de l’Ontario (AODA) et une liste croissante de lois nationales utilisent toutes les WCAG comme référence juridique. Le contraste est l’un des premiers éléments vérifiés lors d’un audit, car c’est souvent l’un des premiers à être défectueux.
Règles de contraste WCAG 2.2 en langage clair
Les WCAG fournissent trois valeurs : 4,5:1, 3:1 et 3:1, chacune s’appliquant à un type spécifique d’élément d’interface utilisateur.
| Élément | Niveau AA minimum | Niveau AAA minimum | Notes |
|---------|-----------|-------------|-------|
| Texte | 4,5:1 | 7:1 | Tout texte inférieur à 18 pt (normal) ou 14 pt (gras) |
| Texte de grande taille | 3:1 | 4,5:1 | 18 pt et plus (normal) ou 14 pt et plus (gras) |
| Composants d'interface utilisateur et graphismes | 3:1 | Non spécifié | Boutons, icônes, bordures de formulaire, anneaux de focus |
| Texte dans les logos ou images décoratives | Exempté | Exempté | Les éléments de marque et les textes accessoires ne sont pas pris en compte |
Le niveau AA est celui que visent la plupart des produits commerciaux et qu'exigent la plupart des lois sur l'accessibilité. Le niveau AAA est un objectif plus strict, principalement utilisé par les administrations, les établissements de santé et les organismes d'éducation. À moins qu'un document de conformité n'indique le niveau AAA, le niveau AA est le minimum requis.
Le piège dans lequel tombent la plupart des concepteurs est d'oublier la règle du 3:1 pour les éléments non textuels. Une bordure de champ de formulaire au ratio 2:1 par rapport à l'arrière-plan de la page est considérée comme non conforme, même si le texte qu'elle contient l'est.
Un anneau de focus au contraste insuffisant est considéré comme non conforme. Une icône dont la signification dépend de la couleur, au ratio 2,5:1, est considérée comme non conforme. Le contraste des éléments non textuels est obligatoire.
Pourquoi les calculs WCAG sont souvent erronés
Les WCAG rapports de contraste sont une formule vieille de 30 ans qui ignore la perception visuelle. C'est pourquoi elles valident parfois des couleurs affreuses et en refusent d'autres qui semblent correctes.
La formule WCAG 2 se base uniquement sur la luminance. Elle considère le contraste du texte sur fond comme une relation linéaire entre la luminosité relative de deux couleurs. Or, ce n'est pas ainsi que le système visuel humain perçoit le contraste.
Le contraste perçu réel dépend de la graisse et de la taille de la police, de la température de couleur et de ce que l'œil regardait une seconde auparavant. Les WCAG 2 ne prennent absolument aucun de ces éléments en compte. Le résultat est un ratio qui traite le texte gris clair sur fond blanc de la même manière que le texte noir sur fond gris clair, alors que l'un est lisible et l'autre pénible à lire.
Comment l'APCA résout le problème de perception
L'APCA (Accessible Perceptual Contrast Algorithm) mesure le contraste de la même manière que la vision humaine, raison pour laquelle la version préliminaire des WCAG 3 le propose comme solution de remplacement.
Les scores APCA varient de 0 (aucun contraste) à environ 108 (contraste extrême). Contrairement aux WCAG 2, il prend en compte l'épaisseur du texte, sa taille et sa polarité (le texte clair sur fond foncé et le texte foncé sur fond clair sont perçus différemment par l'œil).
Seuils APCA approximatifs pour les textes courants :
-
Texte courant (16 px standard) : 75+ (requis), 90+ (idéal)
-
Petits textes (14 px standard) : 90+ (requis)
-
Grands textes (24 px et plus) : 60+ (requis)
-
Interface utilisateur non textuelle : 45+ minimum
L’APCA n’est pas encore obligatoire. Cependant, les produits commercialisés l’utilisent déjà comme norme interne, car elle reflète mieux la qualité de lecture réelle. La meilleure stratégie consiste à respecter les normes WCAG 2 AA pour la conformité et les normes APCA pour une qualité optimale. Atteindre ces deux objectifs simultanément est tout à fait possible si vos jetons de couleur sont conçus pour cela.
Comparaison de la tokenisation dans quatre systèmes de conception
Ces systèmes intègrent déjà l’accessibilité dans la couche de tokenisation ; les concepteurs choisissent donc un rôle au lieu de calculer un ratio.
Radix Colors
À voir en direct sur radix-ui.com
Radix Colors propose des échelles à 12 niveaux, chaque niveau étant pré-associé à un rôle. Les niveaux 11 et 12 correspondent aux textes à contraste élevé et sont garantis conformes aux normes WCAG AA par rapport aux niveaux inférieurs. Les jetons de rôle (text, textContrast, solid, solidHover) permettent aux concepteurs de choisir un rôle plutôt que de calculer un ratio.
À retenir : le modèle de contraste numéroté par rôle. Tout concepteur utilisant le niveau 11 sait qu’il est conforme aux niveaux plus clairs de la même échelle. Le ratio est intégré au numéro du niveau.
Material Design 3
À voir en direct sur m3.material.io
Material 3 associe chaque rôle de couleur à un homologue on- (on-primary, on-surface, on-error) garantissant un rapport de 4,5:1 avec son parent. Ces paires constituent la couche d'accessibilité, intégrée directement au système.
À retenir : le modèle on-. Lorsqu'un concepteur utilise on-primary pour du texte, l'accessibilité est automatique. Aucun risque d'erreur.
Deux autres : Rapports et systèmes perceptifs
Radix et Material résolvent le contraste par l'association des rôles. Les deux suivants le résolvent grâce à des rapports documentés et des échelles perceptuellement uniformes. Les deux approches sont efficaces et méritent d'être étudiées.
GitHub Primer
Découvrez-le en direct sur primer.style
Primer sépare les jetons de premier plan, d'arrière-plan et de bordure en niveaux explicites avec des rapports de contraste documentés. Leurs fg.default et bg.default sont publiés avec des rapports exacts, et chaque jeton sémantique basé sur un rôle bénéficie du même traitement.
À retenir : publier les rapports à côté des jetons. Lorsque le contraste de chaque jeton par rapport à chaque arrière-plan pertinent est documenté, les concepteurs et les développeurs peuvent se passer complètement de l'outil de vérification.
Adobe Spectrum
Visionnez-le en direct sur spectrum.adobe.com
Spectrum utilise des échelles de couleurs perceptuellement uniformes afin que deux jetons ayant le même numéro d'étape aient le même poids visuel quelle que soit la teinte. Cela signifie que l'échange de teintes au sein d'un thème préserve les relations de contraste. Fini les « valides en bleu, non validés en orange ».
À retenir : l’uniformité perceptive. Les échelles basées sur des modèles perceptifs (comme HSLuv, OKLCH ou l’approche personnalisée de Spectrum) rendent l’accessibilité applicable à toutes les thématiques de marque.
Comment rester accessible sans perdre son identité
L’accessibilité ne se résume pas à du texte noir sur fond blanc et à une marque discrète. Les équipes qui conçoivent les produits les plus inclusifs sont celles qui l’ont compris.
Tout dépend de la place qu’occupe l’accessibilité dans la chaîne de conception. Si elle est intégrée dès la conception, la marque reste dynamique et les designers obtiennent des résultats accessibles. Si elle est reléguée à la validation finale, chaque couleur de la marque représente un risque d’échec lors d’un audit.
Trois techniques permettent de concilier personnalité et accessibilité :
-
Séparez la couche d'accentuation en une couleur de marque et une couleur d'action accessible. Linear utilise un violet spécifique pour les éléments de marque et un violet légèrement différent pour les éléments interactifs. Les deux sont immédiatement reconnaissables. Une seule couleur est garantie sur toutes les surfaces.
-
Utilisez des échelles perceptuellement uniformes. OKLCH et HSLuv associent les valeurs de couleur à la luminosité perçue, ce qui permet de faire défiler les teintes sans rupture de contraste. Radix, Spectrum et Material 3 proposent des variantes de ce principe.
-
Intégrez le mode sombre comme un ensemble de jetons parallèle, et non comme une fonctionnalité ajoutée après coup. Un jeton qui ne fonctionne pas en mode sombre n'est pas compatible avec ce mode. Si votre système interprète
text-defaultcomme une couleur en clair et une autre en sombre, les deux valeurs doivent être validées sur la surface correspondante.
Le pire scénario est un compromis non sollicité : une marque atténuée qui reste inaccessible. Cela se produit lorsque les équipes réagissent aux retours sur le contraste en désaturant toutes les couleurs au lieu de corriger les associations. La désaturation n'est pas synonyme d'accessibilité. Ce sont les associations qui le sont.
Le flux de travail des tests d'accessibilité
Tester le contraste est peu coûteux, automatisé et totalement inutile si vous attendez la revue de conception.
Le flux de travail efficace effectue des vérifications de contraste à quatre étapes, et non à une seule.
-
Lors de la définition du jeton. Lorsqu'un jeton est créé, les surfaces autorisées sont également définies.
text-defaultest autorisé uniquement surbg-default,bg-subtleetbg-raised. Le contraste du jeton avec chaque élément est vérifié une seule fois, puis verrouillé. -
Lors de la validation du composant. Storybook, associé à une intégration axe-core ou pa11y, effectue des contrôles d'accessibilité sur chaque variante de composant dans le cadre de l'intégration continue. Toute nouvelle variante présentant un échec est bloquée avant la fusion.
-
Lors du transfert du fichier de conception. Les plugins Figma, tels que Stark ou le vérificateur WCAG intégré, signalent les problèmes directement dans l'outil de conception. Il est important de les détecter au moment de la conception, et non lors de la révision.
-
Au niveau de la page. Lighthouse, axe DevTools ou pa11y s'exécutent sur les pages en production ou en test. Cela permet de détecter les problèmes concrets (contenu tiers intégré, contenu généré par les utilisateurs, thèmes dynamiques) que les tests de composants ne repèrent pas.
L'objectif n'est pas d'exécuter davantage d'outils, mais d'avancer le contrôle. Un échec de contraste détecté par un pipeline d'intégration continue se corrige en cinq minutes. Le même échec, détecté lors d'un audit avant lancement, coûte une semaine à l'équipe.
Pour la raison structurelle qui explique l'efficacité de cette approche par couches, le guide des systèmes de conception détaille pourquoi la pensée par couches de jetons est préférable. Le La règle des 60-30-10 n'est pas respectée. explique quant à lui pourquoi la couleur basée sur les rôles (dont dépend l'accessibilité) a remplacé la pensée basée sur les proportions.
FAQ
Le niveau AA des WCAG est-il suffisant ou faut-il le niveau AAA ?
Le niveau AA est la norme pour la plupart des produits commerciaux et la plupart des lois sur l'accessibilité. Le niveau AAA n'est légalement requis que dans certains contextes (gouvernement, santé, éducation) et son obtention est coûteuse sans uniformiser la palette de couleurs. Visez le niveau AA comme minimum et le niveau idéal APCA comme maximum.
Chaque élément non textuel doit-il respecter les ratios de contraste ?
Les composants d'interface utilisateur non textuels qui transmettent une signification doivent respecter un ratio de contraste minimum de 3:1 selon les WCAG 2.2. Cela inclut les boutons, les bordures de formulaire, les anneaux de focus, les icônes significatives et les éléments graphiques. Les éléments purement décoratifs (motifs d'arrière-plan, dégradés ambiants) sont exemptés. Les textes accessoires (comme une légende superposée à une photo) sont également exemptés.
Quelle est la différence entre WCAG et APCA ?
WCAG 2 est la norme légale actuelle, basée sur une formule de luminance vieille de 30 ans. APCA est la norme de remplacement proposée dans le projet de WCAG 3, basée sur le fonctionnement réel de la perception humaine. Les scores APCA sont mieux corrélés à la lisibilité réelle, mais ne sont pas encore obligatoires. Les produits commercialisés utilisent les deux : WCAG 2 pour la conformité et APCA pour la qualité.
Intégrer l’accessibilité dans les jetons
Un contraste de couleurs accessible n’est pas un choix de style. C’est une propriété du système.
Les équipes qui commercialisent les produits les plus inclusifs et valorisant l’image de marque sont celles qui ont cessé de considérer l’accessibilité comme une simple formalité et qui l’ont intégrée dès le départ comme une propriété intrinsèque du palette de couleurs.
Les jetons encodent les ratios. Les échelles encodent les paires. Les tests sont effectués à quatre étapes du flux de travail. Personne ne vérifie le contraste d'un écran avant un lancement.
Si votre processus actuel repose sur l'évaluation visuelle d'une palette de couleurs par un designer pour déterminer si elle « paraît lisible », vous échouerez à l'audit. Si votre processus utilise un outil de vérification et des contrôles manuels, vous échouerez à grande échelle. En revanche, si votre processus utilise des jetons d'accessibilité basés sur les rôles, vous réussirez votre lancement.
Créez les jetons. Publiez les ratios. Automatisez les vérifications. La marque reste forte, l'interface reste lisible et l'audit devient une simple formalité plutôt qu'une refonte.
Need a color system that hits WCAG without flattening the brand? Brainy builds token-layer accessibility into every palette.
Get Started
