Actual
Secondary text color = color-mix(in srgb, currentColor 80%, transparent)

Expected
Secondary text color = color-mix(in srgb, currentColor 60%, transparent)

This should be applied on new tab page and on Fx View for consistency

(In reply to Josh Berman from comment #0)

Actual
Secondary text color = color-mix(in srgb, currentColor 80%, transparent)

Expected
Secondary text color = color-mix(in srgb, currentColor 60%, transparent)

This should be applied on new tab page and on Fx View for consistency

This carries risk for not meeting a11y standards with some of our themes and probably even more so with third-party themes. I'm skeptical that we should do this for text that's just "secondary" rather than disabled. Have you or could you please evaluate potential a11y implications here before we implement any change?

Adding a11y team to this bug for feedback.

Can you please link a figma spec or provide more information in the bug description? Ideally I'd like to see screenshots of the current vs. expected behaviour and contrast ratios of each.
I don't know what this change is in reference to.

I assume the perf:frontend keyword was added accidentally...

I'll evaluate further and get back to you with more information. Thanks for raising these concerns.

Good call on the contrast - It's an issue in dark mode. If we bump it to 70% and split the difference it does still pass everywhere and gets us closer to our spec'd secondary text color. That sound good?

Josh, can you add a link to the Figma spec for Morgan?

Hey Ray,

I have no way of creating these colors except by using dev tools to apply the new equation on the Fx View page and inspecting the color. Any figma representation I have will be inexact.

If you want to use devtools, the code would be

color: color-mix(in srgb, currentColor 70%, transparent)

I was applying this to a header element to allow me a larger surface area to color pick and then running the background and foreground colors through webaim contrast checker. At 70%, every foreground/background combination is above a 4.5:1 contrast ratio.

Morgan, I'd also be happy to connect with you and just walk through this live and we can discuss. Let me know.

:Josh, could you attach a screenshot of the current behaviour vs. the new proposed behaviour?

As long as the contrast ratios pass AA for the text size they're on, I think we're fine. Does this change modify how the text is displayed in HCM, too? We'll need AAA ratios there.

I just tested in HCM and it doesn't modify the text color there.

I did my best to put together a figma file that represents the modification in behavior for default light theme, dark theme as well as various colorways as best as possible. At 60% we were under AA in dark theme by .3 and just under AA in some soft colorway themes by .01. At 70% we are AA compliant in default light/dark and existing colorway themes.

https://www.figma.com/file/SE4xHgOW84yLiv7vFugm9R/Firefox-View-Stepping-Stone?node-id=13033%3A154291

(In reply to Josh Berman from comment #11)

I just tested in HCM and it doesn't modify the text color there.

I did my best to put together a figma file that represents the modification in behavior for default light theme, dark theme as well as various colorways as best as possible. At 60% we were under AA in dark theme by .3 and just under AA in some soft colorway themes by .01. At 70% we are AA compliant in default light/dark and existing colorway themes.

https://www.figma.com/file/SE4xHgOW84yLiv7vFugm9R/Firefox-View-Stepping-Stone?node-id=13033%3A154291

Thank you for creating the mockup with examples, Josh! In the file, I added comments with actual color contrast ratios and if they pass/fail the AA and AAA conformance levels and noted when they're acceptable for HCM too (when they pass AAA):

1. It looks like the current 80% is the best because it passes everything for AAA and would be acceptable for HCM themes too.
2. But even 70% does not fail AA - the secondary text still provides contrast ratio of above 4.5:1 (all were 6+), which is accessible for non-HCM themes, while the default Dark theme and Active colorway provide HCM-friendly contrast as well.
3. I haven't seen in the Figma file any 60% examples, but per your comment, this would introduce AA fails which is an accessibility issue per WCAG for standard sized text. To make it compliant, text could be made larger (24px and up) or the text could be 18.5px or larger when it is bold - then the 3:1 contrast ratio is considered acceptable for a text. Otherwise, all text should be 4.5:1 to be Level AA compliant.

Josh, based on Anna's comment, what's the final UX guidance on what, if anything, we want to change here? :-)

I'm comfortable saying we move forward with this solution (#2 from Anna's comment) which passes AA but does not pass AAA.

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

2. But even 70% does not fail AA - the secondary text still provides contrast ratio of above 4.5:1 (all were 6+), which is accessible for non-HCM themes, while the default Dark theme and Active colorway provide HCM-friendly contrast as well.

That said if Anna feels strongly we should be AAA compliant then let's leave as is.

While AAA compliance is always most preferable one, having AA compliant colors is sufficient for default themes (non-HCM).

On Windows HCM though the higher transparency fails AAA (which is required when prefers-contrast / HCM enabled) when it's reduced to 60% the Recently Closed secondary text fails AAA for a regular text - see the screenshots attached to compare 70% vs 60% transparency on Windows 11 Night Sky HCM. Maybe we can add a query to have 100% opacity when on HCM?

It passes on macOS, because the Increase contrast mode (OS HCM) auto-enables Reduce transparency which resolves issues like this.

Ok, let's do 70% which passes in HCM at AAA but let's still add a query to have 100% opacity when on HCM. That makes sense to me.

(In reply to Josh Berman from comment #17)

Ok, let's do 70% which passes in HCM at AAA but let's still add a query to have 100% opacity when on HCM. That makes sense to me.

Awesome, thank you, Josh!

Backed out for causing new failures on _theme.scss.

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL sasslint | content-src/styles/_theme.scss(97, 69): No double semicolons allowed (trailing-semicolon)

Patch updated with extra semicolon removed. Waiting for review.

https://hg.mozilla.org/mozilla-central/rev/3897a899d50f

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit auto_nag documentation.

The patch landed in nightly and beta is affected.
:kcochrane, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox107 to wontfix.

For more information, please visit auto_nag documentation.

Seeing unchecked-in changes in respective activity-stream-[os] CSS after running npm run bundle --prefix browser/components/newtab on latest central most probably due to changes in the patch , will be great if you can address by landing followup patch with fix thanks!

Sorry I wasn't aware of the process for those files, but I just submitted a follow-up patch to hopefully resolve.

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)

https://hg.mozilla.org/mozilla-central/rev/3a885a0f862f