Open Bug 1940334 Opened 1 month ago Updated 26 days ago

Browser tabs do not follow the correct HCM styles

Categories

(Firefox :: Theme, defect, P3)

Firefox 136
x86_64
Windows 10
defect

Tracking

()

Accessibility Severity s3
Tracking Status
firefox136 --- affected

People

(Reporter: nstroud, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(1 file)

Prerequisites:

Found in Nightly 136.0a1 (2025-01-07)
Turn on Night Sky HCM in Windows

STR:

  1. Follow prerequisites above
  2. Open Firefox Nightly

Expected / Actual:

The Desktop Anatomy, specifically the browser tabs, should follow the HCM styling found in the High Contrast Mode file in Figma. At this time, the styling does not match in Nightly.

See Also: → 1935275, 1928439

(In reply to Natalie Stroud [:nstroud] from comment #0)

The Desktop Anatomy, specifically the browser tabs, should follow the HCM styling found in the High Contrast Mode file in Figma. At this time, the styling does not match in Nightly.

So this is the first time I see this, or at least the first time I'm noticing that the above mockup reverses the active tab and tabs toolbar colors. I'm not sure I understand the a11y benefits of this, and it seems to break the intended visual hierarchy of the UI where the active tab is supposed to pick up the navigation toolbar colors. Do you have additional context for the mockup and why it breaks with our established design?

Severity: -- → S3
Flags: needinfo?(nstroud)
Priority: -- → P3

(In reply to Dão Gottwald [:dao] from comment #1)

(In reply to Natalie Stroud [:nstroud] from comment #0)

The Desktop Anatomy, specifically the browser tabs, should follow the HCM styling found in the High Contrast Mode file in Figma. At this time, the styling does not match in Nightly.

So this is the first time I see this, or at least the first time I'm noticing that the above mockup reverses the active tab and tabs toolbar colors.

The mockup uses SelectedItem for the background, not the toolbar colour (which I believe is something like mozHeaderBar or WindowBackground?). SelectedItem better represents (semantically) the active tab's state within the tab list of all tabs.

I'm not sure I understand the a11y benefits of this, and it seems to break the intended visual hierarchy of the UI where the active tab is supposed to pick up the navigation toolbar colors. Do you have additional context for the mockup and why it breaks with our established design?

Because each tab is a clickable control, they inherit our HCM, non-primary control styling. This means they use ButtonFace background and ButtonText foreground/border styling. They also inherit our selectable control styling, where the currently selected control gets SelectedItem and SelectedItemText colours, but keeps its ButtonFace border to indicate interaction is possible.

In general, our HCM designs will differ from the visual language presented in our non-HCM ones, since the goal of HCM is to provide semantic colouring which indicates state and actions available, however the visual language within our HCM components should be consistent. The Desktop Anatomy that nstroud linked has been workshopped with the design systems team, who have audited the design for consistency with the existing HCM library.

Flags: needinfo?(nstroud)
Accessibility Severity: --- → s3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: