Contrôles natifs sur un thème sombre

La flèche qui ne s'affiche que sur le Mac du designer

Un thème sombre passe la revue comme chaque problème de cette série : sur les machines que possède l'équipe. Les maquettes sont nettes, le pied de page sombre avec l'inscription à la lettre l'est encore plus, et tous ceux qui l'approuvent sont sur le même système d'exploitation, le même navigateur et le même écran que le designer.

Puis un visiteur sur une machine Windows va ouvrir le menu déroulant des sujets. Ou essaie, parce que la flèche qui dit « ceci est un menu déroulant » est dessinée en gris foncé, par le navigateur, sur votre fond presque noir. Ce qu'il voit est un rectangle muet.

Personne ne signale un bogue, parce que personne ne peut en nommer un. Le formulaire n'est pas cassé ; il avait juste l'air fini avant de l'être. Les thèmes sombres ont un mode de panne que les thèmes clairs n'ont jamais appris à personne à vérifier : des parties d'un formulaire ne sont pas à vous à styler, et ces parties supposent une page claire tant qu'on ne leur dit pas le contraire.

Deux mains peignent chaque contrôle

Votre CSS contrôle les parties d'un champ qu'il a toujours contrôlées : la boîte, la bordure, le texte, l'arrière-plan. Mais un contrôle natif a des parties que la page ne touche jamais. La flèche du select, et la liste d'options qui s'ouvre dessous. Le calendrier qu'invoque un champ de date. La coche de la case à cocher. La barre de défilement dans un long textarea. Les boutons d'effacement et les yeux de révélation de mot de passe que certains navigateurs ajoutent d'eux-mêmes. Tout cela est peint par le navigateur et le système d'exploitation, depuis leur propre palette.

Et cette palette porte une hypothèse par défaut : la page est claire. Le navigateur dessine donc sa flèche gris foncé, sûr qu'elle contrastera bien avec le fond blanc que vous n'avez pas. La liste d'options s'ouvre en panneau blanc sortant de votre select couleur de minuit. Le calendrier arrive comme une lampe torche. Rien de tout cela n'est un bogue d'affichage. Le navigateur répond à une question que votre page n'a jamais posée : sur quel type de fond suis-je ?

Répondez à la question : color-scheme

La réponse tient en une déclaration CSS : color-scheme. Mettez-la à dark sur une page sombre et le navigateur repeint sa moitié de chaque contrôle pour l'assortir. La flèche s'éclaircit, la liste d'options s'assombrit, le calendrier et les barres de défilement suivent. Elle fait plus par caractère que presque tout le reste du CSS d'un thème sombre, et c'est l'une des lignes qui manquent le plus souvent, parce que tout a l'air bien sans elle sur la seule machine où le thème a été construit.

Délimitez-la honnêtement. Un site entièrement sombre la déclare à la racine. Un site clair avec un pied de page sombre la déclare sur le pied seulement, puisque la propriété s'applique là où vous la posez, et le navigateur affichera alors des contrôles clairs dans la moitié claire de la page et des contrôles sombres dans la moitié sombre. La déclaration est une affirmation de fait sur vos arrière-plans. Faites-la partout où le fait est vrai et nulle part où il ne l'est pas.

Les restes qui vous appartiennent encore

Le remplissage automatique est le reste le plus tranchant. Les navigateurs inondent un champ rempli de leur propre couleur de surbrillance, un jaune pâle ou un bleu pâle réglé pour des pages claires, et ils gardent jalousement cette couleur. Votre texte blanc de formulaire sur cette inondation pâle est illisible, et cela arrive précisément à vos visiteurs les plus efficaces : ceux dont le navigateur connaissait déjà toutes les réponses.

Il existe des échappatoires CSS. Le vrai point est que personne ne les applique à un problème qu'il n'a pas vu se produire, alors remplissez automatiquement votre propre formulaire sombre et regardez.

Deux restes plus discrets. Le texte des placeholders s'affiche dans un gris réglé contre du blanc, et sur un fond sombre il peut glisser sous le plancher de contraste que fixent les normes d'accessibilité, alors mesurez-le comme n'importe quel texte (et gardez-en une indication plutôt qu'un libellé, comme dit plus tôt dans cette série).

Et l'anneau de focus du clavier, dont le contraste était garanti sur blanc, peut disparaître tout à fait sur sombre. Un utilisateur au clavier qui tabule dans un formulaire sombre avec un indicateur de focus invisible est perdu d'une façon qu'aucun utilisateur à la souris ne reproduira jamais. Un style de focus personnalisé visible est livré avec le thème, pas après la plainte.

Un avertissement sur le correctif tentant. Supprimer entièrement l'apparence native et reconstruire le contrôle achète une autorité visuelle totale au prix d'une obligation à vie : vous devez désormais la flèche, les états et leur contraste sur chaque système d'exploitation, pour toujours. Et un select reconstruit en div stylés renonce au comportement clavier et à la sémantique pour lecteurs d'écran que le contrôle natif apportait gratuitement. Restylez d'abord le contrôle natif. Ne reconstruisez que lorsqu'une vraie exigence l'impose, et une couleur n'est pas une vraie exigence.

Testez sur la machine que vous n'avez pas

L'audit ici est une matrice, pas un coup d'œil : l'autre système d'exploitation, ses deux modes clair et sombre (les contrôles natifs suivent l'humeur du système autant que votre CSS), une passe au clavier seul, une passe au remplissage automatique. Vingt minutes, la plupart à emprunter l'ordinateur portable d'un collègue. Les bogues de cet article vivent exclusivement dans les combinaisons que votre équipe n'utilise pas personnellement, ce qui est précisément la façon dont ils ont été livrés.

La suite de la série : l'autre chose que les formulaires attirent en plus des visiteurs. Bloquer le spam sans CAPTCHA, ou comment renvoyer les robots sans interroger d'abord chaque humain.