Is there a particular usage for the 'high contrast' fields? If for color blindness, would it be better to set a palette for each color blindness type (dropdown with normal, dueteranopia, protanopia etc.) Considering we now have custom properties for colors, this is something that would be relatively easy.

Is there a particular usage for the 'high contrast' fields?

Just a fairly standard setting found in these type of tools

If for color blindness, would it be better to set a palette for each color blindness type (dropdown with normal, dueteranopia, protanopia etc.)

Thats the nice thing about this code approach - it is easy to enhance it - in a later PR.

@ciar4n re the colour blindness. I have searched and all I can find are filters to simulate the effect of protanopia etc which isnt what you want.

@brianteeman Don't use filters. Color CSS variables can be redefined with a class name.

Eg.

.color-protanopia {
  --atum-bg: #5f7e92;
  etc. etc.
}

Apply the above class to the body for such users requiring these colors. These will replace CSS variables defined under :root

Sorry I wasn't clear. I do not believe you can make a palette suitable for the issue. Thats one of the reasons we have the contrast rules

I do not believe you can make a palette suitable for the issue.

I can't see why not. If protanopia makes it difficult to distinguish between yellows and greens then we create a palette that avoids using both of these colors.

If increasing the contrast makes it easier for those with color blindness (very questionable), then we can assume they would simply adjust their monitor rather than messing with settings on a per-site basis.

Finally, currently this PR doesn't increase the color contrast even thou it is labeled that it does. It inverts the color which is very different.

then we can assume they would simply adjust their monitor rather than messing with settings on a per-site basis.

Personally I agree with you on this and the same applies to all the settings here. But its a fairly standard thing for this type of function and the a11y team said it was useful to have this functionality on a per site basis as well as at the browser/os level

then we create a palette that avoids using both of these colors.

If you can do that then go for it. Either as a separate Pr or as a pr to this branch

If the a11y team can define suitable pallettes for each, I will create the pr to apply them.

@ciar4n there is no team

@ciar4n I have found out how to get suitable colour palettes.

I'll get a base started in a PR.

Just seen the number of color variables we are defining. A little excessive so I would suggest we reduce these where possible. Probably best in a separate PR made first.

I would suggest only changing the colours that could have been changed in the template style. That gives us two sets

:root {--atum-bg-light: #e8e8e8;--toolbar-bg: #f5f5f5;--atum-text-dark: #495057;--atum-text-light: #ffffff;--atum-link-color: #1757a1;--atum-link-hover-color: #0a2747;--atum-special-color: #001b4c;}

and from the hue
:root {--atum-bg-dark: #6b501a;--atum-contrast: #b52c2c;--atum-bg-dark-0: #f7f7f7;--atum-bg-dark-5: #e8e8e8;--atum-bg-dark-10: #d9d9d9;--atum-bg-dark-20: #bababa;--atum-bg-dark-30: #9f9a93;--atum-bg-dark-40: #917e5f;--atum-bg-dark-50: #866832;--atum-bg-dark-70: #524214;--atum-bg-dark-80: #39300e;--atum-bg-dark-90: #252009;}

We only need to provide three options for the main color barrier types
And so far in the tests a lot of the current colours dont change

My point is that a lot of the variables are duplicates. Currently we have the following so we need to redefine every variable for each color barrier...

--blue: #1a466b;
--primary: #1a466b;
--atum-bg-dark: #1a466b;

Better the following so we only redefine --blue.

--blue: #1a466b;
--primary: var(--blue);
--atum-bg-dark: var(--blue);

If you can give me a list then I can calculate the values

Hard to say. Colors are been defined quite randomly across the template. Some colors are still hardcoded. Some by color name (--blue, --red etc.). Some by state color (--success, --warning etc.), Also a collection of unnecessary (imo) variations of the same color (--atum-bg-dark-20, --atum-bg-dark-30 etc.).

Presuming all these variables are been used, then I would say all of them.

Regarding the hardcoded color, we obviously can not redefine them. This would include elements I would expect should change color depending on the color blindness type (eg. buttons).

That's really why I suggested #26194 (comment)

Yes but most of them colors are for aesthetics only. As they already follow WCAG AA, they should not really be an issue regarding color blindness. To truly benefit color blindness we should be redefining non-aesthetic colors (button color etc.).

well I will have to leave that up to you to work out. The tool I found was https://coolors.co/

You input the color and then click on the eye icon and select the color-blindness simulator you want. It will then change the color accordingly. BUT it doesn't change the color value that is displayed :( You have to use a color picker to grab that - unless you can find the js calculation script they are using

Neat. I use coolors.co but never noticed that option.

it's certainly a hidden feature

I have tested this item ✅ successfully on 222137d

I have tested this item ✅ successfully on 222137d

RTC

I have tested this item ✅ successfully on 222137d

Thanks! @ciar4n still interested in your colour PR but looks like it's going to need another round of tweaks for the a11y issues mentioned there first

Thanks