User tests: Successful: Unsuccessful:
Changed Colors of Quickicons
Added chosen colors to scss vars
Pull Request for PR #38813
I changed the colors of the Quickicons to accessible colors (AAA) and followed this article for recommendations:
https://medium.com/handsome-perspectives/a-guide-to-color-accessibility-in-product-design-aa3e8919be0
I am not sure if it's ready to test yet.
If we have accessible colors for alerts they should be consistent through the system but it seems that the colors are managed also in an outside repo (https://github.com/joomla-projects/custom-elements), I am not sure how to change them there and test it.
Also I do not understand the logic behind how it was done before. I wanted to use the scss variables but they can't be used with css variables so I put in the values static. Which I think is wrong because the colors should be managed by scss variables in a central file.
Note that I changed the class of the Privacy Request Icon to simulate the warning color.
Note that I changed the class of the Privacy Request Icon to simulate the warning color.
Note that I changed the class of the left bottom quick-icon to warning for testing purposes.
Status | New | ⇒ | Pending |
Category | ⇒ | Repository NPM Change |
Title |
|
Labels |
Added:
NPM Resource Changed
?
|
I thought to make consistent AAA Colors according to the recommendations in the article. Not good? I can take the AA colors as well, but I tought the more accessible the better.
PR changes not only the colors of the group of quick icons. Lots of changes. Colors, contrast, etc.
I think you have missed the significance of @Kostelano comment
Should I aim AAA or AA @brianteeman i thought the more accessible the better. Of course changing colors to be more accessible involves changing the constrast. That's the main goal.
that is a question for the accessibility team.
the point you missed from @Kostelano comment is that this pr impacts much more tha the quickicons
I like the idea.
that is a question for the accessibility team.
the point you missed from @Kostelano comment is that this pr impacts much more tha the quickicons
Yes, because it has to fit together. I changed the color and contrast of the other quick icons as well to match the color
of the corrected quick icons. But before I don't know if we even want to make it better accessible it does not make sense to discuss the changes.
As far as I know, Joomla 4 is compliant with WCAC AA. If we want to make it AAA compliant, we should do that everywhere in the particular client (admin or site or installation) and not only at one place.
As far as I know, Joomla 4 is compliant with WCAC AA. If we want to make it AAA compliant, we should do that everywhere in the particular client (admin or site or installation) and not only at one place.
Ok, I will change the colors to the lower accessibility standard no problem
We don't promise AAA compliance, which does not mean that colours may not be AAA thats always fine and no need for discussion. I like the colours but I think that it is wrong to make some changes here and there without a concept.
The whole colour scheme was calculated carefull by @coolcat-creations - with automatically generatng a a11y colour scheme when a user selects a colour for the template.
This was dammaged during all the design chnges which followed - but the right way would be repairing the hue, then calculating the colours with better contrast.
Dear @coolcat-creations
the solution doesn't seem optimal to me.
For two reasons.
For technical reasons we should only touch _quickicons.scss otherwise we will have lots of sideeffects, we can not control
Got it, I will change it to AA colors :-)
Would suggest checking contrast with upcoming APCA formulas for more accurate visual contrast:
The biggest problem is with the warning/yellowish orange color, so I would focus on changes there that are consistent with the other red/green colors that do pass AA contrast.
For example with the quick icon, using this combo for the text and default background:
Text/icon: #db9508
Background: #fff7e8
And for the hover state:
Background: db9508
Text: #ffffff
Icon: #ebd9ae
I changed the colors to have the same smooth appeareance like before, anyway improved some contrasts and fixed the warning color. Is it ok for you now?
The entire point of the other PR was to make the message on template overrides to check "less scary" by being aa different colour to the red danger used on thingss like Update.
With this PR the difference between warning and danger is so subtle that it fails to achieve the objectives of that PR and it might as well be closed.
Initially I used different colors but people were unsatisfied that the change is too hard. Now I use the AA colors from the medium article and still not good? https://medium.com/handsome-perspectives/a-guide-to-color-accessibility-in-product-design-aa3e8919be0 What is your prefered color for warning if not orange? @brianteeman
I would have stuck to the colours that bootstrap uses https://getbootstrap.com/docs/5.2/customize/color/
I don't think that you would ever agree to change all the quickicons to this colorscheme at all. It's a way too hard change for the backend to follow this scheme and would not fit into the design.
You asked and I answered.
As I said above the whole purpose of the other PR stopping the danger and warning colours being the same was at user request that they are differentiated and the warning is less scary.
You asked and I answered.
You disagreed to the initial hard change here in the PR and now you are proposing this extrem hard color change... ?
As I said above the whole purpose of the other PR stopping the danger and warning colours being the same was at user request that they are differentiated and the warning is less scary.
Yes and you introduce a style which is not accessible anymore. I try here to help your PR and you put stones into the way.
I am just going to close my PR. Not wasting any time on it.
Moving forward with this PR I hope you follow the advice from @angieradtke to only change the quickicons file
And my request that you uses lowercase for css colours as used everywhere else
I will see if I can suggest some colors that are well differentiated but still accessible as well as solve the monochrome issue. Taking a look now...
Title |
|
@brianteeman I changed the colors like you suggested, is it ok for you now?
I will see if I can suggest some colors that are well differentiated but still accessible as well as solve the monochrome issue. Taking a look now...
Thank you!
@coolcat-creations Please fix the SCSS code slyte errors reported here by the linter (npm run lint:css
): https://ci.joomla.org/joomla/joomla-cms/58546/1/25
npm run lint:css
thank you, done!
Elisa, I haven't been keeping close track of your changes so APOLOGIES if this is backtracking.
Checking the contrast on the success, info, and danger styles, it appears to be okay for AA standards. The issue is that warning and danger are styled the same.
Here's what I'd suggest that keeps the colors the same for the other quick icons and makes warning styled in a similar way and also large enough contrast for fluent text by APCA contrast checking (since that's more accurate for orange/yellow tones).
The colors used here for the warning styles are:
#FBF7EF
#A4740B
#FDC855
#CC8C04
#FFFFFF
(same as other quick actions)Here are screenshots of the APCA contrast checker for those values for the text:
Note that for both of those the contrast is rated at 'fluent text okay'.
Here's some colorblind simulators also of the current and suggested colors:
It's not perfect, but it's better than warning and danger being exactly the same.
Another problem (for another day) is conveying meaning through color only, but that is for a different issue I think. Progress over perfection.
Regarding monochrome, I don't think that we can solve that just by tweaking colors. There's very little differentiation as it is between quick actions in monochrome so I'd suggest focusing on that when we figure out conveying meaning through color only as we are doing now.
@crystalenka just one suggestion would be to make the joomla Icon color the same as the font color to make it more solid? What do you think?
@brianteeman are you ok with the proposed colors by @crystalenka and my suggestion for it? then I will change it accordingly.
The icon color can maybe be a little bit darker but I wouldn't suggest using the same color. The other quick icon styles do not use the same color (it's an optical illusion) and this works to our advantage for the warning styles because it makes the text color "feel" more yellow even though it's really brown. Also the current pattern uses the same color for the icon in the base and hover styles so it needs to show up against both backgrounds
@coolcat-creations how about #E5B448
for the warning icon? It's a bit closer to the pattern of the other quick icons.
@chmst @joomla/joomla-accessibility-team-jat
Would the colors I suggested (copied again here, screenshot available in last comment) be okay by you/the JAT? The warning styles don't work for AA but they do pass the APCA rating for fluent text.
The colors used in the screenshot above for the warning styles are:
#FBF7EF
#A4740B
#E5B448
#CC8C04
#FFFFFF
(same as other quick actions)All other quick icons can remain the same in my opinion as they pass AA rating. And they are no better/worse in monochrome than the current solution so we should maybe address issue of using only color to convey meaning in a different PR/discussion.
@crystalenka your suggestion is good. We can follow the information in #38885 (comment).
We must not care about monochrome, as the information in the buttons is textual and at least readable, the information depends not only on colour.
Thank you all for your commitment and patience! Especially @coolcat-creations
Thanks for your help @chmst, @crystalenka, @brianteeman, @angieradtke, @richard67 - Now I think its finally ready to be tested :-)
I wanted to test it, but the download assembly broke. Please fix who knows how.
I wanted to test it, but the download assembly broke. Please fix who knows how.
@Kostelano Fixed.
Dear @coolcat-creations the solution doesn't seem optimal to me. For two reasons.
- Your colour adjustment brings some unrest into the design. You are using colors we not used before.
- The red and green of the font, as we have it now, is ok in terms of contrast, only the icons could be a little stronger.
For technical reasons we should only touch _quickicons.scss otherwise we will have lots of sideeffects, we can not control
and lots more examples
@brianteeman thank you for your test!
I removed the changes of existing colors in the variables file as requested.
I left the alert colors in the variables file so they can be reused in future PRs - for example alerts should use the same colors in a consistant way.
Any wishes for this PR or can it be final test and merged?
I had suggested some alternative colors/design pattern somewhere but I am not finding it now (so that it would be clearer and also more accessible). I will go look for it and see, I'm not sure if that was communicated to you or not, sorry
Possibly you have to expand older comments when they are collapsed by default.
So it was under discussion in the JAT channel in Glip last month but two conversations were going on at once and I think we lost track a bit.
Here was my final suggestion to meet WCAG 2.1 AA or even AAA requirements for these items:
Here's what I said at the time:
It's significantly different from the current hover state but gives us more flexibility with colors and means that the contrast there far exceeds WCAG 2 AAA requirements.
This pattern actually improves the contrast ratios for all four quickicon styles, some of which are currently barely passing WCAG AA
I think it would work for all the quick icons; we could refine these colors to be the ones we’re already using elsewhere so there is more consistency (just using approximate values now) and the biggest improvement in this pattern in my opinion is that it drastically improves the legibility for several different kinds of color blindness
@chmst do you remember if JAT reached a decision if this pattern is okay?
@crystalenka that looks soooo nice
Ok I will change it to the colors, :-) do you have the exact values? If not, I will screen capture it with my color doggy :-)
I think I have them somewhere, but would be better to use existing variables if we can! Are the existing success/danger/etc variables far off?
If it helps, here are the values I used there:
For all styles:
Success:
#F3F9F3
, same as existing#457D54
, same as background used in existing hover style#E2FFE2
Info / Default:
#F3F7FD
, same as existing#486285
, same as existing#DFECFF
Warning: (if there are existing variables that are close to this then use those)
#FBF7EF
#F1A505
#FFF3D9
#AF7D0F
Error:
#F4F0F0
(same as existing)#C52927
(same as existing danger hover background)#FFE9E9
Eek. Let's set that to black then for maintained legibility.
Eek. Let's set that to black then for maintained legibility.
On the whole dashboard then, or only in those alert boxes?
Just those alert boxes right now. I think in J5 we will have a better opportunity to refine the base styles/color variables in the template as a whole.
Oohhhhhhh I see what you mean.
Are the hover styles for the normal quick icons affected by this PR or do they still inverse?
Oohhhhhhh I see what you mean.
Are the hover styles for the normal quick icons affected by this PR or do they still inverse?
They were affected but now not anymore :-)
BTW this needs to be rebased on 4,3 not 4.2
and please address the code style issues highlighted here https://ci.joomla.org/joomla/joomla-cms/59815/1/25
So should I change the info classes to black, right? This will affect the whole dashboard. @brianteeman @crystalenka
I think affecting the whole dashboard is okay at this point. It will be consistent with each other and more accessible as a whole.
This pull request has been automatically rebased to 4.3-dev.
Title |
|
Labels |
Added:
a11y
bug
RMDQ
PR-5.0-dev
Removed: ? |
Title |
|
Title |
|
No prebuilt packages are available for download.
Sorry, saw to late This branch has conflicts that must be resolved.
No prebuilt packages are available for download.Sorry, saw to late
This branch has conflicts that must be resolved.
It needs to solve a conflicting file and updatethe branch.
This was added to the RMDQ almost 12 months ago. No point in @coolcat-creations wasting time on it until they make a decision to either accept or reject this change
I think it was also meanwhile changed in the template itself - i would tend to close it?
@coolcat-creations It's been 2 years since you opened the PR. I also see hardcoded color values, which I would consider as not good... Do you want to keep this open and work on this further or should we close this?
Closing as stated in previous comments #38885 (comment) and #38885 (comment) .
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2024-11-24 19:48:09 |
Closed_By | ⇒ | richard67 | |
Labels |
Added:
PR-5.2-dev
Removed: PR-5.0-dev |