Comment choisir des combinaisons de couleurs accessibles
Les choix de couleurs ressemblent à une décision esthétique et agissent comme une décision juridique. Environ 4 000 procès d'accessibilité web par an touchent les défendeurs américains depuis 2021, et un contraste de couleur insuffisant est l'un des trois problèmes les plus cités dans les dossiers basés sur WCAG (aux côtés du texte alternatif manquant et des champs de formulaire non étiquetés). La bonne nouvelle : le contraste est le plus simple des trois à corriger : un ratio est un nombre, le seuil WCAG est un nombre, et vous pouvez calculer l'un contre l'autre en quelques secondes. La mauvaise nouvelle : « accessible » va au-delà du ratio principal : daltonisme, indicateurs de focus, mode sombre et tokenisation comptent tous.
Une brève histoire de l'accessibilité couleur numérique
Le contraste de couleur comme norme écrite date du premier travail de la Web Accessibility Initiative du W3C en 1997. Les Web Content Accessibility Guidelines 1.0 originales (mai 1999) recommandaient un contraste suffisant en termes qualitatifs sans nombre concret. WCAG 2.0 (décembre 2008) a introduit la formule de luminance relative désormais familière et le ratio 4,5:1 au niveau AA, tiré de recherches de Lighthouse International sur ce que des utilisateurs âgés portant des lunettes pouvaient confortablement lire à l'écran.
Le poids juridique est venu après. La Section 508 du US Rehabilitation Act a référencé WCAG 2.0 en 2018 ; l'ADA, après l'arrêt Robles v. Domino's du Ninth Circuit le 15 janvier 2019 (Cour suprême ayant refusé l'appel en octobre 2019), est désormais lue par les tribunaux américains comme couvrant l'accessibilité numérique sous le Titre III. L'European Accessibility Act est entré en vigueur le 28 juin 2025, exigeant WCAG 2.1 AA sur les services numériques grand public pour le secteur public et beaucoup de privés. En pratique, 4,5:1 texte normal + 3:1 grand texte + 3:1 composants UI est le plancher de facto pour tout site public construit aujourd'hui.
La science a continué d'évoluer. WCAG 2.1 (2018) a ajouté la règle de contraste non-textuel 3:1. L'algorithme APCA, développé par Andrew Somers pour WCAG 3, modélise la perception de luminosité plus précisément et donne des nombres différents pour les paires très sombres et très claires ; c'est un Editor's Draft en 2026, pas encore un standard. Les OKLAB et OKLCH de Bjorn Ottosson (2020) ont donné aux designers un espace colorimétrique perceptuellement uniforme qui rend la génération d'échelles couleur accessibles bien plus facile qu'en HSL ou RGB.
Ce que « couleur accessible » signifie vraiment
Quatre choses comptent, pas juste le ratio :
- Contraste premier plan vs arrière-plan. Le nombre principal. Le corps de texte a besoin de 4,5:1, le grand texte 3:1, les contrôles UI et indicateurs de focus 3:1 contre les couleurs adjacentes.
- Daltonisme. Environ 8 % des hommes et 0,5 % des femmes voient moins de couleurs que ne le suppose le design. Les trois types principaux sont protanopie et deutéranopie (rouge-vert, les plus communs), et tritanopie (bleu-jaune).
- La couleur n'est jamais le seul signal. WCAG 1.4.1 interdit de se fier à la couleur seule pour transmettre du sens. Une bordure d'erreur rouge a besoin d'une icône ou d'un libellé aussi.
- Indicateurs de focus. Les utilisateurs clavier ont besoin de voir où est le focus. La règle WCAG 2.4.7 exige un indicateur de focus visible, et la mise à jour 2.4.11 (WCAG 2.2) exige au moins 2 pixels CSS d'épaisseur et 3:1 de contraste contre la couleur adjacente.
Comment choisir des couleurs accessibles, étape par étape
- Partez de tokens sémantiques, pas de couleurs brutes. Définissez
text-primary,text-secondary,surface-default,surface-elevated,border-default,accent-primary,accent-danger, etc. - Choisissez l'échelle de luminosité. Utilisez les valeurs de luminosité OKLCH pour construire une échelle de 5 à 9 paliers où chaque palier a une différence perceptuelle constante avec le suivant.
- Choisissez les teintes à chaque palier. Prenez la teinte de marque, puis prenez teintes complémentaires ou d'accent qui maintiennent une chroma similaire.
- Calculez les ratios de contraste. Chaque paire de tokens qui se touche a besoin du bon ratio. Corps de texte sur surface par défaut : 4,5:1. Texte désactivé : au moins 3:1 s'il doit rester lisible.
- Lancez un simulateur de daltonisme. Prenez un écran clé et re-rendez-le à travers les simulateurs protanopie, deutéranopie et tritanopie.
- Testez avec une vraie techno d'assistance. Mac VoiceOver, NVDA, JAWS et TalkBack devraient tous pouvoir naviguer sans dépendre des indices de couleur.
- Ajoutez le signal non-couleur partout où la couleur porte du sens. Icônes pour erreur/succès/avertissement, soulignements pour les liens dans le corps, motifs pour les séries de graphiques.
- Documentez les tokens. Une bibliothèque Figma, une page Storybook, ou un site de design-system statique.
Référence des ratios de contraste
| Paire | WCAG 2.1 min | Niveau AA | Niveau AAA |
|---|---|---|---|
| Corps de texte (sous 18 pt regular ou 14 pt gras) | 4,5:1 | 4,5:1 | 7:1 |
| Grand texte (18 pt regular ou 14 pt gras) | 3:1 | 3:1 | 4,5:1 |
| Composants UI (bordures formulaire, états toggle, focus) | 3:1 | 3:1 | n/a |
| Objets graphiques (icônes porteuses de sens) | 3:1 | 3:1 | n/a |
| Texte à l'intérieur d'un logo | exempté | exempté | exempté |
| Contrôles désactivés | exempté | exempté | n/a |
| Texte décoratif | exempté | exempté | exempté |
Types de daltonisme et comment vérifier
| Type | Prévalence | Voit moins de | Échec courant |
|---|---|---|---|
| Protanopie | ~1 % des hommes | Rouge | Erreur rouge vs succès vert indistinguables |
| Deutéranopie | ~5 % des hommes | Vert | Idem : confusion rouge-vert |
| Tritanopie | ~0,005 % | Bleu | Bleu vs jaune indistinguables |
| Achromatopsie | ~0,003 % | Toute couleur | Ne voit que la luminance en niveaux de gris |
| Trichromasie anomale | ~5 % | Sensibilité réduite sur un canal | Différences couleur subtiles fusionnent |
Pièges courants
- Designer en HSL ou RGB. Des pas numériques égaux en HSL produisent des pas perçus inégaux. OKLCH corrige ça.
- Se fier à la couleur seule pour l'état. Rouge et vert pour erreur et succès : 8 % des utilisateurs ne les distinguent pas. Ajoutez icône ou libellé.
- Noir pur sur blanc pur.
#000sur#FFFscore 21:1 mais fatigue les yeux pour la lecture longue. Descendez à un quasi-noir et un quasi-blanc. - Tyrannie de la couleur de marque. Traiter le rouge de marque comme sacré et l'utiliser à 2,1:1 « parce que c'est la marque ». Rafraîchissez la palette de marque.
- Indicateur de focus invisible sur fond sombre. Un anneau bleu 2px sur un bouton bleu sombre peut disparaître. Testez l'anneau de focus sur toutes les surfaces.
- Texte placeholder qui échoue au contraste.
placeholder=est rendu à ~40 % d'opacité ; tombe sous 4,5:1 facilement. - Contours de champ trop pâles. Une bordure 1px gris-sur-blanc à 1,2:1 échoue à WCAG 1.4.11. Montez à 3:1 ou plus épais.
- Survols qui ne changent que la couleur. Certains appareils de pointage ne produisent pas de survol. Combinez avec une ombre ou une transformation subtile.
- Mode sombre par simple inversion. Inverser produit des couleurs sombres saturées dures. Le mode sombre a besoin de son propre passage avec accents désaturés.
- Texte auto-généré sur images. Du texte rendu sur une image téléversée ne peut garantir le contraste. Ajoutez un fond translucide ou une ombre.
Algorithmes et standards alternatifs
| Algorithme | Année | Statut | Force |
|---|---|---|---|
| Ratio de contraste WCAG 2.x | 2008 | Exigé par la plupart des réglementations | Maths simples, largement outillé |
| APCA | 2020 | Editor's Draft WCAG 3 | Meilleur sur la luminosité perceptuelle |
| ISO 9241-302 | 2008 | Norme ergonomique poste de travail | Très stricte, orientée matériel |
| Avertissements de contraste Lighthouse | 2018 | Chrome DevTools | Gratuit, dans le navigateur |
| axe-core | 2015 | Bibliothèque open source | Standard de l'industrie pour test auto |
Pour le travail réglementé aujourd'hui, WCAG 2.1 AA est le plancher. APCA vaut la peine d'être suivi à mesure que WCAG 3 mûrit ; beaucoup d'équipes design-system reportent déjà les deux nombres.
Outils pour choisir des couleurs accessibles
| Outil | Objet | Force |
|---|---|---|
| Vérificateur de contraste (navigateur) | Noter une paire premier plan/arrière-plan | Instantané, pas de téléversement |
| Générateur de palette accessible | Construire une échelle complète à chroma constant | OKLCH pour uniformité perceptuelle |
| Simulateur de daltonisme | Re-rendre un écran tel qu'un daltonien le voit | Détecte les soucis rouge-vert avant lancement |
| Chrome DevTools Lens | Inspecter contraste et daltonisme sur place | Intégré au navigateur |
| WebAIM Contrast Checker | Référence WCAG 2 classique | De confiance, largement cité |
| Stark (plugin Figma) | Auditer les designs Figma | Détecte les soucis dès le design |
| axe DevTools (navigateur) | Scan WCAG automatisé | Standard de l'industrie |
| Échelles Tailwind, Radix, Open Props | Palettes OKLCH pré-testées | Accessibilité curatée par équipes design |
Confidentialité et les outils
Le vérificateur de contraste, le générateur de palette accessible et le simulateur de daltonisme tournent entièrement dans votre navigateur. Les couleurs que vous choisissez ou collez sont traitées par JavaScript sur votre appareil, les résultats sont rendus sur la page, et rien n'est envoyé à un serveur. Pas de télémétrie, pas d'analytics sur l'entrée, pas de scripts tiers. Pour les couleurs de marque pas encore publiques, les palettes produit internes, ou les designs sous embargo, ce flux strictement local est la différence entre confier vos assets de marque non sortis à l'outil d'un inconnu et ne pas le faire. Les outils peuvent tourner hors-ligne une fois la page chargée, ce que vous pouvez vérifier en coupant le réseau et en recontrôlant une paire.
Questions fréquentes
What contrast ratio does WCAG require?
WCAG 2.1 Level AA requires at least 4.5:1 for normal body text and 3:1 for large text (18 pt regular or 14 pt bold). Level AAA raises that to 7:1 for normal text and 4.5:1 for large text. Non-text UI components and graphical objects need 3:1 against adjacent colors.
Are WCAG contrast ratios scientifically accurate?
They are based on the WCAG 2.0 algorithm from 2008, which compares the relative luminance of two colors using the sRGB color space. The formula is imperfect for very dark and very light combinations and for some color hues; the APCA (Accessible Perceptual Contrast Algorithm) being developed for WCAG 3 produces more perceptually accurate results. For 2026 work, WCAG 2.x is still the standard most regulations cite.
How do I check whether my colors work for color-blind users?
Run them through a color-blindness simulator that converts your palette to what someone with protanopia, deuteranopia, or tritanopia sees. About 8% of men and 0.5% of women have some form of color vision deficiency, so this matters.
Should I use the same color palette for light and dark mode?
Usually not. Dark mode needs slightly desaturated colors at the same hue, otherwise vivid colors that look fine on white become eye-strain on black. Define semantic tokens (text-primary, surface-secondary) and map them to different physical colors per mode.
What does OKLCH have to do with accessibility?
OKLCH is a perceptually uniform color space (Bjorn Ottosson, 2020) where equal numerical changes produce equal perceptual changes. That makes it much easier to generate accessible color scales because you can step the lightness in equal increments and the perceived brightness step is consistent, which is hard to do in HSL or RGB. CSS supports OKLCH directly since 2023 in all major browsers.