1795723 - [HCM] Unified Extensions Panel to support High Contrast Mode

Status: RESOLVED FIXED

(WebExtensions :: Themes, defect, P2)

Description

[Anna Yeddi [:ayeddi]]

Attachment: No change in the appearance when an Increase Contrast is activated.png

STR:

1. Open Firefox and navigate to the unified extensions panel
2. Open an extensions panel and review the appearance and colors of the panel items
3. Activate a High Contrast Mode of the macOS by checking Increase Contrast option under System Preferences > Accessibility > Display > Display
4. Return to the Firefox and review the unified extensions panel again

Expected:

1. Color contrast is increased, providing at least 7:1 contrast ratio between all text and its foreground

Actual:

1. No change is made with and without Increase Contrast modes.
2. Subtitle test has insufficient color contrast of 5.8:1 against their background:
   • Foreground: #C2C3C8
   • Background: #42404C

System: macOS 12.6
Browser: Fx Nightly 107.0a1 (2022-10-17) (64-bit)

Comment 1

[Morgan Reschenberg [:morgan]]

In addition to the things Anna has mentioned under Actual in #c0, I'd recommend:

• Increasing the contrast of the <hr> elements within the panel
• Adding a 1px solid border around the icon buttons
• Adding a 1px solid border around the panel itself
• Modifying the background color of disabled elements in addition to their text color, to make them more distinguishable from enabled elements

Comment 2

[Anna Yeddi [:ayeddi]]

Attachment: HCM_extensions_panel.png

Adding the Windows OS screenshot with and without HCM theme (Dark) enabled.

Active buttons like gear image buttons and Manage extensions button on the screenshot included and, whenever an extension appears to be enabled in the menu, extension button should provide the following semantic styles when an HCM is enabled. Each button should have:

• a border (as Morgan pointed out in the comment above), color ButtonText
• background with ButtonFace color
• foreground (label text and icons) with ButtonText color
• when hovered, button color pair is changed to a selected item color combination (ButtonText to SelectedItem and ButtonFace to SelectedItemText

For inactive buttons the color pair to be used is: GrayText for the foreground and Canvas for the background.

Static text like the Extensions heading to use Canvas with CanvasText colors.

Visual reference could be found in this Figma file - it includes both dark and light HCM for both Win 11 and Win 10 look and feel examples for ease of testing/referencing and in the Engineering HCM info on Wiki. Let me know if more info on the HCM can be helpful.

Comment 3

[Julian Gaibler]

Attachment: downloads-comparison.png

We can probably style it after the downloads panel, right?

Comment 4

[Morgan Reschenberg [:morgan]]

(In reply to Julian Gaibler from comment #3)

Created attachment 9301823 [details]
downloads-comparison.png

We can probably style it after the downloads panel, right?

wooo yes perfect :)

Comment 5

[William Durand [:willdurand]]

Attachment: WIP HCM

Hi Anna, thanks for the extra information. I started to make changes to support HCM (locally) and I am wondering if the attached screenshot looks good. WDYT?

AFAICT the color for the secondary text (below an extension name) is yellow because that is set to GrayText. Also, should the dot color be GrayText too? I set it to ButtonText currently.

Comment 6

[William Durand [:willdurand]]

Some more questions (sorry):

• In Julian's screenshot/proposal above, the primary button is only "more visible" on mouse hover (which is also shown in the left side of the screenshot in comment 5): shouldn't we treat this button as the other (menu) button instead?
• Comment 2 seems to show a screenshot with HCM disabled and a dark theme. My understanding is that HCM is its "own thing" not tied to dark theme, for which we don't have great support in the unified extensions panel at the moment. Is this bug only about adding support for HCM? If so, it'd be good to have a new bug for dark theme support/enhancement.

Comment 7

[William Durand [:willdurand]]

Attachment: Screenshot 2022-11-10 at 14.57.00.png

What I had in mind for the first question in Comment 6, though that looks bad on hover...

Comment 8

[William Durand [:willdurand]]

Attachment: Bug 1795723 - Unified extensions UI should support High Contrast Mode. r?ayeddi!,dao,Itiel

Comment 9

[William Durand [:willdurand]]

I submitted a patch with a refined version of what the screenshots attached in Comment 7.

Comment 10

[Anna Yeddi [:ayeddi]]

(In reply to William Durand [:willdurand] from comment #5)

Created attachment 9302839 [details]
WIP HCM

Hi Anna, thanks for the extra information. I started to make changes to support HCM (locally) and I am wondering if the attached screenshot looks good. WDYT?

AFAICT the color for the secondary text (below an extension name) is yellow because that is set to GrayText. Also, should the dot color be GrayText too? I set it to ButtonText currently.

Hi William,
Thank you for working on the patch!

I think for the secondary text the approach on HCM would be:

• when the control is actionable (not disabled) - use ButtonText for it still (with the ButtonFace as a background). Here we want to show the user that they can, in fact, activate the control by clicking on this text too, to communicate the item's semantic rather than an aesthetics.
• When this extension is actionable but clicking on the secondary text won't activate anything - use CanvasText with the Canvas as a background. This will provide to a user a hint that while this text is not functional, the button itself would work when clicked and the secondary text will still be readable.
• When an item is disabled and clicking on the text won't activate anything too - use GrayText with the Canvas as a background. This will say to the user that the control is inactive altogether.

(In reply to William Durand [:willdurand] from comment #6)

Some more questions (sorry):

• In Julian's screenshot/proposal above, the primary button is only "more visible" on mouse hover (which is also shown in the left side of the screenshot in comment 5): shouldn't we treat this button as the other (menu) button instead?

Great catch! Yes, we should follow the menu buttons styling. Ideally we'd have these adjacent controls individually styled as buttons, meaning:

• Be ButtonText + ButtonFace pair-colored
• Have a border with the foreground color
  This would show to the user their semantic, as they are individually actionable buttons. As the HCM is user-activated theme, we need to respect the user's request for a semantic styling (their color selection of ButtonText with ButtonFace and SelectedItem with SelectedItemText) and a border for all controls instead of preserving visual styling.

Just in case, this is a HCM reference to hover indication of adjacent buttons example.

• Comment 2 seems to show a screenshot with HCM disabled and a dark theme. My understanding is that HCM is its "own thing" not tied to dark theme, for which we don't have great support in the unified extensions panel at the moment. Is this bug only about adding support for HCM? If so, it'd be good to have a new bug for dark theme support/enhancement.

This is correct. I just wanted to show that there are no specific changes provided for the HCM view, when it is active, and used the default/non-HCM view as a benchmark to compare the HCM with. Thank you for clarifying this!

I'll be reviewing the patch shortly.

Comment 11

[Anna Yeddi [:ayeddi]]

Attachment: 2022-11-15 Win HCM panel.png

This is how the panels looks with the most recent patch version on WinOS - r+ed from the a11y/semantics side.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a3d07cfd33de
Unified extensions UI should support High Contrast Mode. r=ayeddi,desktop-theme-reviewers,dao

Comment 13

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/a3d07cfd33de