Bugzilla

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 that's 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.)

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.)