DSG-08

Form control in a color that doesn't match the background

InfoAccessibility

What the check measures

The check asks two things at once. First: is the page dark? (the luminance of the <body> background is computed; below a threshold it counts as dark). Then: does the document declare that it supports a dark scheme? (the color-scheme property on the root element).

When the page is dark but color-scheme says nothing about dark, the finding is raised for form controls the browser paints itself: selects, checkboxes and radio buttons. The report lists at most five.

Why those elements in particular: the browser decides their appearance and follows the declared colour scheme when doing so. On a dark page without a declaration it paints them in the light variant: a white checkbox on a dark background, a light dropdown in an otherwise dark form.

What the check does not do: it does not measure those elements' actual contrast (that is COLOR-01), it cannot recognise a page that handles dark mode with its own styles and no declaration, and it cannot see elements with fully custom appearance. The finding is page-level and informational.

How strong the evidence is

Effect not demonstrated

We recommend it because it does no harm or has some other benefit, but we promise nothing about whether it makes language models cite you. Nobody has demonstrated that yet.

For visibility in AI answers there is no effect at all. It is a visual detail, but one visible at first glance that reads as unfinished work.

What color-scheme actually does is well documented: it tells the browser which colour schemes the page supports, and the browser paints the elements it controls accordingly: form fields, scrollbars, the default background colour. Without a declaration it assumes a light scheme.

Why we mark it only as information and not a defect: because it affects neither function nor the legibility of content, only the appearance of controls. And because a page may handle dark mode with its own styles thoroughly enough to trip our heuristic undeservedly.

Where it is still worth fixing: it is one line of CSS. The cheapest fix in the whole design module, and it takes effect immediately, including scrollbars and built-in controls that manual styling tends to forget.

How to fix it

On a dark page, declaring the scheme is enough:

:root {
  color-scheme: dark;
}

And if the site supports both and follows the system setting:

:root {
  color-scheme: light dark;
}
  • The order in light dark sets the default for a browser that does not know the system preference.
  • The declaration also affects scrollbars and built-in controls, not just forms. That is the main reason it is worth having even on a site whose forms are styled with custom colours.
  • If the site has its own theme switch, set color-scheme from the chosen theme rather than hard-coding it. Otherwise a user switching to light gets dark form controls.
  • Do not confuse it with prefers-color-scheme. That is the query “what does the user want”; color-scheme is the answer “what can the page do”. You need both.

Verification is visual and quick: open a form on a dark page and look at a checkbox and a dropdown. If they glare white, the declaration is missing.

What the report says about it

Finding description

The page has a dark background but does not set `color-scheme: dark` (or `light dark`). Controls like `select`/checkboxes then often render in the operating system's default LIGHT style, which looks like a visual bug on a dark background.

Recommendation

Set the CSS property `color-scheme: dark` (or `light dark`, if the page supports both modes) on `<html>` or `<body>`. The browser will then render native controls in a matching style.

Sources

Text verified 2026-09-12