Claro Shortcuts star fails WCAG Use of Color and Non-text contrast

My mistake on tagging this 131. I should have gotten back to Andrew on that sooner.

I'm going to try to move the MR forward a little.

Adding Needs issue summary update because the IS mentions IE11 and AFAIK Drupal dropped support for IE11.

There were merge conflicts when updating the existing MR branch, so here's a new MR against 11.x.

Some comments

1. I went back to the non-concentric fill for the "remove" states as specified by @ckrina's comment #16.
2. For the "add, hover" state, the previous MR had a solid fill for forced-colors: active.
   That wasn't in @ckrina's screenshots, and due to the + above the star in the Claro icons I wondered if it is necessary. So I left the fill empty for now as shown in the screenshots.
3. Inside the CSS url() function, the SVG with a forced-colors: active media query embedded in a style element did not display the LinkText color as expected.
   However, there are many instances in core of using mask-image for forced-colors: active, so I went with that method.
4. For the time being, I've put the same icons into both Claro and the shortcut module.
   I suggest creating a lower-priority followup to refine the shortcut module's icons since they'll appear on Olivero (which has different blues).

These screenshots are from Mac Firefox in standard mode and with browser.display.document_color_use set to 2.

Needs manual testing with & without forced-colors / WHCM. I will update the IS with details.

kentr → changed the visibility of the branch issue-3171726 to hidden.

kentr → changed the visibility of the branch 3171726-claro-shortcuts-star to hidden.

Have not reviewed but previously tagged for issue summary update

Tried to cleanup what I assume are old tags.

I'm working on the IS update.

Updated the IS, included testing notes, and attached the screenshots that didn't save for #57.

Forgot to change status / remove IS update.

Before

After

Does appear to address the failure

Waiting on a maintainer to make sure they're fine with the color change.

Actually see in #6 ckrina gave the thumbs up.

@smustgrave I think the version here is different than what @ckrina was thumbing up in #6.

There were several iterations. The latest before I worked on it had the "concentric" stars. I didn't use that version because of @ckrina's comment in #16 🐛 Claro Shortcuts star fails WCAG Use of Color and Non-text contrast Needs work :

Once zoomed, I do like the star inside the star emulating the radio styles, but at a smaller size (like the one we're using) it can look blurry or too "crowded". It would also introduce changes on the SVG depending on the size because a 2px spacing might be too much in smaller icons vs too small on the bigger ones, and I'd try to avoid that if possible. I think the contrast with the blue filled vs non-filled grey when it's not saved should be enough:

My version is closest to @ckrina's screenshots in #16. I added the little "+" and "x" in the corners of the hover versions.

Changed back to NR just in case.

hm that is odd, i've tested MR11498 in Edge with high contrast mode on macos sequoia, the star in the screenshot in #58 🐛 Claro Shortcuts star fails WCAG Use of Color and Non-text contrast Needs work looks okay to me, but in my own testing the star is barely visible in each of the two states.

unchecked:

checked:

Followup for #68 🐛 Claro Shortcuts star fails WCAG Use of Color and Non-text contrast Needs work . The reason why the two star states were barely visible was my usage of the "enable automatic dark mode" setting in the edge rendering tab. Even though it uses also prefers-color-scheme: dark it is still behaving off. @kentr and I had a discussion and some further digging over in: https://drupal.slack.com/archives/C2ANFUGGG/p1746978093222529

We still dont know the exact reason why the "enable automatic dark mode" setting is behaving differently output wise, but the following pen @kentr created illustrates the behaviro pretty well between the two approaches: https://codepen.io/kentr/full/XJJyerz (...and narrows down the cause to the color-scheme property as the key factor) . enable automatic dark mode on the left and prefers-color-scheme: dark on the right.

the color-scheme property is not used in core so far (only gin uses it in a few places). therefore the suggestion for the way forward would be two fold, to open up a followup issue adding something like

:root {
  color-scheme: light dark;
}

to core in general as suggested in the almanac on css tricks ( https://css-tricks.com/almanac/properties/c/color-scheme/). that way all elements of the page/site get opted into both color schemes making those elements theme-able in the forced color mode. and for testing avoid "enable automatic dark mode" nevertheless, instead use the following two settings (here in microsoft edge)

And the star looks good with prefers-color-scheme: dark as well as all the available page color themes available. The only small nitpick i might have and i just noticed last night, in forced color mode the unchecked star border is yellow and the checked star is filled yellow. while in none forced color mode the checked star is blue which is in line with the forced color mode, since the color blue stands for links. but the unchecked star border is black / gray.

so i wonder shouldnt the star in the unchecked state also have a blue border for consistency and semantics?

RE #69

Looking into Automatic Dark Mode further, my take is that the feature is just buggy. AFAICT, these are issues for it. It also appears to still be in a dev stage.

The only small nitpick i might have and i just noticed last night, in forced color mode the unchecked star border is yellow and the checked star is filled yellow. while in none forced color mode the checked star is blue which is in line with the forced color mode, since the color blue stands for links. but the unchecked star border is black / gray.
...
so i wonder shouldnt the star in the unchecked state also have a blue border for consistency and semantics?

This is a good point. I was trying to follow @ckrina's colors in #16. Does this change need designer approval?