Not applicable in Chrome OS since I don't get this autocomplete UI even with auto complete/suggestions turned on in settings. 

Google Chrome	70.0.3511.0 (Official Build) canary (64-bit)
Firmware Version Google_Eve.9584.160.0	

> Not applicable in Chrome OS since I don't get this
> autocomplete UI even with auto complete/suggestions turned on in settings. 
You should be getting them.  Trying search for the query in multiple tabs multiple times, then try again.  If you still aren't getting inline autocompletions, please file a new bug with exact details on what you tried.

Bug 618334 is for Omnibox hint text low contrast (gray on gray)
 Bug 870549  is for Omnibox autocomplete text low contrast (white on blue)

I think the issue here is that, while Mac and Linux (probably CrOS, too, but my Chromebook is not working at the moment) are following the UX redline spec* (black text on a light blue background), Windows is still using white text on a dark blue background for highlights.

I think Windows should be doing the same thing as the other platforms.

orinj: assigning to you since you were dealing with the color-handling code earlier.

* https://gallery.googleplex.com/projects/MCHbtQVoQ2HCZbNPZ-X7_AcC/files/MCHtA7U1iMGr6y43ejxu8E4Uh-KRo2S5bu8

See: crrev.com/c/1229504 : [omnibox] Set selection text color according to redline spec

I don't think any OS was explicitly following the redline spec, it just so happened that the default native theme colors for Linux were pretty close to begin with.  Windows, on the other hand, has a very different idea about how selected text should look.  So this fix brings all up to spec, but it will be a very noticeable change on Windows.  Theoretically, that's just what this bug calls for: improve contrast by following spec.  But I'm not so sure that the spec is an improvement over the status quo.  Here's why I question whether we should make this change:

* We seem to be generally biased to consider only the contrast ratio between background and text color.  Great for readability, but BAD for scanning-sense of UI state.  What about the contrast between selected and non-selected text areas?  That big blue block on Windows starts to look pretty good because the distinction is made obvious by contrasts between backgrounds: this matters for side-by-side contrast and helps selections stand out from other visual elements.

* Contrast ratios are probably wrong anyway.  I realize the value of having a mathematical model for contrast & readability, but as I'm actually reading text with these colors, intuitively the model seems off.  I don't think the real usability difference is so huge as the calculated values suggest.  #3399FF vs #FFFFFF = 2.94  while  #202124 vs #e8f0fe = 14.04 ... I can read both of these:
https://contrast-ratio.com/#%23FFFFFF-on-%233399ff
https://contrast-ratio.com/#%23202124-on-%23e8f0fe

* Selections are a salient UI feature, and I guess we may hear some push-back if we use Chrome-specified colors in the omnibox instead of the standard/native colors used elsewhere.  Consistency and harmony with other theme colors may trump this concern if we strike the right color balance, but as it is I think the light GoogleBlue50 is going to be hard for Windows-users to notice.

Good questions. I've included some responses below but really we should just do what bklmn@ says. :)

> * We seem to be generally biased to consider only the contrast ratio between background and text color.

I think you're right that we're biased towards this. If you can't read the text then nothing else really matters. But I don't think it's true that we only consider that. You're right that we should consider the contrast between the selected and non-selected backgrounds as well.

> * Selections are a salient UI feature, and I guess we may hear some push-back if we use Chrome-specified colors in the omnibox instead of the standard/native colors used elsewhere.

UX has been pretty thoughtful about how they balance the design of Chrome's UI with the conventions of the platforms. I note that the selection on Windows in the chrome://settings UI also uses the reverse-text-color approach so yeah it's worth considering whether we should be consistent with that here.

> * Contrast ratios are probably wrong anyway. [...] I can read both of these.

I can't speak authoritatively about this subject but I can say that what you or I or any one particular person can easily read is not a good way to judge whether or how important contrast ratios are.

I chatted bettes@ on this and we both agree we should follow what the OS defines here. 

Sounds good to me, this means we keep the status quo.  If default Windows selection colors form contrast values deemed insufficient by Chrome standards... well, things might get philosophical if we try to address it in Chrome directly.  Microsoft UI wisdom versus Accessible Contrast Ratio values, FIGHT! :)

Marking WontFix because it already works as intended.

Behaving similarly to the platform standard seems reasonable to me. But I just checked and it turns out that we use a slightly darker blue background than the platform (on Windows 10, at least, compared to text fields in Control Panel). I'm guessing we did this on purpose in order to achieve at least a non-disastrous ratio of 2.9. Could we try just one more shade slightly darker blue and see what that looks like and what ratio that achieves?

In bug screenshot:
#3399ff vs #ffffff = 2.94

In screenshot of today's Canary:
#0078d7 vs #ffffff = 4.49


Running Windows, breaking VS2017 on this line...
https://cs.chromium.org/chromium/src/ui/native_theme/native_theme_win.cc?rcl=6738399c6daa2b2730b7150e04476a797515bbff&l=479

...shows a system color #0078d7 as observed in Canary screenshot.  This is coming from system_colors_ which appears to actually be populated from native OS calls:
https://cs.chromium.org/chromium/src/ui/native_theme/native_theme_win.cc?rcl=6738399c6daa2b2730b7150e04476a797515bbff&l=303

So on my system, where colors have not been changed, this is right at the readable contrast ratio.  What was your process for checking the shade of blue?  Can you point me to a line of code setting it to a blue darker than native system color?  Can leberly@ tell us how the original #3399ff was found?

The user can certainly change system colors.  We can force override them, or even nudge them in the direction of better contrast... but first we should agree on whether we are going to use OS colors or override them - and if so, by which strategy?

Made this just for clarity (and to double check the numbers). If we truly do get #0078d7 from the OS I think 4.49 is sufficient. However is this color able to be changes by user preference? If so, maybe we should make it fixed. Another option would be using google blue (most right), which increases contrast to 5.18. 

¯\_(ツ)_/¯ 

Deleted: blue-ratios.png 39.0 KB

	blue-ratios.png 39.0 KB View Download

Yes I am pretty sure users can change the system colors.  I guess that's how we got this bug in the first place.  I have seen Chrome running on Ubuntu with selected text background of orange.  Even if users couldn't change the colors, the fact that they are coming from a system outside of Chrome is fundamentally a cause for concern.  We should treat the color as unknown.

I just had a long talk with jdonnelly@ about my ideal vision of how we could solve these kinds of problems once and for all: put an intelligent color system under user control between Chrome and the OS (or any other source of colors).  It would know about relations between colors and warn (or fail) when trying to install colors forming insufficient contrast.  Colors from the system could be pulled manually and auto-checked, with any necessary contrast fixes suggested automatically.  But that's a topic for another day...

For this bug, I will add pkasting@ who has surely encountered the OS vs. Chrome color issue before.  What do you think, should we check contrast in UpdateSystemColors and darken selection text background color if necessary?  Or ignore the problem entirely and hope users make sensible choices with their system colors...?  :)

For this bug, if we're using both the system selection background and foreground colors, we should do nothing and WontFix.  Chrome should not be trying to adjust the user's system colors for more or less contrast.  So the question, as in comment 12, is where the #3399ff came from in comment 0: is that the configured system color on that system?  Or is Chrome producing this color somehow?

Regarding the larger issue of themes and how to plumb colors and guarantee contrast: talk to rameier@, who's likely going to own this in the future, and has his own (and my) thoughts on that subject as well.

Yes the selection text background & foreground colors both come from the system.  Unless I missed something in the code (always possible; if so, point me to it).

Maybe #c0 bug/screenshot was reported from an older version of Windows, or colors were customized.  It would be good to know the process for getting at these colors so we can try alternatives (how about black on white!) but it's not really necessary: any colors coming from "elsewhere" should either be overridden explicitly or left intact.

My preferred way of handling this would be to let the color system's interface read system colors on button-press, then suggest alternatives that form sufficient contrast -- but all under express user control at chrome://color (or something like that).  I emailed you and rameier@ to take this discussion off the bug.

For this bug, it sounds like we agree on WontFix but I'll wait a bit to hear from others first.

Would love a more dynamic solution to pkastings@ point, but IMO we should have a stronger opinion that ensures proper contrast and move away from the OS defined colors. We seen some similar issues in MacViews with OS button color vs Chrome/Google colors, but thats another conversation.

Sharing with bettes@ to get his weigh in. 

If we do try to move away from system colors, I think we need to at least do something like bug 883023.

The common case today is that Chrome opinionatedly makes things have less contrast and be less accessible than system defaults, so I don't have a lot of trust here.  But even if we want to do something which scores well in general, there are lots of edge cases where users have legit reasons to enforce some sort of particular system theming and it's not really our place to override.  So I wouldn't be a fan of assuming we Know Better than the system and the user.

Expose ALL colors as a data set and use a chrome://color tool to help authors set every color shown by Chrome UI.  Some colors can auto-derive from others for simplicity's sake, but it's all data under user control so they can override or pull in system colors wherever they want them.  The tool checks and warns about contrast relations (or enforces them, if we want to be opinionated).  I really think if we put something like this out and help users with a server to share and rate color schemes, it will be a huge win both for accessibility and user happiness.

If we force colors, we have to force ALL colors for relational consistency, and that is problematic.  Hence the inclusion of theme and system colors - but we don't go far enough.  It is precisely the lack of user control that causes problems: they need access to the whole set, not just the system/theme subset.  I think developing such a system and tool is well worthwhile - then all these problems go away and get solved with data, which evolves much faster than Chrome dev CLs.

I think such a control might fit better in Vivaldi than Chrome :)

Marking WontFix as discussed.  Still looking forward to an improved color system in the future, which should prevent these kinds of bugs from popping up.