accent-color: Coloring Form Controls Without JavaScript

1. The core problem: native form controls ignore the brand color

Every browser ships its own default rendering for checkboxes, radio buttons, range sliders and progress bars, and none of those defaults were designed with any particular brand color in mind. Chrome draws a checked checkbox in a system typical blue, Firefox does it slightly differently, Safari differently again, and none of those blues happens to match a project's corporate design. Before accent-color existed, achieving a consistent look meant hiding the native checkbox with appearance: none and rebuilding it entirely from scratch, including the focus ring, the checkmark icon and keyboard control.

That rebuild work was error prone because native semantics are easy to lose. A hand built checkbox icon does not automatically react to :indeterminate, the focus ring has to be rebuilt by hand, and screen readers interpret a purely visual construct differently from a real input type checkbox. The accent-color CSS property solves exactly this problem by simply telling the browser which accent color to use for its built in rendering, while the complete native logic, keyboard control and accessibility stay untouched.

2. Syntax and basics of accent-color

The syntax of accent-color is deliberately simple: a color value, applied to a form control or a parent container, colors the checked state rendering of that element. The value can be any valid CSS color, hex, RGB, HSL or an oklch() value, and the browser automatically figures out how that color translates into the native rendering style, including hover and focus states. The special value auto resets back to the system default, which is handy when a global rule needs to be undone for individual elements.

Importantly, accent-color inherits. Setting the property on :root or a form element automatically colors every checkbox, radio, range slider and progress bar inside it, without addressing each element individually. That turns accent-color into a real theming tool: a single custom property on the root element, and a complete form consistently picks up the brand color.

/* Global accent color for the entire document */
:root {
  accent-color: #7c3aed;
}

/* Reset a single group back to browser default */
.legacy-form input[type="checkbox"] {
  accent-color: auto;
}

/* accent-color accepts any valid CSS color, including custom properties */
.form-section {
  --brand-accent: oklch(58% 0.22 293);
  accent-color: var(--brand-accent);
}

3. Coloring checkboxes and radio buttons precisely

Checkboxes and radio buttons are where accent-color has the biggest impact, because these two controls appear in almost every form and, in most projects, were never styled at all before. A single rule on input type checkbox and input type radio is enough to make the background color, border color and checkmark symbol in the checked state consistent with the brand color, without touching size, click target or keyboard navigation.

A detail that is often overlooked: accent-color also adjusts the indeterminate state of checkboxes, the one seen in select all checkboxes in tables with a partial selection. That state used to be one of the hardest to get right when rebuilding checkboxes manually, because indeterminate has to be set via JavaScript and many hand built checkbox components simply forget it exists. With accent-color, the browser handles that logic automatically.

/* Consistent brand color across the whole checkbox and radio family */
input[type="checkbox"],
input[type="radio"] {
  accent-color: #7c3aed;
  width: 1.15rem;
  height: 1.15rem;
  cursor: pointer;
}

/* Per-context override: danger checkboxes in a delete confirmation */
.danger-zone input[type="checkbox"] {
  accent-color: #dc2626;
}

/* accent-color also styles the indeterminate state automatically */
table thead input[type="checkbox"]:indeterminate {
  /* no extra rule needed, the browser reuses accent-color here */
}

4. accent-color on range inputs and progress elements

Besides checkboxes and radios, accent-color also affects input type range and the progress element, although with some browser specific details. On a range slider, accent-color typically colors the filled part of the track up to the thumb, while the unfilled part stays in the neutral system color. On progress, accent-color takes over the color of the advancing bar, which for loading indicators and upload progress is a fast way to align the progress bar with the rest of the interface.

The decisive advantage over a fully custom built range slider remains native semantics here too: arrow keys, page up and page down, home and end work automatically, the ARIA value range is correctly communicated to screen readers, and accent-color changes nothing about that functionality, it only adjusts the visual presentation. Anyone who needs more visual control over a range slider, say a custom thumb with a shadow or a striped track, combines accent-color with the pseudo element based selectors covered in detail in another article of this series.

/* Range slider: filled track takes the accent color automatically */
input[type="range"] {
  accent-color: #7c3aed;
  width: 100%;
}

/* Progress bar: the advancing fill uses accent-color, the track stays neutral */
progress {
  accent-color: #7c3aed;
  width: 100%;
  height: 0.75rem;
}

/* Different accent per severity level, same markup, no JS required */
progress.warning { accent-color: #f59e0b; }
progress.critical { accent-color: #dc2626; }

5. Working together with color-scheme and dark mode

A point that is easy to miss with accent-color: the color-scheme property affects how the browser renders the remaining parts of a form control that are not covered by accent-color, say the border of an unchecked checkbox or the track color of a range slider. If a page sets color-scheme: light dark, the browser automatically adapts those remaining colors to the active system theme, while accent-color keeps the brand color constant.

In practice this means: a project with light and dark mode usually does not need two different accent-color values, just a single, sufficiently high contrast brand color that works in both modes, combined with color-scheme for the native remaining rendering. Anyone who still wants a different nuance per mode, say a lighter variant of the brand color for dark mode, defines the color through a custom property and overrides it inside a prefers-color-scheme media query.

/* Let the browser adapt native chrome (borders, unfilled track) to the theme */
:root {
  color-scheme: light dark;
  --brand-accent: #7c3aed;
  accent-color: var(--brand-accent);
}

@media (prefers-color-scheme: dark) {
  :root {
    /* Slightly lighter accent for better contrast on dark backgrounds */
    --brand-accent: #c4b5fd;
  }
}

6. Contrast and accessibility: the limits of accent-color

As convenient as accent-color is, it does not replace a contrast check. The browser does automatically compute a matching checkmark or dot color relative to the chosen accent color, but that automatic computation does not guarantee that the overall contrast between element and background meets WCAG requirements. Anyone using a very light brand color as accent-color on a light form background risks a checkbox whose checked state is barely distinguishable from its unchecked state, particularly for users with limited vision.

The practical recommendation: always check accent-color values with a contrast calculator against the expected form background, at least 3 to 1 for non text UI components under WCAG 2.1 criterion 1.4.11. It is also worth testing with forced colors or Windows high contrast mode enabled, because some operating systems ignore accent-color in that mode and fall back to system wide contrast colors, which makes an additional textual or icon based signal necessary for forms that rely purely on color coded status, say green for valid and red for invalid.

7. Fallback strategies for unsupported browsers

accent-color has been supported by all current browsers since 2021 and 2022, Chrome from version 93, Firefox from 92, Safari from 15.4. For projects that still need to support older browsers, accent-color is an ideal example of progressive enhancement: without support, the browser renders the default appearance, which stays fully functional, just not in the brand color. There is no layout break, no missing element, only a visual deviation that can be accepted in unsupported browsers.

Anyone who still wants to close that gap checks with @supports (accent-color: auto) whether the property is available, and only in the negative case loads a heavier custom checkbox solution. This strategy keeps the common case lean, since the vast majority of visitors use modern browsers, and reserves the extra effort for the minority where accent-color is actually missing.

/* Feature detection: only ship the heavy custom checkbox for unsupported browsers */
@supports not (accent-color: auto) {
  input[type="checkbox"] {
    appearance: none;
    background: white;
    border: 2px solid #7c3aed;
    border-radius: 0.25rem;
  }
  input[type="checkbox"]:checked {
    background: #7c3aed;
  }
}

@supports (accent-color: auto) {
  input[type="checkbox"] {
    accent-color: #7c3aed;
  }
}

8. Combining accent-color with Tailwind CSS

Tailwind CSS has supported accent-color directly since version 3.1 through the accent-* utility classes, say accent-violet-600, which automatically reference the configured theme colors. That lets an entire form area of an application be colored consistently without writing a separate CSS file, and without the utility classes undermining the native semantic advantage of accent-color, they generate exactly the same CSS property as a result.

For Hyva themes, which use Tailwind CSS as a CSS first approach, this is a direct replacement for many of the checkbox overrides previously required in Magento forms. A single global accent-violet-600 on the form wrapper is enough to color cart checkboxes, filter radios and checkout progress indicators consistently, entirely without the multi line appearance none constructs with background image icons that used to be common.

/* Tailwind utility approach, generates the same accent-color property */
<input type="checkbox" class="accent-violet-600 w-5 h-5">

/* Applied at the form container level, inherited by all children */
<form class="accent-violet-600">
  <input type="radio" name="shipping">
  <input type="range" min="0" max="100">
</form>

9. accent-color compared to fully custom widgets

Choosing between accent-color and a fully custom built form control depends on how much control is actually needed. For the vast majority of projects, where a consistent brand color is all that is wanted, accent-color is the clearly more robust and lower maintenance solution, because it leaves native behavior untouched.

For projects with a strongly individual design, say a custom checkmark icon in brand shape or a toggle switch instead of a classic checkbox, a full custom rebuild remains necessary. For all other cases, and in practice that is clearly more than half of all projects, accent-color is entirely sufficient to free forms from the gray default rendering.

10. Summary

accent-color solves a years old problem with minimal effort: a single CSS property colors checkboxes, radio buttons, range sliders and progress bars to match a brand, without changing native keyboard control, focus behavior or screen reader semantics. The property inherits, can be set globally on the root element and overridden precisely per section, say for warning colors in a delete confirmation.

What remains important is the contrast check, since the automatic computation of the checkmark color does not guarantee WCAG conformance, as well as the interplay with color-scheme for consistent dark mode rendering. Combined with Tailwind CSS through the accent-* utility classes, accent-color becomes one of the most efficient tools for integrating native form controls into a modern design system.

11. FAQ: accent-color for form controls