988191 - Title bar font color shouldn't be as eager to change according to window border color on Windows 8

Status: VERIFIED FIXED

(Firefox :: Theme, defect)

Description

[Rafael]

Attachment: BlackWhite.png

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140325030201

Steps to reproduce:

Changed the window border color to a darker one.


Actual results:

Title bar font became white.


Expected results:

Title bar font should've remained black as the Windows options for window border color won't allow it to become too dark that a black font won't be seeing. Aside from that, all the windows have black title bar font color, so Firefox looks inconsistent.

Comment 1

[Matthew N. [:MattN]]

We just implemented this in bug 940393 to address readability concerns. Can you please read over that bug and see if that makes sense. Perhaps there is some compromise that can be made with the threshold but I think it's clear improvement for some colours.

Comment 2

[:Gijs (he/him)]

(In reply to Rafael from comment #0)
> Title bar font should've remained black as the Windows options for window
> border color won't allow it to become too dark that a black font won't be
> seeing.

This is not true. Windows 8's options let you adjust the hue, saturation and brightness of the color yourself, and you can configure a fully black window frame if you want to.

The default Windows titlebar font is bigger than the tab titles (which means it can deal with lower contrast than the tab titles), and a number of the shades of gray that are offered by default will also be so dark on screens with low brightness that the smaller black text is very hard to make out.

Furthermore, the row of tabs is something you regularly scan, looking for the tab you want, whereas the window title is much less important (when I'm e.g. writing a prose document, I don't constantly look at the titlebar indicating that I'm still in LibreOffice/MS Word/whatever with file X open), which is presumably why MS thought it'd be OK to leave it black irrespective of the window frame color.

I don't think the consistency is important enough here to warrant backing out this fix, but I'll let Jared make the final call here.

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

While testing out this change, I noticed some colors triggered the color-flip that surprised me. These were medium to slightly-dark greens. As Matt said, we could tweak the threshold values, but the ones we are using are those recommended by the Web Content Accessibility Guidelines.

Can you attach a screenshot of the issue?

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

Sorry, I see the screenshot on the bug already. This comes down to an accessibility + UX question. Forwarding needinfo accordingly.

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

This bug doesn't seem to me to be about a classical 'title bar'.

Where does the background colour for the our tabs on Windows come from? (Is it based on the Windows system setting for title bar background?)

Comment 6

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to David Bolter [:davidb] from comment #5)
> This bug doesn't seem to me to be about a classical 'title bar'.
> 
> Where does the background colour for the our tabs on Windows come from? (Is
> it based on the Windows system setting for title bar background?)

Background tabs use the color of the window frame. On Windows 8, this can be specified by going to the Personalization menu, and choosing Color at the bottom. Within that submenu, the user can specify their own custom color.

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #6)
> (In reply to David Bolter [:davidb] from comment #5)
> > This bug doesn't seem to me to be about a classical 'title bar'.
> > 
> > Where does the background colour for the our tabs on Windows come from? (Is
> > it based on the Windows system setting for title bar background?)
> 
> Background tabs use the color of the window frame. On Windows 8, this can be
> specified by going to the Personalization menu, and choosing Color at the
> bottom. Within that submenu, the user can specify their own custom color.

And I guess we don't follow the Windows 8 settings font colour because users might want low readability on title bars, and not so for in client area colour pairings. I think this is reasonable thinking. Overall I agree with comment 2, at least for now.

Comment 8

[Stephen Horlander [:shorlander]]

I think we are making the right choice WRT to contrast by flipping from dark to light at a certain threshold, regardless of how Windows itself is handling titlebar text. However we currently seems too aggressive when inverting the colors. The values need to be tweaked a bit.

Comment 9

[Rafael]

(In reply to :Gijs Kruitbosch from comment #2)
> (In reply to Rafael from comment #0)
> This is not true. Windows 8's options let you adjust the hue, saturation and
> brightness of the color yourself, and you can configure a fully black window
> frame if you want to.
> 
> The default Windows titlebar font is bigger than the tab titles (which means
> it can deal with lower contrast than the tab titles), and a number of the
> shades of gray that are offered by default will also be so dark on screens
> with low brightness that the smaller black text is very hard to make out.
> 
> Furthermore, the row of tabs is something you regularly scan, looking for
> the tab you want, whereas the window title is much less important (when I'm
> e.g. writing a prose document, I don't constantly look at the titlebar
> indicating that I'm still in LibreOffice/MS Word/whatever with file X open),
> which is presumably why MS thought it'd be OK to leave it black irrespective
> of the window frame color.

Indeed, I just noticed you can adjust the 'settings' of the color and you're right about tab row being different than window title. Excelent point on that.
But I still think the treshold could be changed, as Matthew said, since a not so dark background triggers the font color change, as Stephen Horlander stated.

Comment 10

[:Gijs (he/him)]

(In reply to Rafael from comment #9)
> But I still think the treshold could be changed, as Matthew said, since a
> not so dark background triggers the font color change, as Stephen Horlander
> stated.

I agree. It's interesting though, because AFAICT the formula the original patch implemented is following AERT's recommended algorithm, which isn't the same as WCAG's...

Jared, can you try using the formulas from:

http://www.w3.org/TR/WCAG20/#contrast-ratiodef
and
http://www.w3.org/TR/WCAG20/#relativeluminancedef

instead to aim for at least a 4.5:1 contrast ratio? I'm much more familiar with WCAG than with AERT, and somewhat more confident that they'll result in a more "sensible" threshold. http://webaim.org/resources/contrastchecker/ seems to suggest, for instance, that the screenshot example (#c17a71) should be considered OK for black text (for AA, but not AAA, compliance).

More interestingly, it suggests that white text on that background actually provides *less* contrast, which isn't how I perceive it (that is, on my screen, the white text seems more legible to me than the black, even if I'm not sold 100% on the black variant warranting swapping to white).

David, can you clarify? Maybe my memories of how this was meant to work are rusty... :-\

Comment 11

[:Gijs (he/him)]

radar'ing

Comment 12

[David Bolter [:davidb] (NeedInfo me for attention)]

Probably best to go with WCAG.

Comment 13

[:Gijs (he/him)]

Attachment: change to WCAG algorithm for titlebar font,

I went with 3 rather than 4.5 because 4.5 still writes off shades of gray where I think black is fine. This is pretty much entirely subjective. Jared, can you check if this gets it 'closer to right', let's say?

Comment 14

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8398806 [details] [diff] [review]
change to WCAG algorithm for titlebar font,

Review of attachment 8398806 [details] [diff] [review]:
-----------------------------------------------------------------

Please mention that the formula comes from section 1.4.3.

Comment 15

[Jared Wein [:jaws] (please needinfo? me)]

https://hg.mozilla.org/integration/fx-team/rev/5ab06488935a

Comment 16

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/5ab06488935a

Comment 17

[:Gijs (he/him)]

Comment on attachment 8398806 [details] [diff] [review]
change to WCAG algorithm for titlebar font,

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 940393 / Australis
User impact if declined: titlebar text switches to white too eagerly
Testing completed (on m-c, etc.): been on m-c for a week
Risk to taking this patch (and alternatives if risky): low, just changing the maths we do to determine when to switch to white
String or IDL/UUID changes made by this patch: none

Comment 18

[Mike Conley (:mconley) (:⚙️) (PTO Dec 22 - Jan 2)]

Aurora: https://hg.mozilla.org/releases/mozilla-aurora/rev/200aa3202fb1

Beta: https://hg.mozilla.org/releases/mozilla-beta/rev/5e0b16fe8951

Comment 19

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Rafael can you verify this with builds from:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/29.0b7-candidates/build1/
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

Comment 20

[Rafael]

(In reply to Florin Mezei, QA (:FlorinMezei) [Away between 5-16 May] from comment #19)
> Rafael can you verify this with builds from:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/29.0b7-candidates/
> build1/
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-
> central/

Sorry for the *huge* delay on my answer, but it's working now :-)
The fix "arrived" some time ago, I just didn't see the needinfo. I use the Nightly build.

Comment 21

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Marking as verified based on comment 20.