We need to add every hard coded color we want for visual integration with the platform to nsILookAndFeel. If eMetric_UseAccessibilityTheme is not enabled, these colors should be set to hard coded values, and if it is enabled, they should be set to values extracted from the system, like GreyText and Window. See the attached image for an example of how two hard coded colors we would like to use in the Vista theme would react. Every bug that uses a hard coded color should be set to block this bug, so we can get them all in.

I like the approach of making easily overridden named colors, but I think it should be implemented in such a way that normal web pages can't use these colors, we don't want to set up any proprietary colors here. Bug 420236 potentially blocks. Bug 403137 Bug 403147

Bug 414243 – Don't hard code the color of glyphs used in buttons. Bug 418044 – Hard-coded border color of Downloads Complete notification. Bug 418598 – Fixed background image for selected item in Error Console.

I will be putting together a list of all of the hard coded colors in our UI, along with the color they should fall back to for accessibility, and the various platform specific colors we would like to use for visual integration: http://wiki.mozilla.org/Firefox3/Colors (note: currently very incomplete)

Neil, can you look at this and comment on risk/viability to get done this week?

There are about 80 or so to change. This would presumably mean adding a bunch of constants to widget/src/windows/nsLookAndFeel.cpp

There's a considerable number of false positives. For example, hard coded text *and* background colors or hard coded border colors aren't accessibility problems.

(In reply to comment #6) > There's a considerable number of false positives. For example, hard coded text > *and* background colors or hard coded border colors aren't accessibility > problems. > Nonetheless, they should be converted to native colors.

That's not generally true. Think of the find bar or the identity button's background for EV sites.

as for the places calendar findings, see bug 367991 and bug 422977

(In reply to comment #8) > That's not generally true. Think of the find bar or the identity button's > background for EV sites. > I agree. But see bug 418044 for an example of an exception.

Yeah. Bugs like bug 418044 don't need this bug, though. The alert box could just use a native color from the start.

I think there are a few things that are inherently high-contrast but hard coded. The find bar that Dão mentions is a good example, from the view of the normally sighted there's not much more high contrast than white text on a deep red background. More importantly the actual high contrast isn't the point of the red background, the user has just typed the text and doesn't necessarily need to read it, but the red is a very good flag. However, that doesn't mean that it wouldn't be better to use Highlight if the high contrast mode is enabled, because you're guaranteed that Highlight will be high contrast against HighlighText. Red on the other hand might be a color which the user is particularly color blind against, and might see it as blending with a whiter color. The secondary issue there of course is that Highlight might not be particularly eye catching, which is the real point of the red.

(In reply to comment #12) > The secondary issue there of course is that Highlight might not be > particularly eye catching, which is the real point of the red. And that Highlight might be confusing in that it's the color of selected text.

(In reply to comment #5) > Created an attachment (id=312935) [details] > List of hardcoded colours in windows theme > > There are about 80 or so to change. > Note that this only includes browser and toolkit part of the theme. Also, the search should be expanded to look for the colour constants as well, like 'black' or 'red'. This list only includes the #xxx form. There are also five rgba() usages in browser.css.

(In reply to comment #8) > That's not generally true. Think of the find bar What's special about the findbar? The red or yellow background colour should not be hardcoded either.

(In reply to comment #15) > (In reply to comment #8) > > That's not generally true. Think of the find bar > > What's special about the findbar? The red or yellow background colour should > not be hardcoded either. As long as the text remains readable, there isn't really a problem (much like "hardcoded" icons, e.g. a red close button with a white X). And there's no suitable system color to fall back on.

The same applies to netError.css, btw.

(In reply to comment #14) > There are also five rgba() usages in browser.css. If used with caution, rgba() isn't a problem for accessibility or OS integration.

OK, then I'd like Alex to clarify if by 'every hard coded color' he means 'every hard coded color should be set to values extracted from the system' or if he means 'some hard coded colors should be set to values extracted from the system'.

We should: a) minimize the amount of truly hardcoded colors we're using, and use native colors as a general rule. b) figure out the native atoms to fall back to for each case c) add values that we can use to return the hardcoded colors if we're not using an accessible theme (i.e. vista-awesomebar-url-color (name subject to change) would fall back to greytext if eAccessibleTHeme is true).

(In reply to comment #20) > c) add values that we can use to return the hardcoded colors if we're not using > an accessible theme (i.e. vista-awesomebar-url-color (name subject to change) > would fall back to greytext if eAccessibleTHeme is true). I think this would make more sense as general-purpose solution: foo { color: #whatever; } foo:-moz-system-metric(use-accessibility-theme) { color: grayText; } Note that in any case, there's a small but fundamental flaw in this whole approach: !eMetric_UseAccessibilityTheme doesn't mean that the theme that's in use is equal or at least close to the default theme that we assume when we hardcode a color.

(In reply to comment #21) > Note that in any case, there's a small but fundamental flaw in this whole > approach: !eMetric_UseAccessibilityTheme doesn't mean that the theme that's in > use is equal or at least close to the default theme that we assume when we > hardcode a color. This is why we need to make sure to universally 'soft hard code' whole elements. If we're going to set vista-awesomebar-url-color then we need to be equally sure to set vista-awesomebar-background-color and vista-awesomebar-pagetitle-color. That way when then user is using anything not default they wont have Firefox look like their system, but they will still not run in to things like Bug 409974. I agree with Faaborg that if the user has gone through the trouble of changing their windows chrome, they'll likely have no particular qualms about changing the Firefox theme either (I was one of those users at many points during past releases of Mozilla and Firefox.)

>OK, then I'd like Alex to clarify if by 'every hard coded color' he means >'every hard coded color should be set to values extracted from the system' or >if he means 'some hard coded colors should be set to values extracted from the >system'. In the case of eAccessibleTheme being true, I think we should consider only using extracted system colors. People use this theme for a variety of reasons ranging from low vision acuity to being highly sensitive to light, so we probably don't want to start second guessing too much. For things like the EV or SLL site button, or the find bar, color cues are meant as a secondary indicator that isn't mandatory for using the interface. I would like us to centralize all of our color definitions not just so that we can make sure we fall back to system colors for accessibility (the specific purpose of this bug), but also so that we correctly adapt to each platform's color palette, and also quickly adapt to the color palette's of new operating systems, like Windows 7. For instance, the color of red we use in the Find Bar touches all three issues, low vision users may not be able to see white on light red, it is currently an arbitrarily selected color that doesn't visually integrate on XP, OS X, Vista, or Gnome/Tango, and when a new OS comes out, it probably won't look right there either. If we don't get everything cleaned up for this release, that's fine, but there area a few colors, like vista-awesomebar-url-color (name subject to change) that will be important to address now.

(In reply to comment #22) > This is why we need to make sure to universally 'soft hard code' whole > elements. If we're going to set vista-awesomebar-url-color then we need to be > equally sure to set vista-awesomebar-background-color and > vista-awesomebar-pagetitle-color. That way when then user is using anything not > default they wont have Firefox look like their system, but they will still not > run in to things like Bug 409974. On a related note, it seems like we wouldn't be able to resolve bug 403137 without hard coding a white text color and therefore a black background color, too, which means that bug 425598 (this one) will be a win for white high contrast themes only, leaving especially classic themes in a bad state.

(In reply to comment #21) > I think this would make more sense as general-purpose solution: > > foo { > color: #whatever; > } > foo:-moz-system-metric(use-accessibility-theme) { > color: grayText; > } That's a pretty great idea, actually. This would make it easier for third-party Firefox themers to observe these settings as well, thoughout their themes. It also minimizes the deeper code changes, and puts most of the work into CSS. > Note that in any case, there's a small but fundamental flaw in this whole > approach: !eMetric_UseAccessibilityTheme doesn't mean that the theme that's in > use is equal or at least close to the default theme that we assume when we > hardcode a color. Sure, though as discussed in other bugs, that's not a blocker for Firefox 3. We should file another bug on that, though, and perhaps see if we can expose a -moz-system-metric(not-default-theme) by sampling an atom or two and determining if it's the native theme or not. Sadly, Windows doesn't tell us if something is or isn't a default theme.

> I think this would make more sense as general-purpose solution: > > foo { > color: #whatever; > } > foo:-moz-system-metric(use-accessibility-theme) { > color: grayText; > } It would be great if we could get that working, since this would also enable us to use some different images for high contrast themes (for instance in places like the site button). >should file another bug on that, though, and perhaps see if we can expose a >-moz-system-metric(not-default-theme) I filed the (mildly satanic) bug 426660

As far as I know, eMetric_UseAccessibilityTheme is Windows only, which would mean that bug 423740 and bug 423741 can't depend on it.

(In reply to comment #26) > > I think this would make more sense as general-purpose solution: > > > > foo { > > color: #whatever; > > } > > foo:-moz-system-metric(use-accessibility-theme) { > > color: grayText; > > } > > It would be great if we could get that working, since this would also enable us > to use some different images for high contrast themes (for instance in places > like the site button). > That's a pretty simple change by adding a couple of lines to nsCSSRuleProcessor.cpp::InitSystemMetrics I think most of the effort here is in coming up with the set of colours we need to add/change in the theme.

Let's split the work out, then. I'm happy with this bug morphing to be about making it so that we *can* fall back to system colours in the CSS. We'll deal with the changes to the theme CSS files separately. (In reply to comment #27) > As far as I know, eMetric_UseAccessibilityTheme is Windows only, which would > mean that bug 423740 and bug 423741 can't depend on it. Removed those dependencies. This should indeed be windows only.

Please make sure to clearly document the theme CSS changes clearly here so that those of us maintaining custom themes can more easily update our themes without having to dig through the code to figure out what happened. Thanks.

>Let's split the work out, then. I'm happy with this bug morphing to be about >making it so that we *can* fall back to system colours in the CSS. Yep, color changes throughout the theme should be handled in separate bugs, but I'm trying to organize all of the information here: http://wiki.mozilla.org/Firefox3/Colors so that we do have a central place to track everything Note that this list goes beyond pure accessibility and also into visual integration with the platform.

Enn: any ETA?

Note that bug 426660 comment 11 points out that knowing if we're not using the default theme might actually be enough. eMetric_UseAccessibilityTheme tells us if the user has enabled High Contrast Mode (by pressing ALT+L_SHIFT+PRTSCRN), not if they're using a high contrast theme. Ironically, supporting this is needed for sec.508 compliance, supporting the other one will have a more significant effect on users.

Given bug 426660, can we wontfix this?

Not a WONTFIX yet, but not a blocker.

>Given bug 426660, can we wontfix this? We might still want this for switching to high contrast icons in the navigation toolbar (note how some applications on Vista change their icons when in a high contrast mode.)

I'm closing this, since as of today we still haven't discovered a compelling use case for this. People keep thinking this would be the right solution to their problem when technically it isn't. E.g. they want to use this as a proxy for whether a dark OS theme is being used, which is of course wrong.

Is there any chance the decision not to fix could be reconsidered, for situations like this http://codepen.io/patrickhlauke/pen/KNoNwd (where an SVG icon with a transparent background is used, and - since SVG colors aren't automagically changed when in Windows High Contrast Mode - the colors need to be adapted using MQs)? See my hacky current solution using -ms-high-contrast which works in IE/Edge http://codepen.io/patrickhlauke/pen/WozRyM

On further investigation http://codepen.io/patrickhlauke/pen/WozRyM I can see how Microsoft's high-contrast MQ feature is actually misleading (since users can change the colors actually used by Windows for particular schemes, even "white-on-black", arbitrarily)