1883948 - Searchfox's left vertical bar is invisible in High Contrast Mode (HCM) on Windows and/or with the about:preferences "General > Colors > Manage Colors... > Override the colors specified by the page with your selections above" set

Status: RESOLVED FIXED

(Webtools :: Searchfox, defect)

Description

[Calixte Denizet (:calixte)]

Attachment: image.png

STR:

• switch to HCM on Windows
• open a file in searchfox.

The vertical bar on the left is invisible and the associated popup when hovering the bar should have a border in order to avoid any confusion with the code behind it.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Thanks for filing this and with a screenshot! Accessibility is very important to searchfox!

I found the following docs that will probably be useful to improving this situation:

• https://firefox-source-docs.mozilla.org/accessible/ColorsAndHighContrastMode.html#high-contrast-mode
  • This describes where to enable HCM. On Ubuntu 23.10 using gnome-shell I found the setting under the Settings App at "Accessibility > High Contrast"
• https://firefox-source-docs.mozilla.org/accessible/HCMMediaQueries.html
• https://firefox-source-docs.mozilla.org/accessible/HCMSettings.html

Enabling HCM on linux the blame strip appears distinguishable for me on both the default "System theme - auto" and the "Dark theme". But if I go to about:preferences "General > Colors > Manage Colors..." and set "Override the colors specified by the page with your selections above" to "Only with High Contrast Themes" I see approximately what you're seeing except I see white text on a black background even in dark mode. I would be interested to know if Windows specifically has a high contrast dark mode that automatically impacts Firefox's behavior there or if you have changed Firefox's Color settings there to invert them from the default?

One testing note is that currently searchfox lacks code coverage data because of reliability problems with the upstream code coverage infrastructure, but the code coverage strip UI is probably something we should address too.

My initial thoughts here, where I'd definitely love feedback from those with more expertise on high contrast mode accessibility best practices:

• Blame hoverbox: A high-contrast specific border seems appropriate without changing the existing styling at this time to avoid interfering with (visual) muscle memory, but it likely would be worth trying to unify things when we change the blame popup styling for hyperblame.
• Blame strip: There's inherently a trade-off with options here as the point of the zebra-striping happening on a blame-change granularity is to show discontinuities in authorship while avoiding drawing the eye to the blame strip as it's secondary metadata. A possible option here is to basically do what we already do for coverage, which is to have a different visual presentation when hovered versus not hovered. An option:
  • Unhovered: A high-contrast specific border-top/border-bottom based on a sibling selector between c1 and c2 types could accomplish the high-level zebra-striping goal of trying to express delineations between blame authorship without drawing the eye too much. Left and right borders would likely make sense to provide an awareness of where the blame striping is.
  • Hovered: The c1 zebra striping could remain white while the c2 zebra striping could become black, making it easier to distinguish between the stripes than just relying on the thin border.
• Coverage strip: The design rationale here is similar to the blame strip and we already have hover logic in place to go from low contrast uncovered/hit/miss to providing more details. The existing blame strip is rather precariously thin to begin with which is not great for visibility in the first place and limits options like use of cross-hatching. One of the initial prototype options that we didn't go with was visualizing the amount of coverage as bar-width, which could still be an option if we let the coverage strip effectively go "full bleed" to the edge of the page on hover. Or that could also allow for expanding to being wider on hover with non-bgcolor as hit, bgcolor as a miss, and some percentage cross-hatched on uncovered. For unhovered I think the outline approach for the blame strip might be least bad?
  • A tentative plan for future searchfox enhancements has been to introduce different "lens" modes for searchfox source listings that could be enabled from the fancy bar. The reality is that there are a large number of pieces of data/metadata that fundamentally vary on a per-line/per-token basis and the blame strip presentation is a natural encoding for these, but it's infeasible and undesirable to show all this information all the time. So it makes sense to let users choose what they care about at a given time and activate a lens, which could potentially be sticky / global across new searchfox tabs. This can help users pick the information and visual encodings that work best for them, although we'd still want to start with reasonable defaults. (And there are of course performance implications to both the generalized DOM and the a11y tree.)

Comment 2

[Calixte Denizet (:calixte)]

Usually I use https://drafts.csswg.org/css-color/#css-system-colors where the colors change depending on the chose HCM theme.
Maybe :ayeddi will have some ideas to help to improve a11y.

Comment 3

[Anna Yeddi [:ayeddi]]

Attachment: Updated HCM styling for blame and input fields.png

Thank you for reporting it, Calixte, and for the investigation, Andrew!

The blame indications are, indeed, are not visible on the Windows 11 with the default HCM Dark Sky activated. I drafted a PR for the fix to look like attached on Win11. It should make the HCM appearance more unified across platforms.

Comment 4

[Anna Yeddi [:ayeddi]]

The PR link is: https://github.com/mozsearch/mozsearch/pull/697

Also, just in case, this palette viewer that our colleague Morgan has created could be helpful to confirm which system colors are expected to be rendered on your machine (how should they look like): https://mreschenberg.com/WebPaletteViewer.html

Comment 5

[Anna Yeddi [:ayeddi]]

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

Created attachment 9390869 [details]
Updated HCM styling for blame and input fields.png

Thank you for reporting it, Calixte, and for the investigation, Andrew!

The blame indications are, indeed, are not visible on the Windows 11 with the default HCM Dark Sky activated. I drafted a PR for the fix to look like attached on Win11. It should make the HCM appearance more unified across platforms.

Morgan, WDYT about adding only left and right borders for the blame and keeping them ButtonText for both lines of the zebra, so it doesn't look cut off a pixel here and there. And LMK if you have any other feedback on the blame and text input fields, in general. (FYI: I customized the Win11 Dark Sky theme to have ButtonFace be yellower than the default, so it's apparently not Canvas)

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

Thanks for the quick fix! I've landed https://github.com/mozsearch/mozsearch/pull/697 and applied it to the release1 web server so https://searchfox.org/mozilla-central/source/ has the CSS changes now, although you may need to force reload if you check in the next few minutes due to HTTP caching headers.

One surprising thing for me is that on Ubuntu when I enabled the high contrast mode, the background of the search box at the top of the page went from white to a light gray, which made contrast slightly worse. This makes sense since the CSS explicitly is setting the background-color to ButtonFace and https://mreschenberg.com/WebPaletteViewer.html does have a light gray color for me there. Since the "color" is ButtonText, I presume this is sufficient contrast, though. (And the screenshot in comment 3 seems like it works quite well!)

Please feel free to iterate and/or resolve as fixed as makes sense to you. If you would like, I always encourage people to send emails to dev-platform about notable and important searchfox updates and improvements to accessibility are both!

Comment 7

[Morgan Reschenberg [:morgan]]

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

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

Created attachment 9390869 [details]
Updated HCM styling for blame and input fields.png

Thank you for reporting it, Calixte, and for the investigation, Andrew!

The blame indications are, indeed, are not visible on the Windows 11 with the default HCM Dark Sky activated. I drafted a PR for the fix to look like attached on Win11. It should make the HCM appearance more unified across platforms.

Morgan, WDYT about adding only left and right borders for the blame and keeping them ButtonText for both lines of the zebra, so it doesn't look cut off a pixel here and there. And LMK if you have any other feedback on the blame and text input fields, in general. (FYI: I customized the Win11 Dark Sky theme to have ButtonFace be yellower than the default, so it's apparently not Canvas)

That makes sense to me, I'd recommend using @media (forced-colors) for these modifications instead of @media (prefers-contrast), since the former is intended to target HCMs like Windows HCM (where CSS System colors are the only colors that can be used) and the latter applies to all contrast modes including macOS's Increase Contrast (which has no such stipulations around which colors are "allowed" only that they be closer to AAA than AA)

Comment 8

[Morgan Reschenberg [:morgan]]

Attachment: macOS_increase_contrast_blame

Comment 9

[Anna Yeddi [:ayeddi]]

Thank you both for the patience and feedback - I've sent the PR with the follow up updates: https://github.com/mozsearch/mozsearch/pull/701

Comment 10

[Anna Yeddi [:ayeddi]]

Attachment: New Updated HCM styling for blame and input fields - macOS Increase Contrast

Calixte, could you please confirm the changes are appearing on your end and, if the experience is improved, to close the bug? The recent patch has merged (I am attaching the macOS Increase Contrast mode appearance with blame dialog)

Comment 11

[Calixte Denizet (:calixte)]

Yep I confirm it's a way better like this: thank you very much.

Comment 12

[Anna Yeddi [:ayeddi]]

Amazing! Thank you for reporting it :) closing the bug