Ce que les WCAG ne couvrent pas

Les Web Content Accessibility Guidelines définissent des ratios de contraste minimaux : 4.5:1 pour le texte normal, 3:1 pour le texte large (WCAG 2.2 AA). C'est un progrès considérable par rapport à l'absence de norme, mais les recherches de Legge et al. (1990) et leur actualisation par Bailey et al. (2012) montrent que ces ratios sont insuffisants dans plusieurs contextes : basse luminosité, écran en extérieur, basse vision, et certains types de daltonisme.

Le daltonisme (CVD — Color Vision Deficiency) touche 8 % des hommes et 0,5 % des femmes de descendance européenne. Les trois types principaux — protanopie (déficit rouge), deutéranopie (déficit vert), et tritanopie (déficit bleu) — rendent certaines combinaisons de couleurs indistinguables. Un bouton rouge « Supprimer » à côté d'un bouton vert « Valider » est invisible pour un utilisateur protanope : les deux boutons semblent identiques.

Les ratios WCAG mesurent le contraste de luminance, pas la distinguabilité chromatique. Un texte orange sur fond vert peut avoir un ratio de 4.5:1 (conforme WCAG AA) tout en étant illisible pour un deutéranope. C'est une limitation structurelle que les guidelines reconnaissent mais ne résolvent pas.

APCA : la prochaine génération de mesure du contraste

L'Advanced Perceptual Contrast Algorithm (APCA), développé par Somers (2022) et candidat pour les futures WCAG 3.0, corrige plusieurs limitations des ratios actuels. L'APCA prend en compte la polarité (texte sombre sur fond clair est plus lisible que l'inverse), la taille du texte (les petits textes nécessitent plus de contraste), et le poids de la police (le gras est plus lisible à contraste égal).

En pratique, l'APCA produit des résultats plus intuitifs. Le texte gris clair (#777) sur blanc (#FFF) est conforme WCAG 2.2 AA en mode texte large, mais l'APCA le signale comme insuffisant pour les paragraphes. Inversement, certaines combinaisons rejetées par WCAG 2.2 (texte foncé sur fond légèrement coloré) sont acceptées par l'APCA quand la lisibilité réelle est bonne.

Pour les designers, l'APCA n'est pas encore un standard obligatoire, mais l'utiliser en complément des WCAG actuelles améliore significativement la lisibilité réelle. L'outil de calcul est disponible en open source et s'intègre facilement dans un workflow de design system.

Concevoir pour le daltonisme : au-delà du filtre

L'approche la plus répandue pour « tester » le daltonisme est de passer une maquette dans un filtre de simulation (plugin Figma, mode daltonien de Chrome DevTools). C'est utile pour identifier les problèmes, mais insuffisant pour les résoudre. Les travaux de Jenny et Kelso (2007) sur la cartographie et de Geissbuehler et al. (2018) sur les interfaces montrent que la solution n'est pas d'ajuster les couleurs — c'est de ne pas dépendre uniquement de la couleur.

Le critère WCAG 1.4.1 (« Use of Color ») l'exprime clairement : la couleur ne doit pas être le seul moyen de transmettre une information. Un état « erreur » en rouge doit aussi avoir une icône, un texte, ou une bordure distinctive. Un graphique avec des courbes colorées doit aussi utiliser des tirets, des points ou des labels. Ce principe est simple à énoncer mais systématiquement violé dans la pratique.

Le pattern le plus robuste : le « double codage ». Chaque information portée par la couleur est doublée par un autre canal — forme, icône, texte, position, texture. Un feu tricolore est un bon exemple : la position (haut, milieu, bas) redonde avec la couleur. Même un utilisateur achromatope total (vision en noir et blanc) peut utiliser un feu tricolore grâce à la position.

Basse vision et conditions d'éclairage extrêmes

La basse vision touche 246 millions de personnes dans le monde (OMS, 2023). Ces utilisateurs ne sont pas aveugles — ils voient, mais avec une acuité réduite, un champ visuel restreint, ou une sensibilité au contraste diminuée. Les ratios WCAG sont calibrés pour une vision « normale corrigée » et un éclairage intérieur standard.

Les recherches de Arditi et Cho (2005) montrent que les utilisateurs avec une basse vision ont besoin de ratios de contraste 2 à 3 fois supérieurs au minimum WCAG pour une lisibilité confortable. Concrètement : viser un ratio de 7:1 ou plus pour tout texte essentiel, pas seulement le 4.5:1 du niveau AA.

Les conditions d'éclairage extérieur dégradent aussi la lisibilité. Un écran de smartphone en plein soleil perd 60 à 80 % de son contraste apparent. Les recherches de Kim et al. (2021) recommandent des interfaces à « high contrast mode » automatique basé sur le capteur de luminosité ambiante — pas juste la luminosité de l'écran, mais un ajustement des couleurs d'interface pour maximiser le contraste en conditions extrêmes.

Palette inclusive : méthode pratique

La construction d'une palette de couleurs véritablement inclusive suit un processus en 4 étapes, formalisé par les travaux de Coughlin (2018) et les recommandations du Inclusive Design Toolkit de Microsoft. Étape 1 : choisir des couleurs qui passent le test de contraste WCAG AA (4.5:1) et idéalement AAA (7:1) pour les éléments textuels.

Étape 2 : vérifier la distinguabilité en simulation daltonienne — pas juste la visibilité, mais la capacité à distinguer deux couleurs adjacentes. Si « succès » et « erreur » sont indistinguables en deutéranopie, ajouter un second canal (icône, forme). Étape 3 : tester en niveaux de gris — si l'interface est compréhensible en noir et blanc, elle fonctionnera pour tous les types de vision. Étape 4 : valider avec des utilisateurs réels ayant des déficiences visuelles, parce que les simulations sont des approximations.

Un conseil final : les design systems devraient inclure des rôles sémantiques de couleur (success, warning, error, info) et les implémenter avec double codage par défaut — couleur + icône + label. Quand un designer utilise le token « color-error », le système fournit automatiquement la couleur rouge, l'icône ⚠️ et le texte « Erreur ». Pas juste la couleur seule.