Sending this over to bettes@ for color spec.

Implementing  bug 856893  will affect this.

This is related to http://crbug.com/865819.

Any updates on this? This is an a11y blocker for us.

Rob's comment 6 is confusing; it says this bug is related to itself, and reassigns to Orin without a color spec from Alan.

Addressing  bug 856893  might change the hovered numbers (though I don't know to what), but if the active-vs.-inactive contrast ratios are too low, Alan needs to adjust the master spec of what the frame and active tab colors are.

I figured Rob meant 856893.  I am trying to nail down the right course of action for both these bugs together (see my last comment on 856893) but my big concern at this point is that the whole new contrast-ratio-driven approach is too experimental for post-branch development.  It may well be brilliant, and maybe we're close, but it's all new & different, and I suppose time is short.

http://crrev.com/c/1147605 shows some progress, in 3 different directions: 1) interpolation within preferred range, 2) constants straight from an updated spec, and 3) the new contrast-ratio targeting approach.  If we can get #3 going and it works as well as hoped, it might be great and handle all the cases, but it's uncertain at this point.

Okay, the contrast-ratio targeting approach is submitted to CQ so we should see it working in tomorrow's canary.  What I think would be helpful in knocking out this issue is to:

* State the process used to measure live contrast ratios (is it just screenshot + color tool in GIMP + contrast-ratio.com?  A screenshot with measured pixels marked would be great.)
* Post the updated contrast ratio values along with the raw colors used to compute them.

I suspect we may end up tuning some constant values targeting specific contrast ratios.  Right now they are definitely smaller than the 1.4 mentioned on #0.

I suspect the ratios in comment 0 were "contrast-ratio.com using the spec values" but I'm not sure.

Peter is correct about #0. Gonna look into Canary today.

Note, the contrast ratio approach in comment 10 hasn't landed yet because it failed browser tests.

Yeah, I am learning that I should say "look for it in Canary tomorrow" when CLs *land*, not when submitted to CQ.  The failures appear to be unrelated to the change itself, but it's new to me and in any case will need to be troubleshot.

Friendly ping! Is this in today's canary?

No.  

Now the CL is landed, so look for contrast-ratio-driven tab hover opacities in tomorrow's canary.  My concern about the targeted numerical contrast ratio values (last paragraph of comment #10) still stands.

Implementation looks pretty good across default, incognito, colored title bars, and themes.  

I'd be interested in what some subtle tuning might look like to increase the contrst, but I don't think it's possible for M69 (per Mark's advice). 

Darker tabstrips could use a brighter base color, but increasing the contrast for darker tabstrips runs the risk of blending inactive-hover tabs with active tabs in the default tabstrip case. Possibly worth opening up another bug for? 

Doing things like small contrast increases and color changes across all themes, including default, is pretty easy and safe, even for M69.  My read on this bug is that this is about the default theme not having sufficient contrast.  If you can come up with a tweak you want to make to the default theme for incognito, we can adapt it to work for other themes/settings.

Moving to 70 - Already received a11y signoff for M69.