how can we trigger the update warning during testing?

When hovering the cursor, the color of the icon merges with the background, which was not (as far as I remember) in the danger type.

I have tested this item ✅ successfully on 8d5e28e

I have tested this item ✅ successfully on 8d5e28e

RTC

this can not possibly be rtc

@brianteeman what's wrong with the PR?

#38813 (comment)

Back to pending

Please retest

I have tested this item ✅ successfully on 333b2f6

Hover icon now working. Thanks Brian!

I have tested this item ✅ successfully on 333b2f6

RTC

I think that the colors used have not enough contrast:


(I took them from the screens posted here)

Suggested colours welcome

What about this combinations?
https://medium.com/handsome-perspectives/a-guide-to-color-accessibility-in-product-design-aa3e8919be0
The second row AAA looks good to me

The background colour is NOT being defined in this PR. It is using the one defined globally in the atum template variables

I remember I researched accessible colors and set them up but it was reverted by someone else :-(

As this PR is about using the warning instead of the error I would really like to see this merged as it is and then the JAT can make sure that the core template colours are all accessible. Or the JAT can actually submit a PR

I would suggest to merge the colors first so that your PR does not bring any accessibility issues on the front dashboard.

@coolcat-creations could you make a PR? Happy to test as I agree with this PR...

I try, I don't have a dev environment because composer and npm does not work on my computer but I try to create the PR "blind" - maybe I can see then in the prebuild packages if I changed it in the correct file.

I just had a look in the github files and it's slightly more then just changing the warning color because the featured state is using warning as well, which is strange. I need a buddy to get composer running on my computer then I can do this with pleasure and fix some of the colors.

I try, I don't have a dev environment because composer and npm does not work on my computer but I try to create the PR "blind" - maybe I can see then in the prebuild packages if I changed it in the correct file.

Run my program and your worries will go away :D https://bearsampp.com/get-started Takes about 5 minutes to setup and zero "install"

I try, I don't have a dev environment because composer and npm does not work on my computer but I try to create the PR "blind" - maybe I can see then in the prebuild packages if I changed it in the correct file.

Run my program and your worries will go away :D https://bearsampp.com/get-started Takes about 5 minutes to setup and zero "install"

Thank you but I am on a Mac :) When I try to install Composer it's always complaining about missing libraries.

Thank you but I am on a Mac :) When I try to install Composer it's always complaining about missing libraries.

well darn.

Appreciate help and feedback on #38885

The WCAG 2.0 contrast checker is famously inaccurate for white-on-orange text; it's calculating pure contrast instead of perceived contrast.

While not technically WCAG 2.0, it is more accurate to test the colors in the upcoming WCAG 3.0 checker for these particular combos. (More here)[https://www.myndex.com/APCA/]

Here are the APCA results for the hover state:
(contrast okay for spot and non-text elements only)

And for the default state:
(contrast insufficient)

So the contrast definitely needs to be improved. However, I don't think that we don't have to change the colors as drastically as in #38885 in order to get it there :)

I'll comment over there also with some ideas.

So the contrast definitely needs to be improved. However, I don't think that we don't have to change the colors as drastically as in #38885 in order to get it there :)

Thanks and agreed.

I'll comment over there also with some ideas.

And/or submit a pr to this branch

if I understood this correctly this pr is not RTC right or is it better then nothing?

It will place a not accessible warning on the home dashboard. I will rework the color change PR now.

It is better than nothing and the PR proposed by @coolcat-creations is a seperate thing that will require considerable testing on its own

Please test #38885 :-)

But you introduce here to break accessibility @brianteeman ? I think the color needs to be fixed and then your PR can be merged without breaking a11y

Please also test with setting "monochrome" and changing the hue value for atum

Please also test with setting "monochrome" and changing the hue value for atum

Before and after this PR the monochrome setting makes all the icon shades so close together they cannot be differentiated

Before and after this PR the atum hue settings have zero impact on the quickicons

Not wasting my time on this.