Improve color contrast on preferences panel #54
Conversation
pocka
left a comment
There was a problem hiding this comment.
Do the link texts reflect embedder's (containing page's) style? For example, when an embedder has a { color: #f00; } the link should be #f00 instead of browser default. I'm not familiar with system colors in that situation, just wondering. Perhaps :where(a) { color: LinkText } (without media query)?
If "embedder's style and fallbacks to browser default" is impossible, we need additional CSS custom properties.
As for the checkmark graphics, I intentionally made the color barely visible.
- Distinguishing black-ish color and green is difficult, at least for me. The selected one does not stand out.
- They are purely aesthetic elements and don't (shouldn't) convey semantic meaning.
It should not have readable contrast. Increasing contrast or hiding them when a user requested more contrast ( (prefers-contrast: more)) would be reasonable, though (because user may dislike low contrast.)
|
Thanks for the context on the checkmarks.
My concern here is that the do seem to convey semantic meaning because they are displayed in two different states, one where it is selected and another is not. In my opinion, they are conveying meaning and are worth making visible, but I think you can technically argue they are non-essential according to WCAG since a graphical element is essential if "if removed, would fundamentally change the information or functionality of the content", and you could remove the check mark and it's absence would still convey not being selected. Also the outline around the selected option could be considered the primary method for identifying the selected option. I will revert the opacity change, but maybe the checkmark should be removed altogether if it's difficult to distinguish between the selected and non-selected state. Also we should likely make the checkmark |
It currently does, but would not with the system colors. My situation was an issue because we are embedding it on a page that does not set a link style nor has a dark mode where it changes the default link style. So the link is inheriting the embedder's style, I think in this case it's fair to say the embedder should handle this case, though it may be nice to be able to turn off the dark mode if the embedder is using it in a situation where dark mode is not yet supported. |
|
Closing this as I don't think anything here should be merged based on the discussions above. |
Small changes to improve color contrast of links in dark mode and the unchecked checkmarks for the
choicecomponent.The link style was not being changed in dark mode which results in the browser default, I've set the link and visited link color to use
LinkTextandVisitedTextrespectfully when the user prefers dark mode.The uncheck check mark's opacity of 0.15 was placing it outside of WCAG 2.1 AA guidelines for contrast of graphical elements (3:1) for both light and dark modes. Setting it to .7 brings it above 3:1 for both light and dark modes
master
this branch