1790660 - HCM mode: MR onboarding progress bar colors to satisfy contrast ratio requirements

Status: RESOLVED FIXED

(Firefox :: Messaging System, enhancement, P1)

Description

[Ania]

Currently, in HCM mode:

• The progress bar background has color set to var(--grey-subtitle-1)
• The progress indication uses var(--checkbox-checked-bgcolor) (aka SelectedItem)

Depending on the color scheme this may create low color contrast (e.g., on macOS with default blue accent color the contrast ratio is only 1.6:1 and this is the same for few other presets.) The minimum is 3:1, especially because there is no textual equivalent provided to the progress indication.

Changing to the following combination will ensure the min contrast ratio for these special cases:

• The progress bar has background has color set to (--checkbox-checked-color) (aka SelectedItemText)
• The progress indication color remains the same (var(--checkbox-checked-bgcolor) (aka SelectedItem)

Comment 1

[Ania]

It will be helpful to visually spot check this with Gabrielle before we work on this.

Comment 2

[Shane Hughes [:aminomancer]]

It seems the progress bar's color is defined by its border-color (--in-content-button-text-color), so the background-color (--grey-subtitle-1) isn't actually visible. I think SelectedItemText isn't gonna work since it's white, same as the page background. Can we just do ButtonFace for the progress bar and ButtonText for the progress indicator? (That's black on light gray, on a white page background, which is the same as we use for buttons)

Comment 3

[Shane Hughes [:aminomancer]]

I guess we should also consider whether we want to deviate from the default UA styles. The progress bar has the same colors as a standard <progress> element. So although the contrast is low, that seems to be a universal problem.

The progress bar in Firefox View has the SelectedItem and SelectedItemText colors, but in reverse. I think those colors may not work as well in the MR onboarding surface because it doesn't have that 1px border to prevent SelectedItemText from blending in with the page background. We could add a border, but it might be an issue since the progress steps are currently nothing but border.

Comment 4

[Ania]

Hi Anna,
This is one of the issues reported during the onboarding a11y review, and I think we might need your guidance here:

Comment 5

[Anna Yeddi [:ayeddi] ⛔ Out of office until November 12 ⛔]

(In reply to Shane Hughes [:aminomancer] from comment #2)

It seems the progress bar's color is defined by its border-color (--in-content-button-text-color), so the background-color (--grey-subtitle-1) isn't actually visible. I think SelectedItemText isn't gonna work since it's white, same as the page background. Can we just do ButtonFace for the progress bar and ButtonText for the progress indicator? (That's black on light gray, on a white page background, which is the same as we use for buttons)
The button colors would not work in this case, because the HCM uses colors as semantic indication and the progress bar here is not actionable (users cannot click a dot to go to that step), thus button styles would not fit it.

(In reply to Shane Hughes [:aminomancer] from comment #3)

I guess we should also consider whether we want to deviate from the default UA styles. The progress bar has the same colors as a standard <progress> element. So although the contrast is low, that seems to be a universal problem.

The progress bar in Firefox View has the SelectedItem and SelectedItemText colors, but in reverse. I think those colors may not work as well in the MR onboarding surface because it doesn't have that 1px border to prevent SelectedItemText from blending in with the page background. We could add a border, but it might be an issue since the progress steps are currently nothing but border.

Maybe, using SelectedItem color for the existent border for the current step and using WindowText for the previous and/or next steps would work? This will communicate to a user which step is current, how many steps are in there and are left, and that these steps are not actionable. Would that work?

(In reply to Ania from comment #4)

Hi Anna,
This is one of the issues reported during the onboarding a11y review, and I think we might need your guidance here:

Thank you! Apologies for the delay

Comment 6

[Shane Hughes [:aminomancer]]

Attachment: Border on the progress bar (not on the progress steps)

(In reply to Anna Yeddi [:ayeddi] from comment #5)

Maybe, using SelectedItem color for the existent border for the current step and using WindowText for the previous and/or next steps would work? This will communicate to a user which step is current, how many steps are in there and are left, and that these steps are not actionable. Would that work?

When you say existent border, do you mean adding a 1px border to the progress bar? Right now the progress bar is actually made up of steps that have no content dimensions, they're just 0px tall rectangles with a 3px border, so they end up appearing 6px tall. We could possibly change that, give them actual height and a 1px border, so that they can visually have a real border instead of using the border to compose what appears to be the background.

It's easier to just leave the steps as they are, but put a border on the progress bar itself (the parent of the steps). But that does mean the current step and the next/previous steps can't have different border colors, since the border would be on the single progress bar, rather than on the individual steps.

Another general issue is that the remaining steps have 0.25 opacity. Due to that, I'm getting a 2.44 contrast ratio between the current step and the remaining steps on Windows 10. If we reset the opacity to 1, the contrast ratio improves to 4.66, but it doesn't look very good. The black WindowText feels more prominent than the light blue SelectedItem, so the progress bar seems sort of inverted.

Comment 7

[Anna Yeddi [:ayeddi] ⛔ Out of office until November 12 ⛔]

(In reply to Shane Hughes [:aminomancer] from comment #6)

Created attachment 9296031 [details]
Border on the progress bar (not on the progress steps)
[...]
When you say existent border, do you mean adding a 1px border to the progress bar? Right now the progress bar is actually made up of steps that have no content dimensions, they're just 0px tall rectangles with a 3px border, so they end up appearing 6px tall. We could possibly change that, give them actual height and a 1px border, so that they can visually have a real border instead of using the border to compose what appears to be the background.
[...]

Oh, my bad - I thought the steps are like dots. Thank you for attaching the example!

Then, we can just use SelectedItem color for the filling and for the border, so the step rectangles are 6px tall purple* selectedItem ones (past steps included, like a long indication) and the border of the progress bar itself is purple* selectedItem too with the future steps being SelectedItemText that would be close to the background but the outer border of the progress bar itself would separate them, as you offered. When both outer - progress bar itself - and inner - completed and current steps - are SelectedItem, they should look more prominent than the SelectedItemText color of the future steps. This would provide clear semantics with an expected color pair.

• purple is the SelectedItem on Win 11 HCM Night Sky as an example as blue is on Win 10

Would that work with the current code?

Comment 8

[Shane Hughes [:aminomancer]]

Attachment: Each progress step with its own individual border

Here's another approach, like this:

.onboardingContainer .screen[pos="split"] .section-main .main-content {
/* border-radius isn't necessary in HCM since the card has the same
   color as the window background. and we need to override it so the
   progress bar won't be cut off at the corner. */
  border-radius: 0;
}
.screen[pos=split] .steps.progress-bar .indicator {
  opacity: 1;
  background-color: Window;
  height: 6px;
  border: 1px solid WindowText;
  border-inline-style: none;
}
.screen[pos=split] .steps.progress-bar .indicator.current,
.screen[pos=split] .steps.progress-bar .indicator.complete {
  border-color: var(--checkbox-checked-bgcolor);
  border-color: SelectedItem;
  background-color: SelectedItem;
}
.screen[pos=split] .steps.progress-bar .indicator:first-of-type {
  border-radius: 5px 0 0 5px;
  border-inline-start-style: solid;
}
.screen[pos=split] .steps.progress-bar .indicator:last-of-type {
  border-radius: 0 5px 5px 0;
  border-inline-end-style: solid;
}

Comment 9

[Shane Hughes [:aminomancer]]

Attachment: Default UA appearance for meter and progress

Yeah that sounds like it would work. Let me know which of these you think is better though. Above ^ the border for the current and previous steps would be SelectedItem (same as their background), while the border for remaining steps would be WindowText or something else that's generally dark. That approach would be the most consistent with the standard UA styles for meter and progress elements, so it would be more conventional. Another advantage of that approach is it actually kills two birds with one stone - we have an unrelated bug with an automated test that would incidentally be fixed by giving the progress steps a real height value. So I actually kind of like that approach.

Comment 10

[Shane Hughes [:aminomancer]]

Oh, and I guess actually the most consistent approach would be to mimic the meter appearance exactly (the progress bar actually has role="meter"), giving the whole progress bar a single border of ButtonText.

(In reply to Anna Yeddi [:ayeddi] from comment #5)

The button colors would not work in this case, because the HCM uses colors as semantic indication and the progress bar here is not actionable (users cannot click a dot to go to that step), thus button styles would not fit it.

By the way, while researching this I noticed that ButtonFace and ButtonText actually are used for meter and progress elements in HCM (that's part of the definition for the meter and progress appearances). What you said regarding the elements not being actionable makes sense, but that seems to apply to every meter or progress element. So I think it would be reasonable to keep this specific meter's colors consistent with the basic appearance, and then investigate whether the default colors are correct. I imagine those colors are defined in a spec somewhere. Maybe Emilio has some insight about how they were chosen?

Comment 11

[Emilio Cobos Álvarez (:emilio)]

They were chosen in bug 1675015, probably so they looked good in Windows HCM. But no, those colors aren't defined in a spec.

I subsequently changed them to make them use matching foreground/background colors at some point.

Comment 12

[Anna Yeddi [:ayeddi] ⛔ Out of office until November 12 ⛔]

(In reply to Shane Hughes [:aminomancer] from comment #10)

Oh, and I guess actually the most consistent approach would be to mimic the meter appearance exactly (the progress bar actually has role="meter"), giving the whole progress bar a single border of ButtonText.

(In reply to Anna Yeddi [:ayeddi] from comment #5)

The button colors would not work in this case, because the HCM uses colors as semantic indication and the progress bar here is not actionable (users cannot click a dot to go to that step), thus button styles would not fit it.

By the way, while researching this I noticed that ButtonFace and ButtonText actually are used for meter and progress elements in HCM (that's part of the definition for the meter and progress appearances). What you said regarding the elements not being actionable makes sense, but that seems to apply to every meter or progress element. So I think it would be reasonable to keep this specific meter's colors consistent with the basic appearance, and then investigate whether the default colors are correct. I imagine those colors are defined in a spec somewhere. Maybe Emilio has some insight about how they were chosen?

Great call on the default meter component! We discussed the strategy with Morgan [:morgan] and I'll work on the HCM meter mockup that we can discuss with the design team post-All-Hands.

in the meantime, maybe the code that you proposed in the comment #8 could have the following updates:

1. Window and WindowText are being deprecated (confirmed) - let's use Canvas and CanvasText (I updated the HCM Win 11 palette for a reference
2. Using AccentColor for macOS instead of SelectedItem for the completed steps to provide OS-aligned experience for macOS users (with @media (prefers-contrast:more and not forced-colors) query.

...and to be the following:

.onboardingContainer .screen[pos="split"] .section-main .main-content {
/* border-radius isn't necessary in HCM since the card has the same
   color as the window background. and we need to override it so the
   progress bar won't be cut off at the corner. */
  border-radius: 0;
}
.screen[pos=split] .steps.progress-bar .indicator {
  opacity: 1;
  background-color: Canvas;
  height: 6px;
  border: 1px solid CanvasText;
  border-inline-style: none;
}

@media (prefers-contrast:more and not forced-colors) { // macOS HCM
  .screen[pos=split] .steps.progress-bar .indicator.current,
  .screen[pos=split] .steps.progress-bar .indicator.complete {
    background-color: AccentColor;
  }
}

@media (prefers-contrast and forced-colors) { // Windows OS HCM
  .screen[pos=split] .steps.progress-bar .indicator.current,
  .screen[pos=split] .steps.progress-bar .indicator.complete {
    border-color: var(--checkbox-checked-bgcolor);
    border-color: SelectedItem;
    background-color: SelectedItem;
  }
}

.screen[pos=split] .steps.progress-bar .indicator:first-of-type {
  border-radius: 5px 0 0 5px;
  border-inline-start-style: solid;
}
.screen[pos=split] .steps.progress-bar .indicator:last-of-type {
  border-radius: 0 5px 5px 0;
  border-inline-end-style: solid;
}

Comment 13

[Shane Hughes [:aminomancer]]

Awesome! That all makes sense, and I'll update the MR onboarding styles before the weekend.

Comment 14

[Shane Hughes [:aminomancer]]

Attachment: border around main section, progress bar with no border-radius

In bug 1793401 we added a HCM-compatible background color to the illustration section, so this changes how the progress bar fits with the section to its left. But I think this would be a good opportunity to add a border to the main section, since normally (in non-HCM) the main section would be more defined with respect to the page background. I guess it's really just a coincidence that the page background and the main section background resolve to the same color in HCM. But we can work around that with a border. I think that also allows us to make the progress bar in HCM diverge less in appearance from the progress bar in non-HCM.

Comment 15

[Shane Hughes [:aminomancer]]

Attachment: more like the previous proposal

Here's another approach more like the original proposal. This is basically the same CSS as before but with some margins added to the progress bar, to account for the fact that the section adjacent to the progress bar now has a background color.

Some issues with this approach are that it's very divergent from the non-HCM styles, and it doesn't really allow for a border around the main section (unless we add a bottom margin to the progress bar as well, so they don't overlap). Emily also noted that with the previous example, respecting the screen's border radius makes the progress bar feel more like it's part of the screen, rather than an independent element.

Comment 16

[Shane Hughes [:aminomancer]]

Attachment: Bug 1790660 - Improve MR onboarding progress bar contrast. r=pdahiya

Comment 17

[Punam Dahiya [:pdahiya]]

Removing blocking 107 MR onboarding meta bug as the fix is targeting Fx108 and not uplift candidate

Comment 18

[Anna Yeddi [:ayeddi] ⛔ Out of office until November 12 ⛔]

Attachment: 2022-10-17_Win-HCM_Progress_meter.png

(In reply to Shane Hughes [:aminomancer] from comment #14)

Created attachment 9298004 [details]
border around main section, progress bar with no border-radius

In bug 1793401 we added a HCM-compatible background color to the illustration section, so this changes how the progress bar fits with the section to its left. But I think this would be a good opportunity to add a border to the main section, since normally (in non-HCM) the main section would be more defined with respect to the page background. I guess it's really just a coincidence that the page background and the main section background resolve to the same color in HCM. But we can work around that with a border. I think that also allows us to make the progress bar in HCM diverge less in appearance from the progress bar in non-HCM.

Thank you! The widget looks great on HCM (WinOS screenshot is attached)

Just in case, for the borders of a content sections on HCM CanvasText is usually used. Alternatively, WinOS uses thick SelectedItem border to highlight windows that are currently focused.
UPD after reviewing the patch: Exactly as you did :) It looks great!

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/525f0bfd5c55
Improve MR onboarding progress bar contrast. r=pdahiya,ayeddi

Comment 20

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/525f0bfd5c55