Allow specifying the "accent color" of a form control element

[chrishtr]

(not sure which spec this might apply to - css-color-adjust? css-color? css-pseudo?)

Form controls often have a themed highlight color that indicates a "selected" state. For example, in Chromium, we recently changed the look and feel to have a blue highlight color:

(Edge on Mac has similar styling to Chrome but does not use blue). This demo enumerates all of the form controls and can be tested on various browsers.

In addition, some operating systems, such as Mac OS X, allow changing the accent color via a user setting. Safari uses this setting to change the blue color in the screenshots above to a different color.

A number of developers have indicated that they would prefer to be able to change the color. See e.g. this issue. I propose a way to do this via CSS:

• A new css property accent-color that would take on the usual color values. We would specify that a user agent should use this color to change the accent color of a UA-rendered form control, if there is such a well-defined concept for that form control; and otherwise this property has no effect. In the various accessibility and forced color modes, this property is ignored.

In general, form control styling and rendering is not specified, but this particular part of it seems like it can be.

[AmeliaBR]

Is there a reason this can't be done via color alone? Would that currently break the modern OS appearance of the control?

[chrishtr]

Is there a reason this can't be done via color alone? Would that currently break the modern OS appearance of the control?

Two reasons:

• Possibly breaking existing sites
• color doesn't indicate what is being colored. For example, there are non-background strokes like borders or the fill color of a progress input, does color change those?

[fantasai]

Accent color isn't indicating what's being colored, either. I'd say if there isn't a compat restriction, @AmeliaBR's suggestion to re-use color here makes a fair amount of sense unless there's a need to indicate two different colors as input.

FWIW, the CSS UI spec used to say

If 'appearance' is not 'normal', the UA must render the element as if it was the specified user interface (UI) control from the platform. The UA should use the computed values of the 'background-', 'border-', 'padding-', 'outline-', and 'text-decoration' properties when they do not have their initial values and the computed values of 'color', 'font', and 'cursor' (whatever their values) to influence the rendering where possible. Any values from those properties that cannot be used to influence the rendering of the UI control must not affect the rendering at all. For example, the UA should not draw a second border around a UI control that already has a border. If 'background-color' or 'background-image' have non-initial values and the UA is using their values for influencing the rendering of the UI control, then the UA must ensure that the 'color' property is also used to influence the rendering.

That seems to have gotten lost along the way... //CC @tantek

[chrishtr]

Accent color isn't indicating what's being colored, either.

I think it is. It's more specific than color. Also, this is the terminology used in the settings app on Mac OS.

That seems to have gotten lost along the way... //CC @tantek

I see. We need to find out which commit removed it.

[mfreed7]

Is there a reason this can't be done via color alone? Would that currently break the modern OS appearance of the control?

I think the biggest downside to re-using color in this way is that it is non-specific. It would not allow you to, for example, change the text color to one thing, and the "accent" features to something else. Take, for example, the date picker:

<input type=date style="color: red">

which has a text display of the date, and (on some platforms) a picker icon or arrow. If we tie everything to color, the above <input> would have both red text and a red icon. In contrast, accent-color would be specific to just the "accents", allowing black text with a red picker icon, for example:

<input type=date style="color: black; accent-color: red;">

This would also be compatible with the existing Mac concept of an "Accent color", which affects control elements but not text colors. It would also be safe for web compat, since accent-color is a new CSS property.

[heycam]

I agree that tying this to color doesn't seem right.

A few questions that come to mind that I haven't given much thought to yet:

• On macOS, the system accent color affects how focus rings are rendered. Should accent-color be allowed to influence focus styling?
• Is there any relation to <meta name="theme-color">?
• Existing form control designs may be amenable to some accent colors but not others. For example, the Chrome checkbox design wouldn't work with accent-color: white unless the checkmark color changes in response. Is this anything to worry about, or is it sufficient to have some wording that encourages engines to ensure their designs can adapt to all choices of accent-color?
• Do we need to think about how a future form control styling mechanism would interact with accent-color? What about Web components that implement form controls, and which want to adapt their styling to the accent color?

[henke37]

An alternative would be to use pseudo elements to target the classic color property to specific parts of the form control. Naturally, this is not as generic as an accent color, but at the same time allows for detailed control of the color for individual parts.

This is not a mutually exclusive alternative, but interaction between the two would need to be clarified.

[chrishtr]

• On macOS, the system accent color affects how focus rings are rendered. Should accent-color be allowed to influence focus styling?

Focus rings can already be styled with CSS like :focus { outline: 5px solid orange }.

• Is there any relation to <meta name="theme-color">?

For some sites, yes, but I can also see them also wanting to choose a different color.

• Existing form control designs may be amenable to some accent colors but not others. For example, the Chrome checkbox design wouldn't work with accent-color: white unless the checkmark color changes in response. Is this anything to worry about, or is it sufficient to have some wording that encourages engines to ensure their designs can adapt to all choices of accent-color?

I think we should add the language you suggested.

• Do we need to think about how a future form control styling mechanism would interact with accent-color? What about Web components that implement form controls, and which want to adapt their styling to the accent color?

We could perhaps define a pseudo element on custom form controls that accent-color automatically applies to? That's kind of what the accent-color I am proposing conceptually does.

[henke37]

"A" pseudo element. As in One. That has one name, suitable for any form control? X to doubt. If form controls get pseudo elements, there should be as many as that form element needs. Not some generic one size fits all one.

One pseudo class that applies to the correct pseudo elements could work tho.

[othermaciej]

What's the intended scope of accent-color? Is it just color of the checked state of radio buttons and checkboxes? If so, then the name seems inappropriately broad. If it's more things than that, then that may shed light on the name, and whether it should all be one property.

[chrishtr]

Is it just color of the checked state of radio buttons and checkboxes?

Yes, something like that (or similar accents in other form elements).

[henke37]

"Something like that" and "or similar accents" are not phrases that belong in a standard. We need a clear definition of what "accent" means here, not vague hand waving.

[jensimmons]

How does this idea fit into the work of the Open UI project? @gregwhitworth ?

[gregwhitworth]

Windows also has the concept of an accent color on Windows 10. I'd recommend that this be a system color so that it can be leveraged in numerous places. As @chrishtr noted it's used in focus, but also can be used in the glyphs or other areas for form controls. I haven't looked at other use cases for this but the fact that Windows changes the title bars and other backgrounds to the accent color makes me think that it may be something that is allowed to be broad while allowing UAs to leverage it in our stylesheets for the specific scenario denoted by @chrishtr.

TLDR; I propose accent-color to be added to the CSS System Colors as a keyword

How does this idea fit into the work of the Open UI project? @gregwhitworth ?

While this was discovered due to form controls it doesn't have to do with defining behavior, anatomy, states and interactions between states so I think staying in the CSSWG makes the most sense. Shoutout to @heycam for pinging the Open UI discourse channel though :)

and thanks @jensimmons for thinking of us :)

[othermaciej]

@gregwhitworth I think the proposal here is to provide a way to set the accent color for a particular form control, not to use the system accent color (that may also separately be useful, but it also creates fingerprinting surface, which this proposal does not).

[mfreed7]

What's the intended scope of accent-color? Is it just color of the checked state of radio buttons and checkboxes? If so, then the name seems inappropriately broad. If it's more things than that, then that may shed light on the name, and whether it should all be one property.

Ideally, the accent-color property can be specified to apply to all form controls, as appropriate. The appearance and styling of form controls is (deliberately) not well-specified, so it might be tough to avoid somewhat vague language here. However, I think the concept is reasonable. For example, in Safari, the system Accent Color setting affects:

• The "background" color for <input type=checkbox>
• The "background" color for <input type=radio>
• The activation "button" for <select>
• The activation "button" for <input type=text list=datalist>
• The highlighted row of <select multiple>
• The active state of <button>

All of the above seem to make sense as a usage of the accent-color. In Chrome, I could also see adding to the above list:

• The shaded portion of the <range> control
• The clear ('X') button on several controls such as <input type=search>

Again, the idea is to control the currently-uncontrollable colors of form elements just a bit better. Our hope is that the more broad Open UI type improvements in stylability will give even better control over all pieces of these controls. But in the meantime, this accent-color proposal will alleviate many very real, very painful developer problems with the existing control styling.

[heycam]

The highlighted row of <select multiple>

On macOS Safari, this is rendered using the Highlight Color rather than the Accent Color. (By default the Highlight Color is a lighter or darker version of the Accent Color, but you can set it to a completely different color.)

[chrishtr]

"Something like that" and "or similar accents" are not phrases that belong in a standard. We need a clear definition of what "accent" means here, not vague hand waving.

Yes, I'm aware of that. No need to talk down.

However, each user agent has their own default form control styling, so the specification of this property will need to be higher level than specific DOM elements.

[othermaciej]

However, each user agent has their own default form control styling, so the specification of this property will need to be higher level than specific DOM elements.

Going over how this might apply to rendering of a wider range of controls as in this comment might help us understand if all of this coming through one property makes sense. For example, Cameron noticed the highlight color vs accent color issue.

It might help to be even more exhaustive in considering the full range of form controls. For example, one thing to consider is the <input type=number> stepper button.

There are also colored pieces of form controls that do not normally follow the OS accent color. We probably want to avoid including those. Rationale: since accent color is likely to be desirable set across a whole site, that is the common use of similar functionality in apps. So it would be tempting to set it as a rule on *, but we wouldn't want unexpected parts of a form control to recolor.

[gregwhitworth]

@othermaciej ahhh my bad - completely mis-read the issue :/ I'll avoid the fingerprinting discussion given this is about a different proposal altogether.

There are also colored pieces of form controls that do not normally follow the OS accent color. We probably want to avoid including those. Rationale: since accent color is likely to be desirable set across a whole site, that is the common use of similar functionality in apps. So it would be tempting to set it as a rule on *, but we wouldn't want unexpected parts of a form control to recolor.

LOL, I was just writing something similar. I agree that we should scope this in if it's solely focusing on form controls. Also, regarding the stepper buttons on number I think it's fine to still allow them on any replaced form control as in the future a UA may use the accent-color on the steppers or some other part that isn't currently exposed. Outside of that, if this is a common enough pain point now to add this to the platform then I am fine with this proposal as long as we scope and name it accordingly. How about form-control-accent-color?

[css-meeting-bot]

The CSS Working Group just discussed Allow specifying the "accent color" of a form control element.

The full IRC log of that discussion

<dael> TOpic: Allow specifying the "accent color" of a form control element
<dael> github: https://github.com//issues/5187
<dael> chrishtr: Form controls are styled and painted in UA specific way in all browsers
<dael> chrishtr: There tends to be a concept of an accent color used to indiacte checked or marked state of form controls.
<dael> chrishtr: UAs pick a default color for that that's consistent in page. There are also OS settings on some OSs to change accepnt color which is respected by some browsers.
<dael> chrishtr: COlor might conflict with brand of site, like site with orange theme but checkboxes are blue
<dael> chrishtr: Proposal is to ahve css property which says form controls should use this color as basis of accent color when painting form control
<dael> Rossen_: Opinions on this?
<tantek> the other big use-case is for sites that want to make "darker" versions of form controls that match their site styling, similar to scrollbar colors
<hober> q?
<dael> fantasai: Main concern is it's not clear what accent color is used for. B/c that it's nto clear what's expected contrast between that, text, and background.
<tantek> +1 agree with fantasai, needs to be predictably specified so it makes sense across OSs and devices
<dael> fantasai: Concern people will choose colors that are good on some OS but won't contrast with background enough in other rows. For example a select multiple it needs to contrast with text. But on a selected checkmark it's background
<dael> fantasai: Understand what you're trying to do but concerned we won't get something robust across browsers
<tantek> needs to be sufficiently predictable across browsers
<dael> florian: Can we split into foreground and background or does that not generalize well
<dael> myles: We had internal discussion and general feeling is good for web in general. Not sure mech to expose. We have a general idea good to style lots of form control aspects. Good to do in general not just one piece. In general feel this has value for web.
<tantek> +1 myles that's a good summary
<fantasai> tantek, that use case is handled by the 'color-scheme' property fwiw
<fantasai> tantek, https://www.w3.org/TR/css-color-adjust-1/#preferred
<dael> chrishtr: Re: general styling point. Agree that there are other things devs wish to style and hopefully can. This one seems to be simple and common and immediately solves a specific conern. THat's why I think do it as a one-off for the moment and general in future
<Rossen_> q?
<jensimmons> q+
<tantek> fantasai, not talking about not dark mode. hence I said darker deliberately
<hober> q?
<dael> florian: General will take time. Seems most of time accent color is related to backgrou,d but not always. If it's background or foreground matters. Having the pair would be a step which could make sense. There can be many aspects of form control we can do later. Knowing if your'e in foreground or background matters.
<dael> heycam: Ignoring select multiple issue which might nto be accent color all other colros are contrasting separately. For checkbox and radio you'd got icon inside which authors can't control. I think for most cases where accent color can be changed any contrasting color can be painted by UA.
<dael> jensimmons: Has anyone working on open UI on the call? I know a lot of work has gone into form controls and what it means to style them
<dael> myles: On iOS there's no concept of the accent colors. Whatever is in spec needs affordences for OS where it doesn't apply
<Rossen_> q?
<Rossen_> ack jensimmons
<dael> florian: If we look at range of historical OS to get diversity the buttons were a shade of blue. If that was still the fashion accent color wold be there and it's very background-y
<florian> https://66.media.tumblr.com/e0c02215356306ee52298451ac25685e/tumblr_o5a0h4UIDN1v0jfsto2_1280.png
<florian> http://pcdesktops.emuunlim.com/pictures/skins/wb/macosx-aqua-bjb.gif
<dael> chirsh: Answering jensimmons, I'm working with gregwhitworth and others on longer term project for form controls. I don't know if enought o discuss here. In general I think compat. I don't think enough to say about OpenUI to clarify
<dael> Rossen_: Is there a resolution you're looking for?
<dael> chrishtr: I'm hoping to get to agreement on name and set of text what's it's supposed to be for UA and says UA should make sure sufficent contrast and only where it makes sense
<dael> fantasai: Fine to try and draft language. Requires more release to make so it works on a variety of OSs. I'm a little skeptical this will work but understand we want it. I'm concerned about having it work for all OSs.
<dael> fantasai: If we can show that would be the case across current and past OSs and there's a reasonable interpretation for all the OS/browser combos I would feel more comfortable moving forward
<jensimmons> +1 to what fantasai said
<dael> chrishtr: Hearing general support but need mroe research to understand compat as well as foreground/background comments
<dael> fantasai: I think we should do that evaluation in GH. Might be right design, but might be diversity of form controls requires something different.
<tantek> we're also looking preliminarily at a more longer term project for form controls as well, if existing work is happening in the open, please share that in CSSWG! Thanks!
<dael> chrishtr: We'll come back with more concrete proposal
<dael> florian: What I'd liekt os ee in research is wide variety of form control and show form controls is always background or neither. If it's in foreground sometimes we need to split it up.

[mfreed7]

Per the action items from the CSSWG meeting, I have worked through these two action items:

1. Study/enumerate the various places where accent-color might apply, across form elements, platforms, and browsers.
2. Propose spec text for the ‘accent-color’ property.

Additionally, I gave some thought to the foreground/background color issue brought up by @frivoal.

I've collected the results in this shared doc:

https://docs.google.com/document/d/1yHQUshdC3hKrDRG-xDtUPYVIcc_JNUglK0KMVoqRyCo

I disabled comments on the doc, but I would love to hear feedback, so please add your comments back here in this issue thread.

[hwikyounglee]

https://docs.google.com/document/d/1yHQUshdC3hKrDRG-xDtUPYVIcc_JNUglK0KMVoqRyCo

a clarification question for @mfreed7: Is there an assumption that there would be granularity options to apply the colors from all UA-chosen form controls to a single element chosen by the developer? Or would the granularity need to be just all UA-chosen controls?

[mfreed7]

a clarification question for @mfreed7: Is there an assumption that there would be granularity options to apply the colors from all UA-chosen form controls to a single element chosen by the developer? Or would the granularity need to be just all UA-chosen controls?

Thanks for the question. This is a proposed new CSS property, which can be applied with full CSS granularity, down to individual elements. So:

input[type=text].group1 {
  accent-color-foreground: blue;
}
#myelement {
  accent-color-background: red;
}

[chrishtr]

Agenda+ to discuss a resolution regarding the general shape of the spec approach Mason listed in his doc.

[heycam]

Regarding separate accent foreground and background colors, are there existing form control designs where the two colors can be independently chosen? Or is it just that the accent foreground color is chosen automatically based on the background? For example, on macOS you can select the accent background color from a specified set of colors, but the foreground color is chosen automatically (it's white, unless the highlight color is "Graphite" then it's black). I'm not convinced we really need the two separate properties, as opposed to having requirements that, if they do honor accent-color, implementations must do so in a way that does not cause contrast issues.

[mfreed7]

Ok, at the last teleconference, there was significant discussion about encouraging interoperability while not constraining innovation, and the inherent conflict therein. I also heard a suggestion from @astearns that it might help to include more prose explaining the motivation and intent for the spec, because it will aid in interpreting the specification. So I've gone ahead and done that - please see the new section of the proposal. I also copied it inline below.

Separately, I heard a recommendation that separate issues be opened for the sub-questions being debated here:

1. Should we go forward with accent-color? This was resolved yesterday.
2. Should we constrain browser vendor innovation of form control elements? I have not heard anyone argue that we should, so I'm going to just take it as a given that we shouldn't.
3. Should interoperability be a goal for the accent-color spec? I filed an issue for this question.

While there are additional issues, I think #3 is a key question. A decision there will guide the rest of the process.

Here is a copy/paste from the new proposal section:

---

Motivation and Intent

This section is non-normative.

In implementing accent-color, there are two competing/conflicting goals:

1. Encourage interoperability among browsers. It is important that developers be able to expect similar, if not the same, behavior across browsers.
2. Encourage (and do not constrain) browser vendors' innovation of form control elements.

The goal of interoperability pushes this solution towards a more strict specification of exactly how to use each accent-color value on each form control element. However, the goal of allowing innovation pushes this solution away from strict specifications for how each form control looks or acts. This specification attempts to provide a good middle ground, which maximizes interoperability while minimizing constraints to innovation.

The general methodology for achieving the above compromise is to examine the set of existing form control elements (as of 2020), and agree on the basics of the way accent-color is applied to each of those existing controls. It is explicitly recognized that each browser provides different implementations of each form control, with their own look and feel. This spec does not try to eliminate those differences. However, it does try to provide some level of uniformity and interoperability, where commonalities exist.

This will require judgement when applying the recommendations to new or existing form controls. The goal would be to adhere to the spirit of this spec as much as possible. For example, if the guidance states that an accent-color value should apply to a particular accent part, and the browser implementation of that part uses a gradient fill rather than a single color, then there may be multiple ways to "use" the accent-color value to affect the gradient rendering of that part. The goal would be to match the guidance where it makes sense, and when possible. That might mean replacing the gradient with a solid fill, or it might mean changing the endpoint values of the gradient to match the accent-color value in aggregate. Or it might mean another behavior entirely. The point is that the guidance should be consulted and used as input in determining how to proceed.

Further, this spec is careful to not require exact conformance of each form control with the accent-color spec. It merely encourages browsers to follow the guidance for form controls elements that are "close enough" to the existing set of controls. For brand new paradigms, input surfaces, control types, etc., this spec does not attempt to limit innovation. If there are similar parts of these new-paradigm controls, then as much as possible/reasonable, those parts should be guided by this spec. But this should not be seen as any limitation on innovation.

To assist in characterizing "close enough" as it relates to the accent parts of form control elements, the Existing Control Examples section of this document includes many examples of several control types, pulled from different browsers, operating systems, and time periods. Except where noted, each of the control examples within each group should be considered "close enough" to the group that the guidance for that group should apply.

[mfreed7]

I've just closed the "interoperability" issue that I opened, as it didn't help move the conversation forward as I had hoped. It actually seems to have somewhat derailed it, and that's likely my fault. The big conclusion I took from that discussion was that my proposal bites off too much, and most people seem to agree that accent-color should be less about "full control" of colors, and (as @samuelbradshaw nicely puts it) more about "dusting" the existing controls with a color. In other words, accent-color seems like a good fit for the "I want to change the theme and ensure contrast / readability, but don't necessarily need to control form UX so tightly", and not a good fit for "I want to make sure my form control looks exactly this way". Other technology is better for the latter. And in this context, interoperability can take the form of "achieves the intended purpose reliably across browsers" as opposed to "generates the same pixels across browsers".

As such, I think we should consider other proposals for the accent-color feature. In particular, @fantasai has made several such proposals (e.g. 1 and 2), and we should consider those and any others.

[chrishtr]

Agenda+ to discuss the specific proposals mentioned in Mason's second paragraph, or the version Brad suggested here.

Those approaches sound workable to me, and likely compatible with a wide range of form control UX designs.

[css-meeting-bot]

The CSS Working Group just discussed accent-color, and agreed to the following:

• RESOLVED: adopt accent-color as a hint to the UA, with requirements on contrast
• RESOLVED: Mason Freed added as UI 4 editor

The full IRC log of that discussion

<astearns> topic: accent-color
<TabAtkins> masonfreed: Summary is I closed the "interopability thread" - question I was trying to ask was whether we wanted precise control over where accent colors should go on a control
<TabAtkins> masonfreed: Think I got the answer I needed - we dont' want to do so.
<astearns> github: https://github.com//issues/5187
<TabAtkins> masonfreed: Majority opinion seems to be that we want this to be more of a hint to the UA - "accent-color: purple" means "use purple on this control if you can if it makes sense".
<TabAtkins> masonfreed: Not "put this purple on the checkbox background", more of a hint instead
<Rossen_> q
<TabAtkins> masonfreed: So I'd like to get a reoslution from the grou pon this direction
<TabAtkins> q+
<jensimmons> q+
<fantasai> sgtm
<florian> q+
<Rossen_> ack TabAtkins
<fantasai> TabAtkins: I'm not sure this is exactly the right direction, fine with it as long as we adopt something like what fantasai said, where we require the UA's chosen colors contrast appropriately with the accent-color
<fantasai> TabAtkins: UA can't put black on black ifyou specify accent-color:black
<fantasai> TabAtkins: With that, sounds fine
<fantasai> Rossen_: you can't ignore the accent color?
<fantasai> fantasai: can always ignore it...
<TabAtkins> jensimmons: I think how Mason described it is good and realistic
<Rossen_> ack jensimmons
<fantasai> jensimmons: I think the way Mason described is really good, more realistic to where we are
<fantasai> jensimmons: more time to solve the problem of robus styling
<TabAtkins> jensimmons: Allows us to give authors something useful and gives us time to solve the problems more robustly
<TabAtkins> florian: Roughly in line with all that. As long as the hint involves the requirement that contrast must work.
<TabAtkins> florian: Don't think we have a resolution on one vs many colors, but we can decide that later
<Rossen_> acj florian
<TabAtkins> florian: I think there is an appetite for precise control, but that requires a more robust solution. Should od that too, but shouldn't conflate with this.
<Rossen_> ack florian
<TabAtkins> Rossen_: Taking the lack of queue as meaning we've said everything we need. Objections?
<TabAtkins> proposed resolution: adopt accent-color as a hint to the UA, with requirements on contrast
<tantek> I think we're ok with that too
<TabAtkins> RESOLVED: adopt accent-color as a hint to the UA, with requirements on contrast
<TabAtkins> masonfreed: We probably need to discuss the 1 vs many colors question later
<TabAtkins> Rossen_: yes
<TabAtkins> fantasai: I think we should put this into UI 4, should we let the editors put that in, and discuss 1 vs many colors separately?
<TabAtkins> astearns: Would Mason like to become an editor?
<TabAtkins> masonfreed: "want" is strong, but I'm willing to do it
<TabAtkins> florian: Happy to have help
<TabAtkins> fantasai: There is proposed text already
<TabAtkins> Rossen_: Objections to adding Mason as UI 4 editor?
<TabAtkins> RESOLVED: Mason Freed added as UI 4 editor

[fantasai]

CSS 'accent-color' Proposed Text

Drafted by Mason Freed, 11 September 2020

Revised by fantasai, 7 October 2020

As discussed on CSSWG Issue 5187, and at the July 1, 2020, July 22, 2020, August 19, 2020, and August 26, 2020 CSSWG meetings,
there is a desire to expand the stylability of form control elements,
in particular by allowing the specification of the “accent color” for various elements.

This proposal is a result of those discussions.

Motivation and Intent

In implementing accent-color, there are two competing/conflicting goals:

1. Encourage interoperability among browsers.
   It is important that developers be able to expect similar, if not the same,
   behavior across browsers,
   and most critically, to get usable results on all browsers and platforms
   now and in the future.
2. Encourage (and do not constrain) vendors’ innovation
   of form control elements.

The goal of interoperability pushes this solution
towards a more strict specification of exactly how
to use each accent-color value on each form control element.
However, the goal of allowing innovation pushes this solution
away from strict specifications for how each form control looks or acts.
This specification attempts to provide a good middle ground,
maximizing necessary interoperability while minimizing constraints to innovation.

The general methodology for achieving the above compromise
is to examine the set of existing form control elements
(as of 2020),
and agree on where and how an accent color is considered to have been applied
to each of those existing controls,
and define that those uses of color are replaced by the specified accent-color.
It is explicitly recognized that each browser
provides different implementations of each form control,
with their own look and feel.
This spec does not try to eliminate those differences.

This will require judgement when applying the recommendations
to new or existing form controls.
The goal is to adhere to the spirit of the feature as much as possible.
For example, if the specification requires
that an accent-color value should apply to a particular accent part,
and the browser implementation of that part
uses a gradient fill rather than a single color,
then there may be multiple ways to “use” the accent-color value
to affect the rendering of that part.
It might mean replacing the gradient with a solid fill,
or it might mean changing the endpoint values of the gradient
to match the accent-color value in aggregate.
Or it might mean another behavior entirely.
Non-normative examples and guidance are provided
as input to help the UA determine how to interpret accent-color
as appropriate to its own platform and implementation.

Proposed Spec Text

<pre class=propdef>
Name: accent-color
Value: auto | <<color>>
Initial: ''auto''
Applies to: all elements
Inherited: yes
Percentages: N/A
Computed value: computed color
Canonical order: per grammar
Animation type: by computed value type
</pre>

User interface controls on any given platform are typically designed as a cohesive set,
under a single, cohesive visual style.
On many platforms (though not all),
the visual style includes the use of an <dfn>accent color</dfn>,
a typically bright color that contrasts markedly
with the more utilitarian background and foreground colors.
Not every control uses the [=accent color=] in every state,
but it is nonetheless a core part of the controls’ color scheme.

The 'accent-color' CSS property allows the author to specify the [=accent color=]
for user-interface controls represented by the element.
An <dfn for=accent-color value>auto</dfn> value represents a UA-chosen color,
which should match the [=accent color=] of the platform, if any.
A <dfn for=accent-color value><<color>></dfn> value
specifies that color as the desired [=accent color=].

The UA should use the 'accent-color'
to draw whichever parts of the form control
would have otherwise been styled with an [=accent color=].
The UA may adjust the luminance or brightness of the color
or make color substitutions in other parts of the control
(e.g. switching an overlaid glyph from using 'color' to using 'background-color'),
as necessary to maintain contrast for legibility of the control,
and may generate variations of the color for gradients etc.
and to match the control to platform conventions for the use of the accent color.

For example ...

Examples

This section is non-normative.

<input type=checkbox>

A checkbox is typically composed of a square,
potentially overlaid by a “checkmark” glyph representing the checked state.

Certain visual styles use an accent color for the checked state:
some of these use it for the background of the circle,
others for its foreground.
In both cases, 'accent-color' would be used to style
the affected parts of the control.
For visual styles that do not use an [=accent color=],
'accent-color' will have no effect.

The following are all examples of checkboxes rendered with a blue 'accent-color':

Browser	Platform	Sample	Notes
Firefox 79	Win		No use of accent color
Chrome 81	Win		No use of accent color
Chrome 83	Win/Light		Accent color as checked item “background”
Chrome 86	Win/Dark		Accent color as checked item “background”
Safari 13	Mac/Light		Accent color as checked item “background”
Safari 13	Mac/Dark		Accent as checked item “background”, and also used to generate highlight and shadow colors around the edges
Snow Leopard	Mac		Accent color used to generate checked “background” gradient

Depending on the specified 'accent-color',
in order to preserve sufficient contrast
between the square and the checkmark
the UA might need to make some adjustments.
For example,
when applying 'accent-color' as the square’s “background”,
the UA could either adjust the accent color’s luminosity or brightness enough
to contrast with the color used to draw the “checkmark”
or change the color used for the “checkmark” to conrast better with the 'accent-color',
for example by switching from using the scheme’s foreground color to its background color
or vice versa.
If using 'accent-color' for the “checkmark” instead,
a different adjustment might be needed
since the relevant contrast would be between the 'accent-color'
and the square’s fill color.

<input type=radio>

A radio button is typically composed of a circle,
potentially overlaid by a “dot” representing the checked state.

As with checkboxes,
certain visual styles use an accent color for the checked state:
some of these use it for the background of the circle,
others for its foreground.
In both cases, 'accent-color' would be used to style
the affected parts of the control.
For visual styles that do not use an [=accent color=],
'accent-color' will have no effect.

The following are all examples of radio buttons rendered with a blue 'accent-color':

Browser	Platform	Sample	Notes
Firefox 79	Win		No use of accent color
Chrome 81	Win		No use of accent color
Chrome 83	Win/Light		Accent color as checked “foreground”
Chrome 86	Win/Dark		Lightness-adjusted accent color as checked “foreground”
Safari 13	Mac/Light		Accent color as checked “foreground”
Safari 13	Mac/Dark		Accent color as checked “foreground”
Snow Leopard	Mac		Accent color used to generate checked “background” gradient

Depending on the specified 'accent-color',
in order to preserve sufficient contrast
between the circle and the dot
the UA might need to make some adjustments.
For example,
when applying 'accent-color' as the “background”,
the UA could either adjust the accent color’s luminosity or brightness enough
to contrast with the color used to draw the “dot”
or change the color used for the “dot” to contrast better with the 'accent-color',
for example by switching from using the scheme’s foreground color to its background color
or vice versa.
If using 'accent-color' for the “dot” instead,
a different adjustment might be needed
since the relevant contrast would be between the 'accent-color'
and the circle’s fill color.

<select> / <input type=text list=datalist>

Drop-down and combo-box controls are typically displayed as
a text area containing the currently-selected value,
and an activation “widget” (such as an arrow button)
which is used to pop up the list of options.

Some visual styles use an accent color for the activation widget.
In these styles, 'accent-color' would be used to style the widget.

The following are all examples of drop-down controls rendered with a blue 'accent-color':

Browser	Platform	Sample	Notes
Firefox 79	Win		No use of accent color
Chrome 81	Win		No use of accent color
Chrome 83	Win/Light		No use of accent color
Chrome 86	Win/Dark		No use of accent color
Safari 13	Mac/Light		Accent color lightened and used to generate drop-down widget “background” gradient
Safari 13	Mac/Dark		Accent color used to generate drop-down widget “background” gradient
Snow Leopard	Mac		Accent color used to generate drop-down widget “background” gradient

Depending on the specified 'accent-color',
in order to preserve sufficient contrast
within the activation widget
the UA might need to make some adjustments.
For example,
when applying 'accent-color' as a background,
the UA could either adjust the accent color’s luminosity or brightness enough
to contrast with the color used to draw the arrows
or change the color used for the arrows,
for example by switching from using the foreground color to the background color
or vice versa.
If using 'accent-color' for the arrows instead,
a different adjustment might be needed
since the relevant contrast would be between the 'accent-color'
and the widget’s background.

<select multiple>

A multi-select is typically composed of
a rectangular area containing several lines of text,
each corresponding to an option.
Depending on the visual style,
selected options might be identified as highlighted items
or identified by some adjacent icon such as a checkmark.
In visual styles where the highlight is intended to match the [=accent color=],
the UA would use specified 'accent-color'.

<button> / <input type=submit|reset|button>

A button does not typically have any [=accent colored=] pieces.

<input type=range>

A range input many parts, and thus many potential accent parts.
One is the thumb, which is the part of the <range>
that the user can drag along the track.
Another is the track that the thumb slides along,
which is sometimes shaded differently on the “filled” side of the thumb,
the portion of the range, between 0 and range.value.
Whichever portion of the range input is typically colored by the [=accent color=]
would be likewise affected by 'accent-color'.

<progress>

A progress bar is typically composed of a shaded track,
within which a portion of the track is shaded in a different color
to indicate the value of the control.
Whichever portion of the progress bar is typically colored by the [=accent color=]
would be likewise affected by 'accent-color'.

<input type=text|search|password|email|tel|url|...>

Text-input controls are typically rendered as an empty box
containing the value of the input as text,
and do not have any parts highlighted by the [=accent color=].
However, sometimes additional controls are embedded,
such as a “clear value” button,
or a “show/hide password” button.
If the visual style uses its [=accent color=] to render any of these,
then they would be likewise affected by 'accent-color'.

<input type=number|date|time|datetime-local|week|month>

A number of more complex input controls are typically rendered as
a text field that displays the currently-selected value,
and an activation widget/button which is used to bring up a pop-up “picker”.
As with text-input controls,
if the visual style uses its [=accent color=] to render any part of the activation widget,
then they are likewise affected by 'accent-color'.
Additionally, if the visual style uses its [=accent color=] within the pop-up “picker”,
then those affected parts, too, can be affected by 'accent-color'.

[caraitto]

@chrishtr @mfreed7
For a accent-color of "auto", could getComputedStyle() be used to get the OS color scheme (concern is that this could be used to fingerprint the user's OS)? Or would getComputedStyle(elem).getPropertyValue("accent-color") just return "auto" or ""?

[josepharhar]

For a accent-color of "auto", could getComputedStyle() be used to get the OS color scheme (concern is that this could be used to fingerprint the user's OS)? Or would getComputedStyle(elem).getPropertyValue("accent-color") just return "auto" or ""?

I don't think we should return the OS color scheme here due to fingerprinting, like you said. We don't even use the OS color scheme for form control accent colors yet in chrome, we only use it for focus rings and selection color right now.

[henke37]

My concern there is that javascript may need the value in order to load appropriate assets or for other customizations too complex for css to handle.

[caraitto]

@josepharhar Could we make sure that the spec mentions that the OS color scheme shouldn't be returned?

[fantasai]

Spec has been published on /TR at https://www.w3.org/TR/css-ui-4/#widget-accent

Note: The computed value is explicitly defined as “the keyword auto or a computed color”.

[mangelozzi]

Well done guys this makes code much simpler (chopped out masses of pseduo ::before svg elements to simulate checkboxes, that had all sort of issues with validation), big thank you!

I have a suggestion. What if accent-color could be applied to <select> or <option> to finally be able to change blue background when hovering over an option:

(Please note the very nice green check box, because the color theme is green, but can't change the blue in the select box):

[josepharhar]

<select> frequently uses platform-specific implementations for the popup that we can't style. I think that the upcoming <selectmenu> element will be easier to style.

[samuelbradshaw]

The spec for accent-color says that "whichever parts of the element’s control(s) would have otherwise been styled with an accent color" should "use the specified accent-color" – so, I think the blue you see in the drop-down menu is a bug (or an incomplete implementation) in the browser you're using.
https://www.w3.org/TR/css-ui-4/#widget-accent

EDIT: Unless the implementors for the browser are considering that to be a "text selection" color, rather than part of the element itself? See #5657