Insights · Getting forms right · 5 minutes
Native Controls on a Dark Theme
Every native form control is painted by two hands: your stylesheet and the visitor's browser. On a dark background the browser's half keeps painting for a light page. The invisible dropdown arrow, the blinding calendar, the autofill flood, and the one line of CSS that fixes most of it.
The arrow that only renders on the designer's Mac
A dark theme makes it through review the same way every problem in this series has: on the machines the team owns. The comps look sharp, the dark footer with the newsletter signup looks sharper, and everyone approving it is on the same operating system, the same browser, and the same display the designer used. Then a visitor on a Windows machine goes to open the topic dropdown. Or tries to, because the arrow that says 'this is a dropdown' is being drawn in dark gray, by the browser, on your near-black background. What they see is a mute rectangle.
Nobody files a bug, because nobody can name one. The form isn't broken; it just looked finished before it was. Dark themes have a failure mode that light themes never taught anyone to check for: parts of a form are not yours to style, and those parts assume a light page until told otherwise.
Two hands paint every control
Your CSS controls the parts of a field it has always controlled: the box, the border, the text, the background. But a native control has parts the page never touches. The select's arrow, and the options list that opens beneath it. The calendar a date field summons. The checkbox's checkmark. The scrollbar inside a long textarea. The clear buttons and password-reveal eyes some browsers add on their own. Those are painted by the browser and the operating system, from their own palette.
And that palette carries a default assumption: the page is light. So the browser draws its dark-gray arrow, confident it will contrast nicely with the white background you don't have. The options list opens as a white panel out of your midnight select. The calendar arrives like a flashlight. None of this is a rendering bug. The browser is answering a question your page never answered: what kind of background am I sitting on?
Answer the question: color-scheme
The answer is one CSS declaration: color-scheme. Set it to dark on a dark page and the browser repaints its half of every control to match. The arrow lightens, the options list goes dark, the calendar and the scrollbars follow. It does more per character than almost anything else in dark-theme CSS, and it's among the most commonly missing lines, because everything looks fine without it on the one machine where the theme was built.
Scope it honestly. A fully dark site declares it at the root. A light site with a dark footer declares it on the footer alone, since the property applies wherever you set it, and the browser will then render light controls in the light half of the page and dark controls in the dark half. The declaration is a statement of fact about your backgrounds. Make it everywhere the fact is true and nowhere it isn't.
The leftovers you still own
Autofill is the sharpest leftover. Browsers flood a filled field with their own highlight color, a pale yellow or pale blue tuned for light pages, and they guard that color jealously. Your white form text on that pale flood is unreadable, and it happens precisely to your most efficient visitors: the ones whose browser already knew all the answers. There are CSS escapes for it. The real point is that nobody applies them to a problem they haven't watched happen, so autofill your own dark form and look.
Two quieter leftovers. Placeholder text renders in a gray that was tuned against white, and on a dark ground it can slide below the contrast floor accessibility standards set, so measure it like any other text (and keep it a hint rather than a label, per earlier in this series). And the keyboard focus ring, which had guaranteed contrast on white, can vanish outright on dark. A keyboard user tabbing through a dark form with an invisible focus indicator is lost in a way no mouse user will ever reproduce. A visible custom focus style ships with the theme, not after the complaint.
One warning about the tempting fix. Stripping the native appearance entirely and rebuilding the control buys total visual authority at the price of a lifetime obligation: you now owe the arrow, the states, and their contrast on every operating system, forever. And a select rebuilt out of styled divs gives up the keyboard behavior and screen reader semantics the native control carried for free. Restyle the native control first. Rebuild only when a real requirement forces it, and a color is not a real requirement.
Test on the machine you don't own
The audit here is a matrix, not a glance: the other operating system, both of its light and dark modes (native controls follow the OS's mood as well as your CSS), one pass on keyboard only, one pass by autofill. Twenty minutes, most of it spent borrowing a colleague's laptop. The bugs in this article live exclusively in the combinations your team doesn't personally use, which is precisely how they shipped.
Next in the series: the other thing forms attract besides visitors. Stopping spam without a CAPTCHA, or how to turn away the bots without interrogating every human first.