By comment #74 of bug 1270006, the contrast of the icon on OS X 10.9 is insufficient. We either need to ask someone from UX to update the toolbar icon in Toolbar.png and Toolbar@2x.png, or use an SVG filter to brighten it.

Rex will check the bug to decide whether to update toolbar icon. If so he'll ask visual Carol for it. Assign to Rex first.

I've just tested on Mac OS X 10.12 with the default theme, and this is a problem there as well: http://webaim.org/resources/contrastchecker/?fcolor=4d4d4d&bcolor=2b99ff A "brightness(1.2)" filter adds a bit of contrast, and indeed we can verify that this passes the accessibility test, at least for large text: http://webaim.org/resources/contrastchecker/?fcolor=4d4d4d&bcolor=00b9ff The brightness solution has the small issue that it affects the border of the icon too, but I don't think it's that noticeable after all. There might be other solutions to make the difference between the two progress areas more visible, for example using hollow icons. I'm not sure it's worth pursuing, because in a few months we'll do a redesign of the toolbar icons. I've not tested the contrast on other platforms but they should all be verified.

OK, I didn't know that we have this tool to check the contrast. Thanks for the detail! Previously I decide to talk with visual whether they want to make a revised icon; but since you said the icon will be revised in a few month, I'll show the version using filter and show it to visual to confirm they accept the result first.

There's a question for me though: when the icon turns to fully bright, the dark-gray background of the arrow is covered completely, and users just see a brighter arrow on a toolbar with an also bright-colored toolbar ... does this need to be considered by the WCAG AA standard too?

Yes, I believe we should keep in mind the contrast of the highlighted icon with the background too. Hopefully we can easily achieve both.

Hmm, If we compare the background color of toolbar with color of highlighted icons, they simply failed the contrast checker: http://webaim.org/resources/contrastchecker/?fcolor=2b99ff&bcolor=e4e4e4 And I am a little bit confused, because apparently all the highlighted icon in firefox failed this check too already when considering the toolbar background. And they failed with an even lower contrast ratio. If we tune the brightness up here, it just worsen the situation. This seems to be a more general issue around the original icon design. (or we applied an too strict metric?) Also adjusting just the progressbar icon produces inconsistency with other highlighted icons. So, I feel handling only this special case may not be a good idea. Since the contrast in progressbar is still better than the background-to-highlight one, I would suggest not to block this bug to bug 1270006 and just take this question into consider when making new icons. How do you think Paolo?

Because the whole point of the indicator is to show the progress of the download, and also to show that a download is indeed in progress, the contrast between the states of the icon is more important than the contrast between the icon and the background, if we cannot achieve both. If you want to preserve the current brightness when the download has completed, you can brighten the icon proportionally less as the download progresses, using JavaScript similarly to what you do with the "height" property.

Sounds good to me for the proportional adjusting idea, but I'll make sure of that with visual before finishing it. I may try to adjust both background and foreground color together based on visual's feedback.

Oh and I forgot to mention that... do you think it's required to consider the dark theme too? It don't have plenty contrast based on the checker either and need to make foreground deepen to pass the check if we decide to. Though that's not our default theme so we have relatively low impact on that.

Yeah, we should consider the dark theme too. Good point!

Hi Paolo: To control two css property together and considering dark theme at the same time, I just came up a different way of animating that makes use of css animation. And this patch depends on bug 1270006's patch so you may need to test it with that. (If you think they can be merged as one patch at last, that's ok for me but I think separating them makes writing and reviewing easier)

Comment on attachment 8840792 [details] Bug 1338984 - Adjust brightness with respect to download progress for arrow-typed progress icon. https://reviewboard.mozilla.org/r/115230/#review116706 Brilliant solution! Typo in commit message: "prgress" ::: browser/components/downloads/content/indicator.js:449 (Diff revision 1) > - (PROGRESS_ICON_FULL_HEIGHT_PERCENT - > - PROGRESS_ICON_EMPTY_HEIGHT_PERCENT) / 100 + > - PROGRESS_ICON_EMPTY_HEIGHT_PERCENT) + "%"; > + // We set animationDelay to a minus value (0s ~ -100s) to show the > + // corresponding frame needed for progress. > + this._progressIcon.style.animationDelay = (-this._percentComplete) + "s"; > } else { > this.indicator.removeAttribute("progress"); > - this._progressIcon.style.height = "0"; > + this._progressIcon.style.animationDelay = ""; This and the value specified originally in the CSS should be the same. ::: browser/themes/shared/downloads/indicator.inc.css:32 (Diff revision 1) > +@keyframes indicatorArrowProgress { > + 0% { > + height: 35%; > + filter: brightness(1.2); > + } > + 100% { > + height: 87%; > + filter: brightness(1); > + } > +} > + > +@keyframes indicatorArrowProgressDark { > + 0% { > + height: 35%; > + filter: brightness(0.7); > + } > + 100% { > + height: 87%; > + filter: brightness(1); > + } > } Please check that these values makes sense visually on all platforms. You can use conditionals to apply different values for different platforms if needed.

Thank you Paolo! And sorry for the late reply. I caught a cold and we had a holiday on Tuesday so I'm absent for a few days. I'll update the patch and check-in them by tomorrow.

Tagging checkin-needed. Note: This patch is based on bug 1270006, which is already pushed yesterday so it should be no problem to check-in. If failed we may need to wait for a while.

Pushed by cbook@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e87b41eb5ac0 Adjust brightness with respect to download progress for arrow-typed progress icon. r=Paolo

Hey,the download indicator shows no activity when an download is being done. Have to click the download arrow to know the current download.Literally no contrast between the download arrow and the background.Running windows 10 and tested on firefox 54. [bugday 20170308]

(In reply to Moneshb7 from comment #19) > Hey,the download indicator shows no activity when an download is being done. > Have to click the download arrow to know the current download.Literally no > contrast between the download arrow and the background.Running windows 10 > and tested on firefox 54. > [bugday 20170308] Changing the state of the release flag is not the right thing to do here, though. You should ask the patch author or reviewer whether they want to reopen the bug completely, or file a followup, or something else. Paolo?

Yes, new bugs should be filed with more information and steps to reproduce. In particular: > the download indicator shows no activity when an download is being done. Does this mean that there is no change in the Downloads Indicator, or that the change is not visible enough? Does this happen only with the "progress arrow" indicator, or also with the previous "progress bar" indicator? It's important to use the same download and steps to reproduce in both cases. > Literally no > contrast between the download arrow and the background. If this is not the same issue as above, it should be filed as a different bug. Please attach a screenshot to the new bug.

(In reply to :Paolo Amadini from comment #21) > Yes, new bugs should be filed with more information and steps to reproduce. > In particular: > > > the download indicator shows no activity when an download is being done. > > Does this mean that there is no change in the Downloads Indicator, or that > the change is not visible enough? > > Does this happen only with the "progress arrow" indicator, or also with the > previous "progress bar" indicator? It's important to use the same download > and steps to reproduce in both cases. > > > Literally no > > contrast between the download arrow and the background. > > If this is not the same issue as above, it should be filed as a different > bug. Please attach a screenshot to the new bug.

(In reply to :Gijs from comment #22) > (In reply to :Paolo Amadini from comment #21) > > Yes, new bugs should be filed with more information and steps to reproduce. > > In particular: > > > > > the download indicator shows no activity when an download is being done. > > > > Does this mean that there is no change in the Downloads Indicator, or that > > the change is not visible enough? > > > > Does this happen only with the "progress arrow" indicator, or also with the > > previous "progress bar" indicator? It's important to use the same download > > and steps to reproduce in both cases. > > > > > Literally no > > > contrast between the download arrow and the background. > > > > If this is not the same issue as above, it should be filed as a different > > bug. Please attach a screenshot to the new bug. ----------------------------------------------------------------------------------------------------------------- Does this mean that there is no change in the Downloads Indicator, or that the change is not visible enough? >>No change in the Downloads indicator Does this happen only with the "progress arrow" indicator, or also with the previous "progress bar" indicator? >> happens only with the progress arrow .

Can you file a new bug / new bugs, with more detailed steps that you're using to reproduce, and especially screenshots of what you're seeing?

(In reply to :Gijs from comment #24) > Can you file a new bug / new bugs, with more detailed steps that you're > using to reproduce, and especially screenshots of what you're seeing? ------------------------------------------------------------------------------------------------- Sure, I'll file a new one .

I can confirm this issue is fixed, I verified Fx 54.0a2, build ID:20170323004002 on Windows 10 x64, Mac OS X 10.11.6 and Ubuntu 14.04. Cheers!