Ratio de contraste WCAG : AA, AAA et APCA en 2026

Vous mettez en ligne un bouton. Orange de la marque, texte blanc, nickel sur votre écran 4K. Puis l’audit d’accessibilité revient en rouge : le ratio de contraste WCAG est de 1,97:1, très loin du seuil 4.5:1 AA exigé pour le corps de texte. Ce bouton qui vous paraissait correct est illisible pour près de 220 millions de personnes malvoyantes dans le monde. Ce guide passe en revue chaque chiffre qui sert à corriger ce problème : ratios WCAG 2, palier AAA, nouvel algorithme APCA Lc, huit catégories de déficience de la vision des couleurs, et une implémentation JavaScript fonctionnelle à intégrer directement dans votre build.

Référence rapide : seuils WCAG et APCA en un coup d’œil

Standard	Texte normal	Texte large	UI / icônes	Notes
WCAG AA	≥ 4.5:1	≥ 3:1	≥ 3:1	Plancher légal
WCAG AAA	≥ 7:1	≥ 4.5:1	≥ 3:1	Cible renforcée
APCA body	Lc 75+	Lc 60+	Lc 45+ (icônes)	Brouillon, perceptuel

« Texte large » signifie ≥ 18pt regular ou ≥ 14pt bold (soit environ 24px et 18,66px en CSS). « UI » couvre les bordures de formulaires, les anneaux de focus et tout objet graphique qu’un utilisateur doit percevoir pour piloter la page. Les logos et les graphiques purement décoratifs sont exemptés des exigences de contraste.

Qu’est-ce que le contraste de couleur WCAG ?

Le ratio de contraste WCAG est une mesure numérique allant de 1:1 (aucun contraste) à 21:1 (maximum) qui compare la luminance relative du texte à celle de son arrière-plan. Les Web Content Accessibility Guidelines exigent ≥ 4.5:1 (AA) pour le corps de texte ou ≥ 7:1 (AAA) pour une conformité renforcée.

Ce ratio pilote la plupart des audits d’accessibilité dans le monde. Le W3C l’a publié dans WCAG 2.0 en 2008, l’a affiné dans 2.1 (2018) puis 2.2 (2023), et tous les grands régulateurs y renvoient désormais. L’ADA aux États-Unis, l’European Accessibility Act (entré en application en juin 2025), la Section 508 pour les agences fédérales américaines et l’AODA canadienne s’appuient tous sur WCAG 2.x AA comme plancher de facto.

Pourquoi cela compte-t-il au-delà du volet juridique ? Près de 220 millions de personnes dans le monde sont malvoyantes sans être aveugles. Elles lisent les écrans, mais uniquement quand le contraste texte/fond est suffisant. Environ 8 % des hommes et 0,5 % des femmes présentent une déficience de la vision des couleurs. Les lecteurs plus âgés subissent un jaunissement du cristallin et une réduction de l’ouverture pupillaire, ce qui abaisse fonctionnellement le contraste perçu de 20 à 30 % après 60 ans. L’usage du smartphone en extérieur fait perdre encore 20 à 40 % à cause des reflets. Une page qui atteint 4.5:1 sur votre bureau est le strict minimum auquel tous ces utilisateurs peuvent encore la lire.

Les personnes les plus concernées sont les ingénieurs front-end qui livrent des interfaces en production, les designers qui choisissent les palettes de marque, les spécialistes de l’accessibilité qui mènent les audits, et les équipes conformité qui répondent du risque juridique. Les calculs sont brefs. Les arbitrages qu’ils imposent le sont moins.

Ratio de contraste WCAG 2.x : la formule et les seuils

Le W3C définit le contraste en trois étapes brèves. Pour calculer le ratio de contraste WCAG : (1) convertir chaque couleur sRGB gamma-encodé en valeurs de lumière linéaire, (2) calculer la luminance relative à l’aide de coefficients fixes correspondant à la sensibilité de l’œil humain au rouge, au vert et au bleu, et (3) diviser les deux luminances avec un petit décalage constant pour gérer les valeurs proches du noir.

La formule de luminance relative issue de WCAG 2.1 §1.4.3 est la suivante :

L = 0.2126 × R_lin + 0.7152 × G_lin + 0.0722 × B_lin

R_lin, G_lin, B_lin correspondent aux valeurs de canal en lumière linéaire après avoir annulé la courbe gamma sRGB. Le poids 0.7152 sur le vert reflète la forte sensibilité de l’œil humain au vert : le vert est environ 7 fois plus « bruyant » visuellement que le bleu par unité d’énergie lumineuse.

La formule du ratio est :

ratio = (L_lighter + 0.05) / (L_darker + 0.05)

Le +0.05 évite la division par zéro pour le noir pur (L = 0) et donne un maximum de (1 + 0.05) / (0 + 0.05) = 21:1 pour du blanc pur sur du noir pur. Le minimum est 1:1, c’est-à-dire deux couleurs identiques.

Voici l’implémentation complète en une trentaine de lignes de JavaScript vanilla. Aucune dépendance, fonctionne partout :

// sRGB hex → canal en lumière linéaire
function srgbToLinear(channel8bit) {
  const v = channel8bit / 255;
  return v <= 0.04045 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4);
}

// "#RRGGBB" → luminance relative [0, 1]
function relativeLuminance(hex) {
  const h = hex.replace("#", "");
  const r = parseInt(h.slice(0, 2), 16);
  const g = parseInt(h.slice(2, 4), 16);
  const b = parseInt(h.slice(4, 6), 16);
  return (
    0.2126 * srgbToLinear(r) +
    0.7152 * srgbToLinear(g) +
    0.0722 * srgbToLinear(b)
  );
}

// Ratio de contraste WCAG 2.x entre deux couleurs hex
function contrastRatio(hexA, hexB) {
  const lA = relativeLuminance(hexA);
  const lB = relativeLuminance(hexB);
  const [lighter, darker] = lA > lB ? [lA, lB] : [lB, lA];
  return (lighter + 0.05) / (darker + 0.05);
}

// Exemple : corps de texte ardoise foncé sur blanc
console.log(contrastRatio("#475569", "#ffffff").toFixed(2));
// → "7.58" : confortablement au-dessus de AA 4.5:1 et juste au-dessus de AAA 7:1

Saisissez deux codes hex dans le Convertisseur de couleurs et les mêmes chiffres reviennent, affichés à côté d’une valeur APCA Lc, d’une classification de gamut et d’un aperçu CVD sur huit canaux. Les seuils, eux, sont concrets :

Élément	AA min	AAA min	Notes
Corps de texte normal	4.5:1	7:1	Sous 18pt regular / sous 14pt bold
Texte large	3:1	4.5:1	≥ 18pt regular OU ≥ 14pt bold
Composants UI / icônes	3:1	—	WCAG 2.1 §1.4.11 ajouté en 2018
Logos & décoratif	exempt	exempt	Aucune exigence de contraste

Les conversions d’unités CSS piègent souvent les équipes. 18pt = 24px à la taille par défaut du navigateur, 14pt = 18,66px. Une police corporelle à 16px (le défaut moderne) se situe sous le seuil « texte large », elle relève donc de la règle AA plus stricte à 4.5:1. Un titre 20px en font-weight: 700 se qualifie comme texte large et bénéficie du seuil plus souple à 3:1.

Une subtilité qui prend les équipes au dépourvu : l’exemption « texte large » de WCAG concerne la lisibilité utilisateur à grande échelle, pas la sémantique des titres. Un <h2> à 14px n’est pas du texte large ; il doit toujours atteindre 4.5:1. Un paragraphe marketing à 24px est du texte large et bénéficie du plancher 3:1. La règle s’appuie sur la taille en pixels rendue et le poids, jamais sur le nom de balise. Les auditeurs signaleront les incohérences ; votre CSS est la source de vérité, pas votre sémantique HTML.

La constante +0.05 dans la formule du ratio a une origine précise : elle représente le terme de flare, la lumière ambiante réfléchie par la surface de l’écran qui relève la luminance apparente du noir pur jusqu’à un plancher minimal. Sans elle, un pixel OLED affichant un vrai noir contre du blanc pur donnerait une division par zéro. Avec elle, le ratio maximal atteignable est 21:1, chiffre que vous retrouverez dans tous les outils d’accessibilité. Aucun écran physique ne peut délivrer plus de 21:1 une fois le flare pris en compte, ce qui explique pourquoi l’échelle WCAG se termine à cette valeur.

AA contre AAA : quel palier viser ?

AA est le plancher légal ; AAA est le palier aspirationnel. La plupart des sites commerciaux visent AA parce que AAA pousse les couleurs de marque vers le niveau de gris pour passer, ce que la majorité des équipes marketing refuse. La décision n’est pas un « plus c’est mieux ». C’est un arbitrage entre portée utilisateur et expression de marque.

Contexte	Palier recommandé	Pourquoi
Site commercial généraliste	AA	Base de conformité ADA / EAA ; les tribunaux citent WCAG 2 AA
Services publics / gouvernement	AAA	Section 508 et statuts UE équivalents recommandent AAA
Santé / éducation	AAA	Base utilisateurs tirée vers des besoins d’accessibilité plus élevés
Tableau de bord interne	AA	Audience connue, arbitrage ROI acceptable
Landing page marketing	AA + dérogation marque	Couleurs de marque autorisées sur hero/CTA, body reste AA

Le coût caché de AAA apparaît la première fois que vous essayez de faire passer un orange de marque saturé au-delà de 7:1 contre du blanc. Impossible. Soit vous foncez l’orange jusqu’à ce qu’il ne ressemble plus à votre marque, soit vous acceptez AA et utilisez l’orange sur des fonds sombres où il atteint AAA sans effort. Beaucoup d’entreprises (y compris certaines des plus attentives à l’accessibilité) visent explicitement AA sur le contenu corporel et ne poussent vers AAA que pour les textes critiques comme les messages d’erreur ou les mentions légales.

Les régulateurs n’ont pas attendu que AAA se diffuse. La réglementation 2024 sur l’accessibilité web de l’ADA cite WCAG 2.1 AA. L’European Accessibility Act, opposable depuis juin 2025, exige WCAG 2.1 AA sur l’ensemble des services numériques couverts. La Section 508, côté gouvernement fédéral américain, prend WCAG 2.0 AA comme base (avec AAA recommandé là où c’est faisable). L’AODA canadienne, statut d’accessibilité de l’Ontario, pointe vers WCAG 2.0 AA. La constante est nette : AA est la barre, AAA est l’objectif.

APCA : le nouvel algorithme perceptuel

APCA (Advanced Perceptual Contrast Algorithm, conçu par Andrew Somers sous le label Myndex) est un algorithme candidat pour WCAG 3. Il remplace le ratio symétrique de WCAG 2 par un score Lc signé en polarité allant de -108 à +108, où le signe indique le sens du contraste (texte sombre sur clair vs texte clair sur sombre) et la magnitude reflète le contraste perçu sur un écran émissif réel.

APCA compte parce que la formule symétrique de WCAG 2 passe à côté de deux effets bien réels :

L’asymétrie de polarité. Du texte clair sur fond sombre ne se lit pas comme du texte sombre sur fond clair, même au même ratio WCAG. WCAG 2 renvoie le même chiffre dans les deux sens ; APCA non.
La modélisation de l’écran. La formule de WCAG 2 a été dérivée de modèles de luminance imprimée sur papier. APCA a été calibré contre des écrans sRGB en éclairage de bureau typique, ce qui se rapproche bien davantage de ce que voient réellement vos utilisateurs.

En contrepartie, APCA est plus complexe (il implique des exposants conscients de la polarité et des ajustements liés à la graisse de police) et n’est pas encore un standard réglementaire. L’analyse d’avril 2026 d’Adrian Roselli reste le résumé le plus clair sur la position d’APCA : il est techniquement prometteur, mais WCAG 3 lui-même est toujours en développement précoce sur la voie Silver, et APCA n’a pas encore été ratifié comme algorithme officiel.

Les seuils Bronze d’APCA (le plancher pratique que visent la plupart des équipes) ressemblent à ceci :

Cas d’usage	Lc recommandé	Lc minimum
Corps de texte (16px, poids 400)	90+	75
Texte large (24px, poids 400)	75+	60
Éléments UI & icônes non textuelles	60+	45
Texte ponctuel / placeholders	30+	30

L’intérêt d’APCA, et la raison pour laquelle le Convertisseur de couleurs affiche les deux métriques côte à côte, tient aux cas où il diverge de WCAG 2 :

#FFA500 (orange) sur #FFFFFF : WCAG 2 renvoie 1.97:1, échec net en AA. APCA est d’accord, avec un score autour de Lc 38, également un échec. Jusque-là, les deux algorithmes disent non, mais la plupart des designers que j’ai vus continuent de livrer cette combinaison parce que « ça rend bien ».
#767676 (gris moyen) sur #FFFFFF : WCAG 2 renvoie 4.54:1, tout juste au-dessus de AA 4.5:1, techniquement un succès. APCA évalue cette paire à environ Lc 60, soit en dessous du seuil Bronze APCA à 75 pour le corps de texte. WCAG passe ; APCA échoue. Le vécu réel de l’utilisateur se rapproche du verdict d’APCA : ce gris sur blanc est plus difficile à lire à taille corporelle que le ratio ne le laisse croire.
#3b82f6 (Tailwind blue-500) sur #000000 : WCAG 2 renvoie 5.71:1, un succès AA confortable. APCA donne autour de Lc 65, sous le minimum Lc 75 pour le corps de texte. Du texte bleu clair sur fond sombre, motif chéri du dark mode, est le cas canonique « WCAG passe, APCA signale ».

Vous n’êtes pas obligé de choisir un camp. La position pragmatique qu’ont retenue la plupart des équipes en production : conserver WCAG 2 AA comme base réglementaire parce que c’est ce que les audits de conformité vérifient, et faire tourner APCA en parallèle comme test de bon sens « est-ce vraiment lisible ? », notamment pour les designs en mode sombre et les couleurs de marque saturées. Le Convertisseur de couleurs affiche les deux chiffres sur la même ligne pour vous éviter de jongler entre des vérificateurs.

Daltonisme et au-delà du contraste

Les ratios de contraste ne sont qu’une moitié de l’accessibilité chromatique. Environ 8 % des hommes et 0,5 % des femmes voient les couleurs autrement que le trichromate de manuel, et la variante la plus courante, la deutéranomalie, se situe pile au milieu de la paire rouge/vert que nous utilisons partout pour les états succès/erreur. WCAG 1.4.1 (« Use of Color ») interdit explicitement à la couleur d’être le seul vecteur d’information ; c’est la règle qui existe pour faire respecter ce principe.

La taxonomie complète des différences de vision des couleurs se répartit en trois groupes : la dichromacy (un cône absent), la trichromatie anormale (un cône décalé) et les rares monochromacies.

Type	Nom commun	Canal touché	Prévalence (H / F)
Protanopia	Aveugle au rouge	Cône L absent	1,0 % / 0,01 %
Deuteranopia	Aveugle au vert	Cône M absent	1,1 % / 0,01 %
Tritanopia	Aveugle au bleu	Cône S absent	0,003 % / 0,003 %
Protanomaly	Rouge faible	Cône L décalé	1,3 % / 0,02 %
Deuteranomaly	Vert faible	Cône M décalé	5,0 % / 0,4 %
Tritanomaly	Bleu faible	Cône S décalé	0,01 % / 0,01 %
Achromatopsia	Aucune couleur	Tous les cônes absents	0,003 % (très rare)
Cone monochromacy	Gris partiel	Un seul cône	0,001 %

La deutéranomalie à elle seule représente 5 % des hommes, soit un sur vingt. C’est la population qui perçoit un indicateur d’erreur rouge et un indicateur de succès vert comme à peu près la même teinte olive-brun. Le remède n’est pas de redessiner votre système de couleurs ; c’est d’ajouter un second canal. Une icône d’erreur rouge associée à une forme « × » et au mot « Erreur » survit à toutes les variantes du tableau. Un simple point rouge, non.

Simuler la CVD en code repose sur deux jeux matriciels standards : Brettel–Viénot–Mollon (1997) pour les dichromacies et Machado–Oliveira–Fernandes (2009) pour les trichromaties anormales. L’approche Brettel projette la couleur d’entrée sur un plan engendré par les deux réponses coniques restantes ; Machado paramètre le décalage du cône en fonction de la sévérité. Les deux sont implémentables comme filtres SVG ou matrices CSS. Le Convertisseur de couleurs embarque les huit variantes en aperçus à un clic, ce qui vous permet de balayer une couleur de marque sur tout le spectre sans quitter la page.

Un court filtre SVG, à déposer dans votre page et à référencer par ID, vous donne une simulation de protanopia en navigateur pour des tests ponctuels :

<svg style="display: none">
  <filter id="protanopia">
    <feColorMatrix type="matrix" values="
      0.567 0.433 0.000 0 0
      0.558 0.442 0.000 0 0
      0.000 0.242 0.758 0 0
      0.000 0.000 0.000 1 0"/>
  </filter>
</svg>

<style>
  .preview-protanopia { filter: url(#protanopia); }
</style>

Appliquez .preview-protanopia au conteneur de votre page pour voir ce qu’un protanope voit. Recommencez avec les matrices deuteranopia et tritanopia (leurs coefficients sont documentés dans l’article Brettel et empaquetés dans la plupart des librairies de simulation CVD). Le panneau Rendering des Chrome DevTools embarque les mêmes simulateurs sous « Emulate vision deficiencies » : utile pour des vérifications rapides, moins pour capturer des screenshots en CI.

La règle plus profonde, au-delà de la simulation : ne laissez jamais la couleur être la seule différence entre deux états. Les icônes doivent se distinguer par la forme (× vs ✓), les états par un libellé (« Erreur » vs « Succès »). La couleur est un multiplicateur sur ces autres signaux, pas un substitut.

Il existe une classe d’échecs que les vérificateurs de contraste ne détectent pas, mais que les simulateurs CVD révèlent. Des segments de camembert distingués uniquement par la teinte, des légendes de carte qui codent les pays par couleur, des badges d’état qui s’appuient sur un dégradé vert/jaune/rouge : tous peuvent passer le contraste WCAG 2 contre l’arrière-plan tout en restant illisibles pour un deutéranope qui les regarde les uns par rapport aux autres. La règle, c’est de vérifier la lisibilité entre couleurs adjacentes dans le design, pas seulement contre le canevas environnant. Deux segments slate-500 côte à côte à la même clarté sont indiscernables quelle que soit la rotation de teinte. Ajoutez un pas de luminance entre régions voisines et le graphique survit à toutes les variantes CVD.

L’achromatopsia et la cone monochromacy sont rares mais méritent une conception explicite parce qu’elles annulent toutes les distinctions de teinte. Un utilisateur achromate ne perçoit que la luminance ; votre interface codée en couleur lui apparaît comme une photo en niveaux de gris. Si votre design tient quand vous passez un filter: grayscale(1) sur toute la page (testez-le dans les DevTools), vous avez validé la version la plus stricte de la règle « la couleur n’est pas le seul signal ». C’est le test d’accessibilité le moins coûteux à exécuter, et il fait remonter un nombre surprenant d’échecs dès que vous l’activez.

Auditer les palettes Tailwind et Material

L’essentiel du travail front-end s’appuie sur une palette toute faite : Tailwind v4, Material 3, Radix ou shadcn. La question d’accessibilité devient « à partir de quelle marche de cette rampe le texte devient-il lisible ? », et la réponse tient davantage du règle de pouce que ce que la documentation veut bien admettre.

Pour la rampe slate de Tailwind v4 contre un blanc pur, voici comment les chiffres WCAG et APCA tombent :

Classe Tailwind	Hex approx.	WCAG vs blanc	AA body	AAA body	APCA Lc (approx.)
slate-400	`#94a3b8`	2.56:1	✗	✗	~38 ✗
slate-500	`#64748b`	4.76:1	✓	✗	~60 ✗ body
slate-600	`#475569`	7.58:1	✓	✓	~78 ✓ body
slate-700	`#334155`	10.35:1	✓	✓	~90 ✓ body

Les règles pratiques qui en découlent :

Le corps de texte exige slate-600 ou plus foncé. Slate-500 passe WCAG AA mais échoue au seuil corporel APCA, donc conforme mais inconfortable. Slate-600 est le plancher sûr.
Les libellés UI et le texte secondaire peuvent utiliser slate-500. Les composants UI n’ont besoin que de 3:1 ; les 4.76:1 de slate-500 sont confortables, et le texte porte d’habitude un contexte visuel d’appui.
Les placeholders devraient utiliser slate-400 ou plus pâle. Le texte de placeholder est exempté de WCAG 1.4.3 en tant que décoratif uniquement si vous conservez un libellé visible au-dessus du champ. Les patrons « libellé-en-ligne-comme-placeholder » doivent atteindre le seuil corps de texte.
Noir pur sur slate-100 / slate-200 est de l’encre gaspillée. Vous êtes à 17:1 et plus ; envisagez slate-700 ou slate-800 comme couleur de texte pour un rendu plus doux sans perdre en lisibilité.

Material 3 utilise une structure de palette tonale similaire. Son surface-container-high se situe autour du ton 92 (très clair) ; son on-surface autour du ton 10 (quasi noir). Le contraste entre n’importe quel on-surface et n’importe quel jeton surface-* de la même famille est garanti par la spec Material de franchir AA. Ne mariez pas on-surface-variant (ton 30) avec surface-container (ton 94) sans vérifier ; c’est un raté que j’ai vu partir en production.

Si vous avez une palette existante qui échoue au contraste, OKLCH offre la voie de réparation la plus propre. Plutôt que de tâtonner sur les codes hex à l’aveugle, convertissez votre couleur en OKLCH, fixez C (chroma) et H (hue), et réduisez L (lightness) jusqu’à ce que le contraste passe. Comme le canal L d’OKLCH est réellement perceptuel, la reconnaissance de marque reste intacte pendant que le contraste se resserre. L’outil HEX vers OKLCH fait cette conversion en une étape ; l’article jumeau OKLCH expliqué couvre les calculs en profondeur.

Le mode sombre mérite son propre paragraphe. Le ratio symétrique de WCAG 2 valide par définition les mêmes combinaisons en mode clair et sombre. APCA, qui est conscient de la polarité, signale fréquemment le corps de texte en mode sombre comme plus difficile à lire que la même paire hex en mode clair. Du clair sur sombre perd toujours du contraste perçu par rapport à du sombre sur clair au même ratio numérique : c’est un effet connu de l’adaptation de l’œil. Repassez APCA sur chaque paire de mode sombre avant la mise en ligne.

Vérificateurs de contraste et workflows CI

Designers et développeurs ont chacun leur vérificateur préféré ; ce qui compte, c’est quelle combinaison d’outils vous intégrez dans un workflow réel. Voici l’état du terrain en 2026 :

Outil	WCAG 2	APCA	Sim CVD	Audit palette
WebAIM Contrast Checker	✓	✗	✗	✗
Adobe Color	✓	✗	✓	✓
Stark (plugin Figma)	✓	✓	✓	✓
Polypane (navigateur)	✓	✓	✓	✓
Color picker des Chrome DevTools	✓	✓ (exp.)	✗	✗
axe DevTools	✓	✗	✗	✓ (au niveau page)
Go Tools Color Converter	✓	✓	✓ (8 types)	✓ (Tints/Shades)

Un workflow qui tient sous pression produit ressemble à ceci :

Dans Figma, les designers font tourner Stark sur chaque frame pour faire remonter les paires en échec tôt. Stark attrape les coupables évidents avant qu’aucun code hex n’atteigne le code source.
À la passation du code hex, les ingénieurs collent la valeur dans le Convertisseur de couleurs pour obtenir ratio WCAG + APCA Lc + classification de gamut + aperçu CVD sur une seule ligne. Si la paire est en mode sombre ou de marque saturée, la double métrique attrape les cas WCAG-passe-APCA-échoue que Stark peut manquer.
Au moment de la PR, axe-core/playwright scanne les pages construites pour toute violation de contraste sur le DOM rendu, états dynamiques compris. Cela attrape les anneaux de focus, les états hover et les affordances désactivées que les fichiers de design statiques ratent.
En QA, l’onglet Rendering des Chrome DevTools simule protanopia/deuteranopia/tritanopia pour des vérifications ponctuelles sur les flux critiques. Le Color Picker des DevTools affiche aussi un ratio WCAG en ligne quand vous survolez un élément.

Pa11y, Lighthouse CI et @axe-core/playwright exposent tous des assertions de contraste dans le cadre de leurs audits d’accessibilité plus larges. Aucun ne vérifie APCA aujourd’hui ; ils vérifient tous WCAG 2. La voie réaliste est « imposer WCAG 2 AA en CI, vérifier APCA Lc manuellement pour les couleurs de marque et le mode sombre ».

Un patron à emprunter aux grandes équipes design-system : intégrez la vérification de contraste à votre étape de validation des tokens, pas seulement à la QA au niveau page. Si vos tokens de design se compilent depuis un fichier source (JSON, YAML ou un module TypeScript), ajoutez un script qui énumère chaque appariement --text-* × --surface-* autorisé par le système et assure un ratio WCAG minimum. Le script tourne en millisecondes, attrape les régressions quand quelqu’un ajuste une valeur de token, et produit une matrice de contraste qui sert aussi de documentation pour l’équipe design. La vérification est indépendante de toute page rendue — elle opère purement sur les tokens, donc elle attrape l’échec avant qu’aucune UI ne soit livrée.

Pour les conversions ad hoc pendant ce workflow — passer entre hex, RGB, HSL et OKLCH pendant que vous déboguez — les spokes HEX vers RGB, HEX vers HSL, HEX vers OKLCH et RGB vers HEX couvrent les allers-retours vers et depuis n’importe quel format de couleur que votre toolchain attend.

Erreurs courantes et comment les corriger

Après des années d’audits d’accessibilité, les six mêmes échecs reviennent en boucle. Chacun a sa parade nette :

Texte de placeholder en gris clair. #999999 sur blanc donne 2.85:1, échec AA. Soit vous foncez à #666666 (5.74:1, AA validé), soit, mieux, vous remplacez les patrons placeholder-comme-libellé par un libellé visible permanent au-dessus du champ. Les placeholders ne devraient pas porter d’information.
Bouton orange de marque avec texte blanc. #FFA500 sur blanc, c’est 1.97:1, échec AA franc. La correction qui préserve la marque consiste à inverser le sens de contraste : texte sombre (par ex. #451a03) sur le fond orange, ou conserver le texte blanc en fonçant le bouton vers un brun-orange profond saturé. Vérifiez dans le Convertisseur de couleurs avant la mise en ligne.
Lien bleu vif en mode sombre. #3b82f6 sur #000000, c’est 5.71:1, succès WCAG AA, mais APCA Lc ~65, sous le seuil corps Lc 75. Passez par OKLCH et faites monter L de ≈ 0.63 à 0.75 en gardant C et H fixes ; vous atterrirez près de #7aa5f8 avec un APCA Lc 80+ confortable et la même teinte.
Texte désactivé en #CCCCCC. 1.61:1 contre blanc. WCAG 1.4.3 exempte le texte purement décoratif de la règle de ratio, mais les contrôles UI désactivés ne sont pas décoratifs : ils communiquent « ceci est actuellement indisponible ». Associez la couleur atténuée à un indice non chromatique (barré, icône cadenas, info-bulle « Désactivé ») pour qu’un utilisateur CVD ou malvoyant comprenne quand même l’état.
Icônes d’état qui ne diffèrent que par la teinte. Un × rouge et un ✓ vert, c’est bon parce que la forme les distingue déjà. Un point rouge contre un point vert, non. Utilisez forme et couleur conjointement ; l’aperçu CVD du Convertisseur de couleurs rend le cas d’échec évident en une seconde.
Texte au-dessus d’un fond en dégradé. Un dégradé qui va de #3b82f6 à #a78bfa contre du texte blanc passe le contraste au milieu et échoue vers le bout lavande. La parade consiste à imposer le contraste contre le point le pire du dégradé, ou à superposer un voile sombre semi-transparent pour que la luminance effective du fond reste toujours sous un seuil connu.

Chaque correction prend quelques minutes. Le cycle d’audit qu’elles évitent, lui, prend des semaines.

FAQ

Qu’est-ce que le ratio de contraste WCAG AA ?

WCAG AA exige ≥ 4.5:1 entre le corps de texte et l’arrière-plan, ou ≥ 3:1 pour le texte large (≥ 18pt regular ou ≥ 14pt bold) et les composants UI comme les bordures de formulaire. AA est le plancher légal sous ADA, EAA et Section 508 ; la plupart des sites commerciaux visent AA parce qu’il couvre la barre réglementaire sans forcer les couleurs de marque vers le niveau de gris.

Quel ratio de contraste me faut-il pour AAA ?

WCAG AAA exige ≥ 7:1 pour le corps de texte normal et ≥ 4.5:1 pour le texte large. AAA est recommandé pour les sites médicaux, éducatifs et gouvernementaux où la base utilisateurs penche vers des besoins d’accessibilité plus élevés. Les couleurs de marque doivent souvent être aplaties vers des valeurs proches du niveau de gris pour passer AAA, ce qui explique pourquoi beaucoup de produits commerciaux s’arrêtent à AA.

Qu’est-ce qu’APCA et est-ce WCAG 3.0 ?

APCA (Advanced Perceptual Contrast Algorithm), conçu par Andrew Somers / Myndex, est un algorithme candidat dans le cadre du projet WCAG 3 Silver. Il utilise des scores Lc sensibles à la polarité allant de -108 à +108 plutôt que des ratios symétriques. En 2026, WCAG 3 est encore en brouillon précoce et APCA n’a pas été formellement ratifié ; WCAG 2.1 / 2.2 AA demeure le standard réglementaire à atteindre aujourd’hui.

Le mode sombre aide-t-il l’accessibilité du contraste ?

Parfois, mais pas automatiquement. Le ratio symétrique de WCAG 2 valide les mêmes combinaisons en mode clair et en mode sombre, mais APCA (sensible à la polarité) signale souvent le corps de texte en mode sombre comme plus difficile à lire que la même paire hex en mode clair. Re-testez systématiquement le mode sombre avec WCAG et APCA avant la mise en ligne ; le clair sur sombre perd du contraste perçu d’une manière que le ratio symétrique ne voit pas.

Pourquoi ma couleur de marque échoue-t-elle à WCAG AA ?

Les couleurs saturées à luminance moyenne (la plupart des oranges, jaunes, verts citron, bleus clairs) ont des valeurs de luminance relative trop proches du blanc pour franchir 4.5:1. La parade : conserver la teinte de marque pour les accents et les grands titres, mais associer le corps de texte à un ton plus foncé de la même famille de teintes. Utilisez OKLCH pour baisser le canal L sans décaler la teinte ; le Convertisseur de couleurs trouve la nuance la plus proche qui passe en une étape.

Les ratios WCAG 2 et les scores APCA sont-ils compatibles ?

Non. WCAG 2 renvoie un ratio symétrique (1 à 21) ; APCA renvoie un score Lc signé en polarité (-108 à +108). La relation est non linéaire : une paire à 4.5:1 en WCAG peut donner Lc 60 ou Lc 75 en APCA selon laquelle des deux couleurs est au-dessus. Traitez-les comme deux vérifications indépendantes, pas comme des traductions l’une de l’autre.

Puis-je appliquer le contraste de couleur aux petites icônes UI ?

Oui, avec des nuances. WCAG 2.1 §1.4.11 exige ≥ 3:1 pour les composants UI et les objets graphiques. Pour les icônes décoratives associées à un libellé textuel visible, les exigences de contraste se relâchent — le libellé porte le sens. Pour les icônes autonomes (par ex. une loupe de recherche sans libellé), imposez la totalité des 3:1 contre le fond environnant.

Comment tester le daltonisme sans simuler ?

Utilisez Chrome DevTools → Rendering → « Emulate vision deficiencies » pour protanopia, deuteranopia, tritanopia et achromatopsia. Combinez avec l’aperçu CVD 8 types du Convertisseur de couleurs pour les variantes de trichromatie anormale (la deutéranomalie étant la plus courante avec 5 % des hommes). Pour le reporting d’audit, capturez des screenshots sous chaque simulation pour que les relecteurs voient les modes d’échec en ligne.

Conclusion

Cinq points à retenir :

AA 4.5:1 est le plancher légal. Atteignez-le sur tout corps de texte ou attendez-vous à du bruit côté conformité.
AAA 7:1 vise la santé, l’éducation et le gouvernement. La plupart des marques commerciales s’arrêtent à AA par choix.
APCA Lc est le test de bon sens sur la vraie lisibilité. Faites-le tourner en parallèle de WCAG 2, surtout pour le mode sombre et les couleurs de marque saturées.
La couleur n’est jamais le seul signal. Doublez chaque indice chromatique d’une forme, d’un texte ou d’un motif ; la deutéranomalie à elle seule représente 5 % des utilisateurs masculins.
Le L d’OKLCH est la bonne molette. Quand une couleur échoue au contraste, réduisez L (pas S, pas B) pour corriger sans dériver de teinte.

Collez deux codes hex dans le Convertisseur de couleurs pour voir ratio WCAG, APCA Lc, classification de gamut et aperçu CVD 8 types côte à côte. Cette vue unique remplace six outils séparés et reste le moyen le plus rapide de boucler les audits décrits dans ce guide.

Guide du contraste WCAG : ratios AA, AAA et algorithme APCA