# Prendre en charge prefers-contrast dans un thème bloc, au-delà du mouvement

> prefers-reduced-motion est devenu un réflexe dans les thèmes de blocs. La préférence système de contraste, elle, reste presque toujours ignorée. Voici comment la prendre en charge concrètement.

- Auteur : Clément Hadrot
- Publié le : 2024-10-07
- Mis à jour le : 2024-10-07
- Catégorie : Accessibilité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/accessibilite/prefers-contrast-theme-bloc-wordpress/

## L’essentiel

- prefers-contrast propose more, less et custom, pas un simple oui ou non
- Le support navigateur reste partiel, prévoir une dégradation propre
- Combiner la media query avec les jetons de couleur de theme.json

« Est-ce que le thème gère prefers-reduced-motion ? » figure désormais dans la plupart des grilles de recette d'un thème de blocs WordPress. La question équivalente pour le contraste, « Est-ce que le thème gère prefers-contrast ? », n'y figure presque jamais. Cette dissymétrie ne reflète pas une différence d'importance entre les deux préférences, mais plutôt une différence de maturité de la prise en charge navigateur et de visibilité dans les outils de développement habituels.

La media query `prefers-contrast` permet à un système d'exposer au navigateur la préférence de contraste réglée par l'utilisateur, avec trois valeurs distinctes en plus de l'absence de préférence : `more` pour un contraste renforcé, `less` pour un contraste réduit, et `custom` lorsque l'utilisateur a défini un jeu de couleurs personnalisé via les réglages d'accessibilité de son système. Le support de cette media query reste partiel selon les navigateurs et les versions, ce qui impose de concevoir la prise en charge comme une amélioration progressive, jamais comme un mécanisme dont dépendrait la lisibilité de base du site.

## Où brancher la préférence dans un thème de blocs

Un thème basé sur `theme.json` déclare déjà sa palette de couleurs sous forme de jetons nommés, ce qui facilite grandement la déclinaison d'une variante à contraste renforcé : il suffit de redéfinir les mêmes variables CSS personnalisées à l'intérieur d'un bloc `@media (prefers-contrast: more)`, sans toucher au balisage ni à la structure des blocs eux-mêmes.

```
:root {
  --wp--preset--color--texte: #3a3a3a;
  --wp--preset--color--fond: #f7f7f5;
  --wp--preset--color--accent: #2563a8;
}

@media (prefers-contrast: more) {
  :root {
    --wp--preset--color--texte: #000000;
    --wp--preset--color--fond: #ffffff;
    --wp--preset--color--accent: #0b3d91;
  }
}
```

Parce que les blocs du cœur consomment déjà ces variables via les classes générées automatiquement à partir de `theme.json`, cette redéfinition suffit à propager le contraste renforcé à l'ensemble des blocs de contenu, sans dupliquer aucune règle spécifique à chaque type de bloc.

## Étape par étape

> L'essentiel à retenir : prefers-contrast propose more, less et custom, pas un simple oui ou non ; Le support navigateur reste partiel, prévoir une dégradation propre ; Combiner la media query avec les jetons de couleur de theme.json

1. Identifier dans `theme.json` les jetons de couleur réellement utilisés comme variables CSS personnalisées (préfixées `--wp--preset--color--`)
2. Choisir, pour chaque jeton, une valeur alternative dont le rapport de contraste dépasse largement le minimum WCAG 1.4.3 (au moins 7:1 pour le texte normal, en visant l'esprit du niveau AAA plutôt que le strict minimum AA de 4,5:1)
3. Regrouper ces redéfinitions dans un fichier CSS dédié, chargé après la feuille de style principale, encapsulé dans `@media (prefers-contrast: more)`
4. Vérifier au clavier et visuellement que les états interactifs (focus, survol, actif) restent lisibles avec la palette renforcée, pas seulement le texte courant
5. Tester le rendu réel sur un navigateur qui prend en charge la media query, en changeant le réglage système correspondant, plutôt que de se fier uniquement à un outil d'émulation

## Ce qu'il ne faut pas négliger

- Ne pas se limiter au texte : les bordures fines, les icônes et les séparateurs visuels perdent souvent en lisibilité avant le texte lui-même
- Vérifier le rendu des images avec superposition de texte, un cas fréquent dans les blocs de couverture, où un contraste renforcé du texte peut rendre l'image sous-jacente illisible
- Ne jamais faire dépendre la lisibilité de base du site de cette media query : elle doit rester une amélioration, la palette par défaut doit déjà respecter le critère WCAG 1.4.3

## Le cas du contraste réduit

La valeur `less` de `prefers-contrast` concerne un public différent, pour qui un contraste très élevé provoque de la fatigue visuelle ou des effets d'éblouissement, notamment chez certaines personnes présentant des troubles neurologiques ou une sensibilité visuelle particulière. Le traitement de cette valeur demande la même méthode, avec une palette légèrement adoucie plutôt qu'un simple gris pâle appliqué uniformément, qui risquerait de retomber sous le seuil minimal du critère 1.4.3.

> Nous recommandons de traiter `prefers-contrast` avec la même rigueur que `prefers-reduced-motion` dans toute checklist de recette de thème : les deux préférences relèvent du même principe, laisser le système exprimer un besoin que le site doit respecter sans configuration manuelle.

## En résumé

La prise en charge de `prefers-contrast` dans un thème de blocs demande peu de code une fois la structure de jetons de couleur de `theme.json` en place : l'essentiel du travail consiste à choisir des valeurs alternatives réellement contrastées et à vérifier leur effet sur l'ensemble des composants, pas seulement le texte courant. Le support navigateur encore inégal ne justifie pas d'ignorer cette préférence : elle se dégrade proprement vers la palette par défaut sur les navigateurs qui ne la reconnaissent pas encore, sans aucun risque de régression.