The discussion revolves around the $primary-medium SCSS variable and its generated color not passing accessibility guidelines. Phillip_Rooney is facing this issue and wants to override the variable, but awesomerobot explains that currently, there’s no direct way to do so due to the automatic generation of secondary variables.
awesomerobot suggests that an advanced color scheme editor could be a potential solution in the future, but notes that it would still require some custom CSS. The primary issue is text contrast for accessibility, and the team plans to look into improving default text accessibility. Phillip_Rooney confirms that accessibility is a top concern due to the product being used in a governmental context.
In the meantime, wadestriebel provides a workaround by adding a custom CSS code to override the $primary-medium variable. The code snippet is:
:root {
--primary-medium: #666666;
}
I have a default primary colour: #4d238c. The issue is: the color for $primary-medium being generated (#a179de) doesn’t pass accessibility guidelines, so i need to make it darker.
It seems laborious to change it in all places where the system is using the medium colour when I could just over write $primary-medium to be red say for example
Yeah totally understand this, at the moment there’s no way to directly override any of the secondary variables we automatically generate because those are all set in stone when the CSS is built. So in the short term, you will need to manually make these changes.
Some explanation:
The color schemes are meant to be a super-simple way to define colors, and anything more specific than that needs to be custom CSS. This was discussed a bit more here: Customizing colors - #2 by awesomerobot
Some things for us to think about:
I don’t think an advanced color scheme editor that grants access to override those secondary variables would be a bad idea, but because they’re used so broadly you’d likely need to write some CSS anyway.
So for example… you might want to override all text occurrences of $primary-medium… but it’s also in places for borders and other elements where the higher contrast $primary-medium wouldn’t be desirable. So at best an advanced color editor would reduce the custom CSS needed, but wouldn’t eliminate it entirely.
That being said… the primary issue here is text contrast for accessibility, right? Our default styles do fail for text contrast in some areas, and it’s possible that if we improve there this wouldn’t be a problem for you to begin with…
So I think in the near future our team can look at default text accessibility, and further down the road we can look at improving our color scheme tools to consider accessibility (https://cloudflare.design/color/ is cool experiment that factors in text contrast, for example).
Hey Kris
Thanks for the reply so quickly.
Yes, our primary concern is accessibility as we are using your product in a governmental context.
I have worked around the accessibility of the contrast in a step by step manner, but as discussed it would be good to have the default colours accessible.
The site however is not just failing on contrast e.g. other often failing elements are - ( List items ( <li> ) are not contained within <ul> or <ol> parent elements.)
But at the moment contrast is all i can control so its fine for now until a fix is put in place.
We stumbled onto this thread because of a similar issue, we solved it with a workaround by adding the following to the theme’s common css:
:root {
--primary-medium: #666666;
}