os-autoinst
Dark mode - Failed test modules hardly readable
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[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
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?
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.
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
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
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).
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?
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.)
so instead of the "Detect from browser" dropdown we should apply the high contrast theme, as it will better
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.
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.
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.
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.