CSS accent-color: recolour native form controls in one line

accent-color recolours native checkboxes, radios, range sliders and progress bars in one line and keeps their accessibility. What it affects and its support.

CSS accent-color: recolour native form controls in one line

Native checkboxes and radio buttons were the last part of a form that refused to match the brand. The usual answer was to hide the control and redraw it with pseudo-elements, which cost a few dozen lines of CSS and, more than once, the keyboard and screen-reader behaviour that came with the real control. The accent-color property replaces all of that with one declaration.

One line

:root {
  accent-color: #1d4ed8;
}

That is enough to recolour every checkbox, radio button, range slider and progress bar on the page. The browser keeps drawing the native control and only swaps the accent: the fill of a checked box, the dot of a radio, the thumb and track of a slider, the bar of a progress element. It also chooses a contrasting colour for the check mark on its own, so a dark accent gets a white tick and a pale one gets a dark tick.

Per control, per state

input[type="checkbox"],
input[type="radio"] { accent-color: #1d4ed8; }

input[type="range"] { accent-color: #15803d; }

progress { accent-color: #b45309; }

/* an invalid required checkbox, e.g. unaccepted terms */
input[type="checkbox"]:user-invalid { accent-color: #b91c1c; }

Because it is an ordinary CSS property, it inherits, cascades and responds to selectors like any other. A form inside a danger zone of the page can carry a red accent while the rest of the site stays blue, with no extra markup.

Dark mode

:root {
  color-scheme: light dark;
  accent-color: light-dark(#1d4ed8, #7aa2ff);
}

Set color-scheme so the control's own frame follows the theme, then give the accent a light and a dark value. The two properties together make native form controls look designed in both themes without touching their internals.

What it does not do

  • It does not style text inputs, selects, textareas or buttons. Those take regular CSS.
  • It does not change the control's shape or size. If the design calls for a custom look, the appearance: none route is still the way, and it is still the route that costs you accessibility work.
  • It does not affect the focus ring. That stays the platform's, which is what you want.

Browser support, honestly

This is the part the short version of this article got wrong. Chrome 93, Edge 93 and Firefox 92 shipped accent-color in 2021 on desktop, and Safari only added it in version 26.2. Chrome for Android does not implement it, which keeps the property at Baseline limited availability as of October 2026. In practice that is not a problem, because the fallback is the default control colour: a browser that ignores the property shows exactly what it showed before. Use it everywhere, and treat the matching colour as progressive enhancement rather than a guarantee.

Reference: accent-color on MDN and its Web Platform Status entry.

Frequently asked questions

Which controls does accent-color affect?

Checkboxes, radio buttons, range sliders and progress bars. Text inputs, selects and buttons are not affected; style those with normal CSS.

Is accent-color supported in all browsers?

Not yet in every one. Chrome 93, Edge 93 and Firefox 92 support it on desktop, Safari added it in version 26.2, and Chrome for Android does not implement it, which keeps it at Baseline limited availability.

Does accent-color break accessibility?

No. The browser keeps the native control, its keyboard behaviour and its focus ring, and picks a contrasting colour for the check mark automatically.