Contraste des couleurs pour l’accessibilité : WCAG 2.1, APCA et ce qu’il faut vraiment livrer

WCAG 2.1 exige un ratio de contraste de 4,5:1 pour le texte courant régulier et 3:1pour le grand texte (18 pt+ régulier ou 14 pt+ gras). La formule est la norme légale de fait aux États-Unis (pertinente pour l’ADA), dans l’UE (EAA) et dans la plupart du monde. Elle a aussi des défauts bien documentés qui ont engendré un remplacement (APCA) qui n’a pas été intégré à WCAG 2.2. Ce guide explique le tableau pratique aujourd’hui.

La formule de contraste WCAG 2.x

Définie dans WCAG 2.0 (2008) et inchangée jusqu’en 2.2 :

contraste = (L_clair + 0,05) / (L_foncé + 0,05)
où L = luminance relative (0-1) de chaque couleur, calculée en sRGB linéaire

Les résultats vont de 1:1 (couleurs identiques) à 21:1 (blanc pur sur noir pur).

Seuils WCAG (pour la conformité AA, la cible standard) :

• 4,5:1 — texte courant, icônes, contrôles de formulaire.
• 3:1 — grand texte (≥ 18 pt ou ≥ 14 pt gras), composants d’interface (bordures de boutons, indicateurs de focus).
• Les cibles AAA sont plus strictes : 7:1 texte courant, 4,5:1 grand texte. Requis uniquement dans certains contextes spécifiques.

Où la formule est incorrecte

Trois problèmes documentés :

1. Insensibilité aux tons moyens.La formule donne des scores de contraste égaux à des paires de tons moyens (ex. gris sur gris) qui semblent très différentes en perception réelle. Une paire de 4,5:1 de gris moyens peut être visuellement plus faible qu’une paire de 3:1 de noir sur gris clair.
2. Aveugle aux teintes. Des teintes à luminance égale (rouge et vert à la même luminosité) obtiennent un score de contraste de 1:1, mais les utilisateurs dichromates peuvent les distinguer mal de toute façon.
3. Graisse de police ignorée.Les polices fines ont besoin de plus de contraste que les polices grasses à la même taille ; WCAG ne donne aucun crédit pour la graisse au-delà du seuil binaire “grand texte”.

APCA : le remplacement qui n’a pas été intégré à WCAG 2.2

APCA (Accessible Perceptual Contrast Algorithm — Algorithme de Contraste Perceptuel Accessible) est la métrique de contraste de prochaine génération proposée et rejetée. Développé par Andrew Somers pour le brouillon de travail WCAG 3.0. Il tient compte des problèmes ci-dessus et est dramatiquement plus précis par rapport aux données d’études utilisateurs réelles.

Les scores APCA vont de −108 à +106. Positif signifie texte foncé sur fond clair ; négatif signifie l’inverse. Seuils :

• Lc 75 — texte courant (remplace le 4,5:1 de WCAG).
• Lc 60 — grand texte ou titres (remplace le 3:1).
• Lc 45 — texte non-contenu (décoratif, mentions légales).

APCA donne des seuils différents par direction (clair sur foncé vs foncé sur clair) parce que les yeux humains traitent les deux cas différemment. La formule symétrique de WCAG manque cela.

Que faire en 2026

Approche à deux voies :

1. Respecter WCAG 2.1 AA au minimum.C’est la norme légale. Utilisez la formule standard de ratio, visez 4,5:1 texte / 3:1 grand. Outils : npm i wcag-contrastpour le programmatique, Chrome et Firefox DevTools (les deux indiquent le contraste au survol) pour l’ad-hoc.
2. Utiliser APCA comme vérification de bon sens. Quand WCAG passe mais que le résultat semble visuellement faible, APCA le signale généralement. APCA est disponible comme apca-w3 (npm) et dans des outils dédiés (Atmos, plugins Stark).

Les deux métriques s’accordent sur les cas évidents (texte noir sur blanc passe ; gris pâle sur blanc ne passe pas). Elles divergent sur les cas limites de tons moyens et de grand texte — exactement là où les tendances de design modernes aiment vivre.

Recommandations concrètes

• Texte courant : viser #1a1a1a(gris foncé) sur blanc donne ~17:1 — agréable, clairement lisible. Le noir pur sur blanc (21:1) peut sembler dur ; un quasi-noir délibéré est acceptable.
• Texte désactivé / espace réservé :WCAG exempte les “composants d’interface inactifs” de la règle des 4,5:1, mais les utilisateurs ont quand même besoin de lire les espaces réservés. Visez 3:1 minimum.
• Boutons :le texte du bouton vs le fond du bouton doit atteindre 4,5:1. La bordure du bouton vs le fond de la page doit atteindre 3:1 (pour la règle du “contraste non-textuel”).
• Indicateurs de focus :le contour de focus doit atteindre 3:1 contre le fond adjacent. C’est la règle qui se brise le plus quand les designers suppriment les contours de focus par défaut du navigateur.
• Mode sombre :la formule WCAG est symétrique ; les chiffres se traduisent. Mais APCA est asymétrique — le mode sombre tend à nécessiter des tokens de design légèrement différents du mode clair pour la même qualité perçue. Ne faites pas qu’inverser les couleurs.

Ce qu’il faut éviter

• Ne pas utiliser le contraste comme seul signal d’état. Les états d’erreur ont besoin de contraste etd’un autre indice (une icône, du texte). Les utilisateurs daltoniens peuvent ne pas distinguer les erreurs rouges des succès verts même à fort contraste.
• Ne pas viser AAA de façon réflexive.Les propres directives de WCAG disent que AAA “n’est pas recommandé comme politique générale pour des sites entiers” — c’est pour des contextes spécifiques. AA est le plafond de design pour la plupart des produits.
• Ne pas faire confiance sans critique aux rampes de couleurs auto-générées. Une rampe OKLCH avec des étapes perceptuellement égales ne passe pas automatiquement WCAG. Vérifiez chaque paire adjacente.

Le flux de travail pragmatique

Au moment du design : utilisez le vérificateur de contraste WCAG dans votre outil de design (Figma, Sketch, Adobe XD ont tous des plugins). Atteignez les minimums 4,5:1 / 3:1.

Au moment du code : validez vos tokens de design contre WCAG avecwcag-contrast ou similaire. Faites échouer le CI sur les régressions.

Au moment du QA : tests réels avec lecteur d’écran et navigation au clavier. Le contraste n’est qu’une petite partie de l’accessibilité ; les chemins clavier et lecteur d’écran sont là où la plupart des bugs d’accessibilité vivent réellement.

Exemple travaillé : une couleur de marque qui “passe”

Sarcelle de marque #3aa6a0 sur fond blanc. Contraste WCAG :2,99:1— échoue AA pour le texte courant (besoin de 4,5:1) et échoue le seuil de 3:1 pour le grand texte d’un cheveu. Score APCA : Lc 52, que APCA évalue comme “utiliser uniquement pour le texte non-contenu ou au-dessus de 24 px.” Les deux métriques s’accordent : cette sarcelle ne passe pas comme texte courant sur blanc.

En assombrissant la sarcelle d’un cran à #2f8682 : WCAG 4,52:1 (passe AA texte courant), APCA Lc 67(passe APCA pour le grand texte, marginal pour le texte courant). Un changement d’un chiffre hexadécimal fait passer le composant de l’échec à la réussite — et la teinte perçue reste reconnaissablement la même sarcelle.

Erreurs courantes

• Tester uniquement contre le blanc. Texte courant sur un panneau coloré, texte de bouton sur un bouton coloré, texte de lien dans un pied de page avec fond sombre — chaque paire a besoin de sa propre vérification.
• Ignorer le texte sur les images.Les titres héros sur des photographies échouent presque toujours quelque part sur l’image. Solutions : une superposition sombre semi-transparente sous le texte (opacité 0,4-0,6), une ombre de texte créant du contraste au bord des glyphes, ou repositionner le texte sur un panneau solide.
• S’appuyer sur les états de survol pour la lisibilité. Les styles de survol améliorent souvent le contraste — mais l’état au repos est ce que l’utilisateur lit. Si l’état au repos échoue, le survol ne le sauve pas.
• Utiliser rgba() avec alpha faible pour le texte. Le texte translucide hérite de ce qui est derrière. Le contraste calculé dépend du fond ; sur un fond coloré, un alpha < 0,8 échoue presque toujours. Utilisez des valeurs hex opaques pour le texte.
• Traiter la simulation daltonien comme un test d’accessibilité. Les outils de simulation montrent approximativement ce que voit un utilisateur daltonien. Ils ne testent pas si le contraste est adéquat ; ils testent si les couleurs sont distinguables. Les deux vérifications sont nécessaires.

Pour les mécanismes d’espace colorimétrique sous-jacents que la formule linéarise, voir notre guide des formats de couleur CSS.

Sources : W3C WCAG 2.1 (2018) et WCAG 2.2 (2023) ; brouillon de travail WCAG 3.0 (2024) ; Andrew Somers, documentation APCA-W3 et études utilisateurs à l’appui ; règle d’accessibilité web ADA Titre III du DOJ américain (2024) ; loi européenne sur l’accessibilité (Directive 2019/882).