Popup & settings page: partial support for forced colors mode (high contrast) - #9153
Popup & settings page: partial support for forced colors mode (high contrast)#9153mxmou wants to merge 6 commits into
Conversation
DNin01
left a comment
There was a problem hiding this comment.
Tested on Edge 151 using the page colors accessibility setting.
| .color-container { | ||
| forced-color-adjust: none; | ||
| } |
There was a problem hiding this comment.
This style rule applies to all elements inside the color input, including the color picker, preventing it from being fully accessible. This should be applied only to the color input, color well, and sliders.
There was a problem hiding this comment.
I don't think it's possible to do that - those elements are in the picker's shadow DOM and are only affected by style elements inside the shadow root.
There was a problem hiding this comment.
I meant by modifying the color picker component's own stylesheet to make the color well and color sliders appear as normal while all of its other elements are adjusted by the browser.
If you were talking about the forced-color-adjust property, it does affect the shadow root's elements, strangely. It's probably being inherited, because when I remove the property, everything in the color picker reverts to your "before" color picker screenshot. Knowing this, the effect could be counteracted with this style rule:
color-picker {
forced-color-adjust: auto;
}There was a problem hiding this comment.
The file you linked is a minified library that isn't meant to be edited directly.
There was a problem hiding this comment.
We could still do one of these things:
- The JavaScript is minified, but I don't see a problem with modifying the template literals that encode the stylesheets used by this library's components.
- Since the components are open shadow roots, their shadow DOM can be modified from the outside after insertion, allowing non-library code to patch in additional CSS.
- We can switch to a different color picker library.
- We can save this for a different PR.
There was a problem hiding this comment.
- We can switch to a different color picker library.
- We can save this for a different PR.
I think we need to switch a different color picker anyway (the current one has quite a few bugs), but that can be done in a future PR.
There was a problem hiding this comment.
Other than forced colors not being applied to the color picker, I think this is an improvement.
I kind of wish, though, that fewer of these forced-colors media queries had to be used. Perhaps setting different values for the CSS variables in the colors.css file when forced colors are active would help save some lines of code now and in the future? Just an idea. Kinda difficult without a refactor, though.
|
@Samq64, you might be interested in testing and reviewing this. |
| @media (forced-colors: active) { | ||
| .icon-button { | ||
| background-color: ButtonFace; | ||
| outline: 1px solid ButtonBorder; |
There was a problem hiding this comment.
Button outlines don't change color when focused.



Changes
Fixes some issues in the extension UI that made it difficult to use when the forced colors mode was enabled. Side-by-side comparison on Edge:
The full settings page looks like this:
And with a light color scheme (the default one on Firefox):
Known issue
A remaining issue is that icons don't have the right color (they might even be invisible, as seen in the screenshot above). This could be solved by using an icon font, as suggested in #1220, or inline SVGs, as suggested in #4989.
Testing
There are several ways to turn on forced colors when testing these changes: