Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dark mode - Failed test modules hardly readable #4875

Open
ggardet opened this issue Oct 28, 2022 · 14 comments
Open

Dark mode - Failed test modules hardly readable #4875

ggardet opened this issue Oct 28, 2022 · 14 comments
Labels

Comments

@ggardet
Copy link
Contributor

ggardet commented Oct 28, 2022

In Dark mode, the failed tests are not readable, we should use different colors.
See the screenshot

@okurz okurz changed the title Dark mode - Failed tests not readable Dark mode - Failed test modules hardly readable Oct 28, 2022
@stale
Copy link

stale bot commented Mar 18, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Mar 18, 2023
@Martchus Martchus removed the stale label Mar 18, 2023
@Martchus
Copy link
Contributor

also see openSUSE/mentoring#202

@Lokeshsri11
Copy link
Contributor

Lokeshsri11 commented Apr 11, 2023

I think the skipped modules are also not easily readable due to similar issues the color contrast of palette.
Do we have the option to change the colors of the palette, or should we only focus on fixing the contrast color?

@Martchus
Copy link
Contributor

I would generally avoid changing the colors of states/results. However, if it is not possible we can likely chose a different color that is in-line with the ones used in the normal/bright theme.

@Lokeshsri11
Copy link
Contributor

I read about color contrast and some research, which states that text with (AA) accessibility level should have a ratio of 4.5:1, and text with (AAA) accessibility level should have a ratio of 7:1 for good accessibility so to solve this issue without making major changes, we need to replace the red color with brick red, which is represented by #CC3333, and use white text for both dark and light modes. Additionally, we need to change the skipped text color to black

@Lokeshsri11
Copy link
Contributor

Screenshot 2023-04-12 115327

The old normal red color may pass the color contrast test for large text, but the brick red color (#CC3333) would ensure that the color contrast meets accessibility standards for all text sizes

@Martchus
Copy link
Contributor

would ensure that the color contrast meets accessibility standards

I'm not sure whether our normal light theme needs to meet all accessibility standards. The same counts for the "normal" dark theme. They should be nice looking and the average user should be able to read the text. We might want to avoid changing colors of states/results here to avoid confusing our existing user base. When it comes to the dark theme we still need to fix some very problematic pages, though.

For tweaking accessibility further to meet higher standards I suggest one create a separate theme (besides the normal/light and the dark theme), e.g. a "High contrast" theme. Developing this as a separate theme has the big advantage that we can also do changes in a much more experimental way and don't need to care much about confusing existing users (and if users opt-into the high-contrast theme they supposedly don't complain about colors changing more radically).

@Lokeshsri11
Copy link
Contributor

The idea of a high contrast theme is great as it won't bring any changes for existing users, and the high contrast theme would be suitable for visual aesthetics. However, if the color of palettes and other visual elements of the high contrast theme are changed, would it cause any issues?

@Martchus
Copy link
Contributor

Martchus commented Apr 12, 2023

However, if the color of palettes and other visual elements of the high contrast theme are changed, would it cause any issues?

I'm not sure what you mean. The high contrast theme would of course use a slightly changed color palette, isn't that the whole point of it? The only issue with that is that users who select the theme need to get used to it but since it is an opt-in I suppose that is ok.

By the way, there's already a drop down menu on https://openqa.opensuse.org/appearance so I suppose adding an additional theme should be low effort at this point. The drop down item that is currently "Detect from browser" should likely be rephrased as "Light/dark depending on browser settings" when adding a third theme like a high contrast theme. (Unless we could also detect whether to use the high contrast theme from browser settings.)

@Lokeshsri11
Copy link
Contributor

so instead of the "Detect from browser" dropdown we should apply the high contrast theme, as it will better

@kalikiana
Copy link
Member

I wonder... when you say "high contrast" I would probably expect a very different theme to the ones we have now. We can still tweak the existing colors to increase contrast as mentioned by example of the color "red" above, though? Popular themes like Solarized and many others follow this approach these days where the entire color palette has a certain contrast ratio. The colors wouldn't need to change much.

Alternatively I would suggest we actually pick existing themes that have solved this problem and were designed with that in mind.

@Lokeshsri11
Copy link
Contributor

Yes, so I think it's right, let's make a different theme, which will be completely color-blind friendly and if you want, we can also make light changes to the current theme, as I said, black text on white color palatte and brick red instead of red.

@Lokeshsri11
Copy link
Contributor

Lokeshsri11 commented Apr 15, 2023

Please have a look, I have made some changes.
black text on skipped palettes and red color changes to brick red and also I will start working on another newly theme, which is color-blind friendly.
2023-04-15

@stale
Copy link

stale bot commented Aug 12, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Aug 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants