Préférences des media queries : respecter les choix des utilisateurs

Les fonctionnalités média CSS permettent à une page de s'adapter aux préférences d'accessibilité et d'apparence exposées par le navigateur ou un autre agent utilisateur, y compris leurs valeurs par défaut, sans indiquer si une personne les a choisies. Des requêtes comme prefers-reduced-motion, prefers-contrast, forced-colors et prefers-color-scheme aident un site à commencer avec une présentation qui respecte ces préférences exposées. Elles doivent servir de paramètres à une conception utilisable, et non remplacer des valeurs par défaut lisibles, des commandes sémantiques ou un moyen explicite de choisir l'apparence.

La règle pratique est simple : respecter la préférence, préserver la tâche et rendre toute dérogation propre au site facile à trouver et à annuler. Une personne sensible aux animations doit toujours pouvoir comprendre un changement d'état ; une personne utilisant une palette système doit pouvoir distinguer les commandes ; et une personne préférant une interface sombre ne devrait pas se voir imposer un thème sombre peu contrasté sur tout le site. Le guide sur les interactions au pointeur traite d'un autre aspect de l'adaptation des interfaces, tandis que la validation des interactions dans le navigateur et la protection de la vie privée dès la conception des workflows de navigateur présentent des principes plus généraux de test et de choix.

Les préférences orientent la conception sans garantir l'accessibilité

Les media queries sont des règles conditionnelles en CSS. Une requête teste une fonctionnalité média, comme la palette préférée ou l'application d'une palette de couleurs forcée par le navigateur, puis permet à la feuille de style de sélectionner les déclarations correspondantes. Le mécanisme est comparable à l'adaptation d'une mise en page à la largeur de la fenêtre, mais la condition représente une préférence de présentation et non une dimension physique de l'écran. Le navigateur évalue la requête et applique les règles correspondantes lorsque l'environnement change.

Ces fonctionnalités exposent un ensemble limité de valeurs définies par la plateforme Web. Elles n'indiquent pas pourquoi une personne a choisi un paramètre, quelles technologies d'assistance elle utilise ni quelle présentation lui conviendra dans chaque contexte. Une application ne devrait pas tenter d'inférer ces renseignements privés. Elle peut répondre à la préférence exposée par le navigateur et proposer une interface cohérente sans attribuer d'étiquette ni de capacité à la personne. Une préférence est un signal utile pour la conception, pas un profil utilisateur.

Cette distinction importe, car une media query ne peut pas corriger tous les problèmes d'accessibilité. Une règle de réduction des animations ne peut pas ajouter un libellé manquant à une commande. Une palette sombre ne garantit pas à elle seule que le texte soit lisible. Une adaptation aux couleurs forcées ne remplace pas une structure HTML porteuse de sens. Quelle que soit la présentation, il faut un contraste suffisant, un focus visible, un état compréhensible et des commandes utilisables avec les modes d'interaction pris en charge par le produit.

Utilisez les media queries comme une amélioration progressive. Commencez par une expérience complète par défaut, puis ne modifiez que les éléments qui doivent répondre à la préférence. Le contenu, la hiérarchie et l'accomplissement de la tâche doivent rester cohérents d'un thème à l'autre. Par exemple, si une animation communique la progression, sa réduction ne doit pas faire disparaître cette information ; un indicateur statique ou un bref état textuel peut transmettre le même message. Si une couleur signale une erreur, le message et les icônes doivent aussi la rendre compréhensible.

Préférez le CSS pour les changements visuels, car le navigateur peut réévaluer les styles sans attendre le code de l'application. JavaScript convient lorsqu'une préférence doit modifier un comportement que le CSS ne peut pas contrôler, par exemple décider de lancer ou non une séquence animée facultative. Limitez ce comportement et permettez de l'arrêter ou de le modifier. N'utilisez pas JavaScript pour reconstruire une préférence que le CSS peut gérer directement, et n'enregistrez pas un choix issu du navigateur comme s'il s'agissait d'une sélection délibérée dans les paramètres du site.

La réduction des animations doit préserver le sens et le contrôle

La fonctionnalité média prefers-reduced-motion peut correspondre lorsqu'une personne a demandé à réduire les animations non essentielles de l'interface. Une feuille de style peut utiliser @media (prefers-reduced-motion: reduce) pour supprimer ou raccourcir les transitions, effets de parallaxe, défilements animés, mouvements lancés automatiquement et autres animations inutiles à la tâche. La valeur no-preference indique que l'agent utilisateur n'applique pas de demande de réduction ; elle n'autorise pas à animer chaque interaction et ne signifie pas que les mouvements conviennent à tout le monde.

Commencez par distinguer les mouvements décoratifs de ceux qui transmettent une information nécessaire. Une carte qui rebondit uniquement pour attirer l'attention peut généralement rester immobile. Une séquence de chargement peut être remplacée par un indicateur de progression stable ou un état textuel. Une transition de graphique peut afficher directement la nouvelle valeur tout en gardant les libellés et le contexte précédent visibles. Un panneau repliable peut s'ouvrir sans longue animation de glissement, tout en exposant son état aux technologies d'assistance. Il ne s'agit pas de masquer le changement, mais de le communiquer sans mouvement superflu.

Une règle globale peut constituer un point de départ utile, mais les composants ne devraient pas dépendre uniquement d'une substitution globale des durées. Le mouvement peut provenir des transitions CSS, des images clés, de bibliothèques d'animation JavaScript, de médias intégrés ou de contenus lancés automatiquement. Examinez l'expérience complète et ajoutez des règles par composant si nécessaire. Une règle qui ramène presque toutes les animations à une durée nulle peut laisser des rafraîchissements d'images gênants, des clignotements ou des mouvements pilotés par script. Elle peut aussi supprimer un délai qui aide à percevoir une interaction. Testez le résultat, pas seulement la correspondance d'un sélecteur.

Certains mouvements sont demandés directement, par exemple par un bouton de lecture vidéo ou l'ouverture explicite d'une animation de graphique. La préférence de réduction ne doit pas rendre silencieusement une commande essentielle indisponible. Prévoyez plutôt une présentation statique de remplacement, un état initial en pause ou une action explicite pour démarrer, avec une commande visible d'arrêt ou de pause. Le critère de succès 2.2.2 des WCAG 2.2 s'applique au contenu en mouvement, clignotant ou défilant qui démarre automatiquement, dure plus de cinq secondes et apparaît en parallèle d'un autre contenu : prévoyez un moyen de le mettre en pause, de l'arrêter ou de le masquer, sauf si ce mouvement est essentiel.

Si le produit propose son propre paramètre d'animation, formulez les choix clairement, par exemple « Réduire les animations » ou « Autoriser les animations de l'interface ». Expliquez l'effet concret à proximité plutôt que d'exposer le jargon d'implémentation. Il ne faut pas obliger une personne à ouvrir les paramètres du système pour arrêter un effet facultatif du site. À l'inverse, un paramètre du site ne doit pas remplacer silencieusement la demande du système d'exploitation. Par défaut, il est prudent de respecter la réduction du système ; un choix explicite du site peut ensuite ne concerner que ses animations facultatives, avec un moyen simple de revenir au réglage système.

Les préférences de contraste exigent des alternatives visuelles claires

La fonctionnalité prefers-contrast permet d'adapter les styles lorsque l'agent utilisateur indique une préférence pour davantage ou moins de contraste, ou pour un traitement particulier. Les valeurs prises en charge dépendent de la plateforme et de l'implémentation ; vérifiez la compatibilité actuelle avant de vous appuyer sur une valeur donnée. La responsabilité de conception dépasse une requête précise : le texte et les commandes ordinaires doivent rester perceptibles dans les conditions prises en charge, et l'information ne doit pas dépendre uniquement d'une différence de teinte subtile.

Pour une préférence more, les adaptations utiles comprennent un contraste texte-arrière-plan plus marqué, des bordures plus visibles, des indicateurs de focus renforcés et une distinction accrue entre les états voisins. Un onglet sélectionné ne devrait pas se distinguer uniquement par une légère variation de teinte. Associez la couleur à un soulignement, une forme, une graisse ou un autre état visible. Les commandes désactivées doivent rester compréhensibles sans se confondre avec le texte environnant. Les messages d'erreur et de réussite doivent inclure un libellé ou une icône en plus de la couleur.

Une préférence less peut convenir aux personnes que les contrastes intenses gênent. Elle ne signifie pas que le texte essentiel doit devenir pâle ni que les commandes doivent se fondre dans l'arrière-plan. Définissez une palette modérée qui conserve un texte lisible, des limites visibles et le focus. Vérifiez séparément les petits caractères, traits fins, textes indicatifs, états sélectionnés et états au survol. Une palette équilibrée dans un grand titre peut échouer dans un formulaire compact ou sur un bouton désactivé.

La valeur custom, lorsqu'elle est prise en charge, peut signaler une préférence de contraste définie par l'utilisateur qui ne correspond pas simplement à more ou less. Ne la traitez pas comme une instruction de créer un mode universel de contraste personnalisé. Le navigateur peut ne pas exposer les couleurs choisies par la personne au moyen de cette fonctionnalité média. Gardez la page lisible avec des valeurs par défaut soigneusement testées et proposez des thèmes sélectionnables si l'application peut offrir des alternatives utiles.

Ne comptez pas sur une requête de préférence pour satisfaire les besoins minimaux de contraste. Certaines personnes ne savent pas où activer une option du système ; leur navigateur peut ne pas l'exposer, ou le contenu peut être affiché dans un environnement qui transforme les couleurs. Vérifiez le texte, les objets graphiques essentiels, les anneaux de focus et les limites des commandes par rapport aux critères d'accessibilité applicables, dans le thème par défaut et les modes pris en charge. Les changements de contraste ne doivent ni effacer l'identité visuelle ni produire une palette secondaire jamais évaluée à la taille réelle du contenu.

Les couleurs forcées appellent les couleurs système et la retenue

La fonctionnalité forced-colors indique que l'agent utilisateur impose une palette limitée. Ce mode diffère d'une préférence pour le contraste élevé : le navigateur peut remplacer les couleurs définies par l'auteur par celles choisies par la personne ou le système, afin de coordonner les avant-plans et les arrière-plans. Une requête comme @media (forced-colors: active) permet d'apporter des ajustements ciblés lorsque la palette forcée modifie des distinctions visuelles importantes dans la présentation normale.

Dans ce mode, préservez la capacité du navigateur à appliquer la palette. Des mots-clés de couleur système comme Canvas, CanvasText, LinkText, ButtonFace et ButtonText expriment des relations avec les couleurs système actives au lieu d'imposer une valeur RVB claire ou sombre. Préférez les commandes natives lorsque leur sémantique convient. Pour les commandes personnalisées, vérifiez que les bordures, le focus, la sélection et les états restent perceptibles après l'ajustement des couleurs par l'agent utilisateur. Une bordure volontairement transparente dans le thème normal peut devoir devenir visible pour que les limites de la commande restent claires.

La propriété forced-color-adjust détermine si un élément est soumis aux ajustements de couleurs forcées. Il est normalement préférable de conserver le comportement par défaut. La valeur forced-color-adjust: none soustrait un élément aux ajustements. Ne l'utilisez que pour un élément limité lorsque l'application adapte elle-même ses couleurs aux besoins de couleur et de contraste de la personne, puis vérifiez le résultat en mode couleurs forcées. Exclure toute une page peut neutraliser la palette choisie et créer des combinaisons illisibles. Il vaut généralement mieux préserver la structure et utiliser les couleurs système pour les éléments qui doivent s'adapter.

Ne supposez pas qu'une image ou un arrière-plan décoratif restera disponible en mode couleurs forcées. Une information portée par une image d'arrière-plan CSS peut disparaître si les arrière-plans sont supprimés ou recolorés. Utilisez du vrai texte, des noms accessibles, des bordures ou un élément graphique intégré approprié avec une solution de repli visible pour l'information essentielle. Pour les icônes dont le sens dépend du remplissage, vérifiez qu'un contour reste visible. Testez le focus clavier et les états sélectionnés dans l'environnement réel de couleurs forcées : des captures du thème habituel ne révèlent pas tous les remplacements.

Les couleurs forcées ne sont pas une invitation à créer un thème noir et blanc codé en dur qui concurrence les réglages du système. La palette du système est un choix visible de la personne et peut comporter d'autres couleurs. Laissez la plateforme agir, puis ajoutez le minimum de CSS nécessaire pour conserver une hiérarchie de contenu et des commandes utilisables. Évitez de remplacer les couleurs système globalement ou d'utiliser forced-color-adjust: none comme raccourci pour préserver l'apparence.

La palette doit respecter un choix explicite dans le site

La fonctionnalité prefers-color-scheme peut sélectionner des styles en fonction d'une préférence claire ou sombre. La page peut ainsi commencer avec une palette adaptée au choix du navigateur ou du système d'exploitation, y compris si la personne modifie ce choix pendant qu'elle consulte la page. Un thème sombre peut réduire la surface lumineuse dans certains environnements, tandis qu'un thème clair peut mieux convenir à d'autres usages. Aucun n'est universellement supérieur : chacun demande des choix de couleurs réfléchis et des tests.

La propriété CSS color-scheme indique les palettes qu'un élément ou un document peut prendre en charge. Déclarer les modes clair et sombre peut aider l'agent utilisateur à afficher les commandes intégrées, les champs de formulaire et les autres surfaces fournies par le navigateur dans une palette compatible. Cette déclaration ne garantit pas l'accessibilité de toute la page et ne remplace pas les styles du contenu du site. Coordonnez-la avec les palettes réellement disponibles afin que les champs natifs n'utilisent pas un mode différent du reste de l'interface.

Avec une commande de thème propre au site, distinguez le mode « système » d'un choix explicite « clair » ou « sombre ». La valeur initiale peut suivre la préférence système ; un choix délibéré peut ensuite la remplacer jusqu'à ce que la personne le modifie. Placez la commande dans une zone de réglages prévisible, nommez-la en langage clair et permettez de revenir facilement au mode « système ». Ne quittez pas automatiquement un thème choisi explicitement parce que la préférence du système d'exploitation change ensuite.

N'enregistrez un choix du site que si cette mémorisation sert la fonctionnalité et si la personne comprend ce qui sera retenu. Stockez la valeur correspondant au choix explicite, et non une copie de la préférence du navigateur lors du premier chargement. Lorsque le choix est « système », continuez à suivre la préférence système actuelle. Ainsi, un thème qui correspondait auparavant ne devient pas une dérogation périmée après une modification des réglages de l'appareil. Cela permet aussi d'expliquer correctement le comportement de l'interface.

Les commandes de thème doivent avoir un nom accessible, fonctionner au clavier, afficher le focus et indiquer clairement le choix actif. Un contrôle segmenté peut proposer Système, Clair et Sombre sans cacher la valeur actuelle dans un menu. Si un interrupteur compact est utilisé, son libellé doit indiquer clairement l'état obtenu, pas seulement « activer/désactiver ». N'indiquez pas la sélection par la seule couleur. Vérifiez les couleurs du focus, des erreurs, des liens, des graphiques et des boîtes de dialogue dans chaque palette prise en charge, et évitez que le choix personnalisé ne provoque un bref affichage de la mauvaise palette avant l'application du réglage enregistré.

Un changement de préférence ne doit pas interrompre une tâche

Les media queries sont évaluées selon l'environnement actuel, pas seulement au chargement de la page. Le CSS peut réagir si une personne change le thème du système d'exploitation ou une préférence d'accessibilité pendant que le site reste ouvert. Le code JavaScript peut utiliser matchMedia() pour savoir si une requête correspond et écouter l'événement change lorsqu'un comportement applicatif doit réagir. La notification de changement de MediaQueryList doit mettre à jour le comportement pertinent, puis le code doit retirer son écouteur lorsque le composant ou la page n'en a plus besoin.

Limitez la réaction JavaScript. Une mise à jour du thème peut changer la couleur des libellés d'un graphique dessiné dans un canevas plutôt qu'en CSS. Un changement de réduction des animations peut arrêter une animation non essentielle pilotée par une bibliothèque de composants. Dans chaque cas, ne modifiez que la présentation ou le comportement concerné. Ne rechargez pas la page, ne perdez pas de travail non enregistré, ne fermez pas une boîte de dialogue et ne réinitialisez pas l'application à cause d'un changement de préférence. Les réponses uniquement en CSS sont généralement plus simples et moins susceptibles d'interrompre une tâche en cours.

Un choix explicite dans le site introduit une seconde source d'état : définissez donc la priorité au lieu de laisser l'ordre des événements en décider. Un modèle utile est le suivant : un choix explicite du site contrôle son apparence ; le mode « système » délègue la décision à la préférence actuelle du navigateur ; et un mode d'accessibilité comme les couleurs forcées reste respecté partout où l'agent utilisateur l'applique. Pour les animations, un réglage du site peut gouverner ses effets facultatifs, mais ne doit pas lancer une séquence automatique contraire à la demande de réduction. Présentez clairement les choix et facilitez le retour au comportement système.

Appliquez les changements sans masquer le contexte. Si un formulaire en cours est ouvert, le changement de thème doit conserver les valeurs saisies, les messages de validation, le focus et la position de défilement. Si la réduction des animations est activée pendant une transition, placez le composant dans un état stable au lieu de le laisser entre deux états. Si une palette personnalisée est choisie pendant l'ouverture d'un menu contextuel, mettez à jour ensemble le menu, son fond et l'anneau de focus. Le changement de préférence doit améliorer l'expérience en cours, sans obliger à recommencer.

Certains comportements de la plateforme prennent effet immédiatement ; d'autres, propres à l'application, peuvent attendre le prochain rendu. Ne promettez pas une mise à jour instantanée si un graphique asynchrone ou un composant intégré ne le permet pas. Signalez tout délai ou redémarrage nécessaire et laissez la possibilité d'annuler. La plupart des changements de présentation ne devraient pas nécessiter de rechargement ; si c'est réellement le cas, expliquez pourquoi avant que la personne confirme.

Tester l'expérience complète et prévenir les régressions

Construisez une matrice de régression autour des tâches réelles, pas seulement d'une galerie de captures. Incluez l'apparence par défaut, les préférences claire et sombre, la réduction des animations, les valeurs de contraste pertinentes prises en charge par les navigateurs cibles et les couleurs forcées sur une plateforme qui les propose. Testez les combinaisons possibles, comme un thème sombre avec réduction des animations ou un thème choisi dans le site alors que les couleurs forcées sont actives. La matrice précise dépend du produit, mais chaque mode annoncé doit avoir un résultat observable et une vérification reproductible.

Pour chaque parcours représentatif, vérifiez le début, l'état actif, l'achèvement et la récupération. Ouvrez et envoyez un formulaire, parcourez un menu, consultez un graphique, fermez une boîte de dialogue et revenez après une erreur. Vérifiez que le mode courant ne masque pas le focus, n'efface pas les limites des boutons, ne rend pas les états sélectionnés indiscernables et ne supprime pas l'information transmise par une animation. Répétez les parcours au clavier seul. Si la tâche dépend d'un lecteur d'écran ou d'une autre technologie d'assistance, vérifiez séparément les noms, rôles, valeurs et annonces : les media queries visuelles ne vérifient pas l'arbre d'accessibilité.

Les tests visuels automatisés peuvent repérer des déclarations manquantes ou des changements de mise en page inattendus ; les tests unitaires peuvent vérifier la priorité entre les choix système et les choix explicites du site. Ils ne peuvent pas établir seuls si un indicateur de focus est facile à voir, si une animation est éprouvante ou si une palette est agréable à utiliser. Complétez l'automatisation par des vérifications manuelles avec les paramètres d'accessibilité du navigateur ou du système d'exploitation. Consignez le navigateur, la plateforme, le mode, la tâche, le résultat attendu et le résultat observé afin de pouvoir reproduire une régression sans collecter les réglages personnels des visiteurs.

Testez aussi les changements en cours d'utilisation, pas seulement l'état initial. Commencez dans un thème, puis passez à un autre avec un formulaire partiellement rempli. Activez la réduction des animations pendant une transition. Modifiez le contraste alors qu'une commande a le focus. Activez ou désactivez les couleurs forcées lorsque la plateforme le permet. Vérifiez que l'interface se met à jour sans perdre le focus, les données saisies, la sélection ni un moyen clair de revenir en arrière. Ces situations testent la coordination des états que peut manquer une capture après un chargement neuf.

Enfin, examinez les contenus qui dépendent de la couleur, du mouvement ou de la forme. Les messages d'état doivent nommer le résultat ; les graphiques doivent avoir des libellés ou une autre représentation des données ; une animation ne doit pas être le seul moyen de découvrir qu'une opération est terminée ; et les icônes d'action doivent avoir un nom accessible. Un changement de thème ne devrait pas modifier l'interligne ou la taille du texte au point de perturber l'ordre de lecture attendu. La meilleure vérification est de savoir si une personne peut accomplir la même tâche, en comprendre le résultat et se remettre d'une erreur dans toutes les préférences prises en charge.

Sources publiques

• W3C Media Queries Level 5
• MDN : Utiliser les media queries
• W3C CSS Color Adjustment Module Level 1
• MDN : forced-colors
• W3C WCAG 2.2 : mettre en pause, arrêter, masquer