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

I used the same approach here as in #3171727-3: Claro breadcrumb divider needs Windows High Contrast mode improvements. The only possible downside is the same, that the star is now darker without high-contrast mode, but I think it's worth the trade-off.

Chrome before:

Chrome after:

Firefox Windows high-contrast after:

Looks 👍 to me too. It's worth loosing some aesthetic if it's improving accessibility.

Given that the star is now darker than the text, it does stand out quite a bit. It seems fine for now, but should we open a follow-up to see if we could implement the original design after something like https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_Med... is supported by Firefox?

More screenshots please. Is it possible to tell the two states apart in Windows High-Contrast themes (pages added / not added to shortcuts)?

To be honest, the shortcut star performs poorly in the full-colour space too, where it fails WCAG SC 1.4.1 "Use of Color" (level A) and SC 1.4.11 "Non-text contrast" (level AA).

We can't rely on a yellow fill to be noticable compared to the transparent fill (grey, in effect). For example, some users with dyslexia employ a whole-screen colour filter to make text easier to read (sometimes software, sometimes a plastic sheet). There's a good discussion of this in Understanding Success Criterion 1.4.11: Non-text Contrast, specifically illustrating the problem of yellow-filled vs. empty stars.

There's also a very straight-forward solution by using a single colour for both the fill and stroke. (The Firefox URL bar uses this for browser bookmarks; a black star outline changes to a solid blue star.)

Rather than put a band-aid fix for Windows HC, I think we should broaden the scope of this issue to fix the shortcut star in all colour spaces at once, and remove the need for a media query.

Bumping to major because it fails a level-A WCAG success criterion.

Edited the issue summary to explain why this isn't just about using Windows high-contrast feature.

Thanks for the link in #8!

I'm attaching two patches with different approaches. One provides a star with a thicker border in the selected state. The other provides a solid fill in the selected state. The solid patch uses currentColor, but it could work with any solid color as long as the contrast is sufficient on all backgrounds.

I have a slight preference for the yellow star with a thicker border.

It looks like I switched the patch names in the previous comment. Fixed here, and adding a better screenshot.

Thanks for working on this @katherined.

Review of #12:

The "not selected" screenshots: everything is good. It's fixes the problem in the full-colour space, where the grey star outline didn't have enough contrast against the grey page background. It also adapts well to Windows high contrast modes, in all browsers, because it just uses current colour everywhere.

From a cosmetic view, I think the "yellow fill and thick border" variant is quite messy (in a "too-much ink" way). I not sure if the thick border is a strong affordance of "selected" either; the situation isn't the same as the 5-star ratings widget where you can see a row of stars, and the filled ones come before the unfilled ones in the reading order. For our shortcut, we only have one star, and there is no other star on the page to compare it to.

Your screenshots only show what it looks like with the black/white high contrast themes which are pre-configured in Windows. However I don't think the yellow fill version would work well at all for user-specified high contrast themes, where the page background can be literally anything. It won't show up if the user picks a yellow or beige background.

The single-colour "alternative" version is more elegant to me. The difference between a filled and unfilled star is very stark, and works well in the high-contrast themes. But I think it's too heavy (and a bit boring) in the full-colour space.

Here's an experiment of mine. It uses concentric stars.

This is what it looks like in the full-colour space:

A solid star is inside a hollow star. The fill doesn't directly touch the outline of the star; there's a transparent space in between. The shortcut icon behaves somewhat like a single checkbox, with a checked vs. not-checked state. So I'm trying to keep the same sort of distinction between the border and the fill, but without having low-contrast colours. I'm aiming for something similar to a radio button, which usually has a gap between the outer circle and the bullet fill.

I also wanted to see if we could get a colour-adaptive icon without needing alternative image files. So the SVG has a <style> element, with it's own -ms-high-contrast media query. The un-filled star is grey, so it isn't as overpowering as using currentColour which matches the heading text. We can go for a grey which has over 3:1 contrast against the page header (#808080 gives a 3:48:1 contrast ratio).

But when the star is filled, we can still employ colour. I used blue for both the outline and the fill. There's already a lot of blue in Claro to represent active/selected, and this is very much like the selected radio button style (but you know, spiky). It'll have much better contrast than yellow. It's also what Firefox and Chrome do in for browser bookmarks in the URL bar; and empty grey star changes to a filled blue star.

In Windows High Contrast mode, all colours are switched to currentColor, but the transparent gap between the outline and fill is still there. Here's what it looks like with a black-on-white theme:

I always like to test Windows high-contrast with user-specified colours. Here's a sepia-on-rose custom scheme I cooked up (some people deliberately use a low contrast palette!).

The high-constrast screenshots here show IE11, Edge (pre-Blink), and Firefox. The snag is that Firefox doesn't support the high-contrast media query, so the filled star still appears blue. Firefox has always been a poor relation to the MS browsers for high-contrast mode. I'm happy with this; so long as we can get it working well for the MS browsers, that's good. We can wait for the forced-colors media query which is going through CSS standardization.

So far it's just an SVG file, rather than a Claro patch, and I haven't done the add/remove crosses yet. I think the thickness of the solid border and transparent gap might need some adjustment too.

Thank so @andrewmacphersonfor the proposal! I do like the blue fill much more than the yellow one. Based on your proposals, I've prepared this to get more context:

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:

With the "filled" when it's saved should be good enough to let people understand:

@andrewmacphersonwhat does this make sense to you?

Linking open issues from the VPAT - https://github.com/CivicActions/accessibility/blob/main/VPAT/Drupal9Acce...

Thanks for the feedback @ckrina. That's a good point about the rendering at smaller sizes. I mentioned that the thicknesses might need adjusting, and I guess it just suffers from anti-aliasing at small sizes.

I'm happy to go with your proposal to just use a solid fill, rather than my concentric stars idea.

Adding NorthAmerica2021 and Easy Out of the Box tags for visibility.

DrupalCon NA is April 12-16 with a focus on EOOTB on Wednesday, April 14.
Thanks

Created MR and adding patch

@jenniferaube: Thanks for working on this. It's a good start - it gives us the basic empty and solid stars we need. The colours need work though.

Manual testing of patch #23...

These screenshots were all taken with Edge v90. I tested the full-colour space, and 3 versions of Windows high contrast mode.

Screenshots using patch #23 with Windows high-contrast.

Colour space	Empty star	Filled star
Full-colour (author-specified)
Windows high-contrast, white background
Windows high-contrast, black background
Windows high-contrast, custom colour scheme.

In all cases, the star is black. It shows up well against a light background, but is invisible when using a Windows high-contrast theme with a black background.

Today, my custom high-contrast colour scheme is pink-on-purple, with orange links (it could be anything). A black star isn't good contrast here.

1. diff --git a/core/themes/claro/claro.libraries.yml b/core/themes/claro/claro.libraries.yml
   index a40b1625ca..0d40b37f9f 100644
   --- a/core/themes/claro/claro.libraries.yml
   +++ b/core/themes/claro/claro.libraries.yml
   @@ -50,6 +50,7 @@ global-styling:
          css/components/table--file-multiple-widget.css: {}
          css/components/search-admin-settings.css: {}
          css/components/tablesort-indicator.css: {}
   +      css/components/shortcut.css: {}
          css/components/system-status-report-general-info.css: {}
          css/components/system-status-report.css: {}
          css/components/system-status-report-counters.css: {}
   

   This addition isn't necessary. The shortcut.css file is already declared as part of the claro/drupal.shortcut library, later in the file. It's styling for a module, so the CSS file is only added when shortcut module is enabled, and the user has the right permissions.

2. The CSS changes have been made directly in shortcut.css, but they should be made in shortcut.pcss.css. The CSS files in Claro are generated via PostCSS. See Drupal core using PostCSS for development and Frontend Developer tools for Drupal core.

3. +.shortcut-action--remove .shortcut-action__icon {
   +  background: transparent url("data:image/svg+xml,%3csvg height='24' width='96' xmlns='http://www.w3.org/2000/svg'%3e%3cg stroke='currentColor'%3e%3cpath d='m 65.48167,21.357353 -5.540821,-4.268742 -5.564762,4.240238 2.157938,-6.852898 -5.558557,-4.243265 6.874502,0.0334 2.129386,-6.8627197 2.090734,6.8735507 6.87459,0.0019 -5.582354,4.21467 z m 24,0 -5.540821,-4.268742 -5.564762,4.240238 2.157938,-6.852898 -5.558557,-4.243265 6.874502,0.0334 2.129386,-6.8627197 2.090734,6.8735507 6.87459,0.0019 -5.582354,4.21467 z' fill='%2000000' stroke-width='2'/%3e%3cg fill='black'%3e%3cpath d='m 38.42,9.327 0.11,0.35 h 7.934 l -6.521,4.742 -0.31,0.225 0.138,0.358 2.922,7.599 -6.397,-4.653 -0.294,-0.214 -0.294,0.214 -6.397,4.653 2.923,-7.599 0.137,-0.358 -0.31,-0.225 -6.521,-4.742 h 7.934 l 0.11,-0.35 2.418,-7.665 z m -24.002,0 0.11,0.35 h 7.934 l -6.521,4.742 -0.31,0.225 0.138,0.358 2.922,7.599 L 12.294,17.948 12,17.734 11.706,17.948 5.309,22.601 8.232,15.002 8.369,14.644 8.059,14.419 1.538,9.677 H 9.472 L 9.582,9.327 12,1.662 Z'/%3e%3cpath d='M 42.5,1 V 8 M 39,4.5 h 7 M 88,7 94,1 m 0,6 -6,-6' stroke-linecap='square' stroke-miterlimit='3'/%3e%3c/g%3e%3c/g%3e%3c/svg%3e") left top / 6rem 1.5rem no-repeat;

   There are two fill attributes here, and they are both hard-coded black. The reason the currentColor always ends up black, is because it's specified in an SVG attribute. It's something to do with the browser starting a new render root (terminology?) for an SVG-as-CSS-background-image, and the initial currentColor is black.
   In #14, my experiment used a style element in the SVG itself, with CSS stroke/fill properties instead of SVG stroke/fill attributes. Then currentColor works out the same as the system plain text (I don't yet grok why...).

• In the default full-colour space, the filled star should be blue. The empty star needs a dark grey (which?) outline, and a blue outline for hover/focus. See @ckrina's images in #16.
• Since the shortcut-star functionality is implemented as a link, we ought to use the CSS LinkText system colour inside a high-contrast media query, for all states.

@mgifford: Did you mean to tag this wcag131? SC 1.3.1 is "Info and Relationships". That's not the issue here; the visible information is conveyed via markup. I looked at the other issues tagged wcag131 and they're all about high-contrast.

Hi there, I made the changes pointed out on #26, adding inline styles on the svg with a media query for detecting high contrast mode worked really well. I pushed the changes to the existing merge request, not sure if that's better than starting a new merge request.

Here's how it looks now on Chrome and Edge with high contrast enabled:

Tagging for Design4Drupal 2021. Contributions are Friday, July 22
https://design4drupal.org/

Correcting tag Design4Drupal2021

Added some comments in the MR.

The star does not show in IE11 high contrast mode also.

I'm going to spend a bit of time on this.

Attached is a new approach (so no interdiff).

• We use unicode stars(☆ and ★) for high contrast mode along with media queries.
• I also remove the RTL version of the star because its exactly the same as the regular LTR version.

Screenshots:
IE:

Edge:

FF:

The previous patch still allowed the core shortcut module to insert a RTL version of the star as a background image, which would show in Edge and FF.

This patch overrides that behavior.

Layout_builder.Drupal\Tests\layout_builder\FunctionalJavascript\LayoutBuilderDisableInteractionsTest
✗
Drupal\Tests\layout_builder\FunctionalJavascript\LayoutBuilderDisableInteractionsTest
fail: [Other] Line 0 of sites/default/files/simpletest/phpunit-84.xml:
PHPUnit Test failed to complete; Error: PHPUnit 9.5.8 by Sebastian Bergmann and contributors.

This looks like an unrelated failure. Re-queuing the tests.

I like the simplification for WHCM / forced-colors using unicode characters instead of trying to get the SVG to work. It's also great that you don't need to mess with color overrides for WHCM / forced-colors since it's just text, which the user agents handles well.

One thing I noticed. The merge request included the blue stars design. The recent patch is missing that and shows the yellow stars.

Here's an updated patch with the blue stars .svg.

Adding tag for DrupalCon Europe2021. Thanks

Thanks for working on this everyone. I'm afraid I've lost track of whether to look at the merge request or the patches here.

Whichever it is, please don't use the Unicode stars - go back to using the SVG stars.

Short version: using Unicode symbols like this is extremely fragile in situations where users specify their own fonts (in browser preferences, OS preferences, or user stylesheets). For detailed reasons, review the Slack conversation in #3223281-19: Olivero: Primary nav search icon invisible in forced-colors mode in MS Edge.

I found a survey of Unicode character ranges and the Unicode fonts that support them. The list of fonts supporting the Miscellaneous Symbols block isn't very long. The page was last updated in 2012, so I imagine more actively maintained fonts may support it by now. However I'd assume that older, unmaintained proprietary fonts won't have gained support for Miscellaneous Symbols.

Also remember there are FOUR star icons used by the shortcut widget, not two. The Unicode stars don't have accompanying + or x signs like the existing SVG version does.

Re. #32: The reason the star doesn't show in MSIE is that is strips out CSS background images, on the assumption that they interfere with overlying text. This behaviour has been superceded by the text-backplate in Legacy-Edge and the modern CSS forced-colors standards. You can still get a CSS background image in MSIE, but you have to explicitly restore it using the legacy vendor media feature -ms-high-contrast: active. I think that also works for style elements inside an SVG.

I'm away-from-Windows right now, but I'd like to try the older versions out which still use SVG.

(updated; fixed broken markup)

Per @andrewmacpherson 's comment, we can't use the unicode solution posted on #33 and the improvements on that on #38.
So we have to go back to the solution in #29 and test it.

As referenced in #3227431-12: Tabledrag icon doesn't adapt to forced-colors mode, we could also use the CSS clip-path property. This works well in high contrast, but has been not been an option due to lack of IE11 support. If we move this issue to 10.0.x, it'd be a LOT easier to implement fixes like these.

Here's a codepen demo: https://codepen.io/mherchel/pen/qBPaeEQ?editors=1100

Here's a codepen demo with a star shape. This will work great in high contrast mode*

Two issues:

• This will not work in IE11
• This doesn't have the little plus/X icon that hovers. TBH, I don't think that's needed.

https://codepen.io/mherchel/pen/JjrgvjY

If we go this route, we can either 1) commit it to both 9.4.x and 10.0.x (and file a followup for 9.4.x that'll likely never get solved). Or, we can just commit it to 10.0.x.

If this solution won't work, we'll need to refactor the shortcut module to utilize a twig template so we can inline the SVG markup. But, IMHO, this isn't too bad.

According to #3066007: Roadmap to stabilize Claro, this is a "must have" for Claro to be Stable. I don't know if that's accurate, but if it is, then it would be really great to have Claro stable in 9.4, because that would allow us to move Seven from core to contrib for Drupal 10, and have one less theme to maintain in core.

Changing Shortcut module to use a twig template doesn't sound like a bad idea to me, unless it introduces BC concerns. If we do that, I still like the idea of a 10.0.x follow-up to make it better once IE11 no longer needs to be supported.

If we think a non-IE solution would be significantly better than one that accommodated IE, another idea is we could just not provide Shortcut functionality at all in IE in Claro? And any Drupal 9 sites still accommodating editors/administrators using IE could just choose to remain on Seven?

And any Drupal 9 sites still accommodating editors/administrators using IE could just choose to remain on Seven?

Yeah, thats my attitude. I don't think there's that many.

Changing Shortcut module to use a twig template doesn't sound like a bad idea to me, unless it introduces BC concerns

This would be the ideal solution. My codepen above is CSS only, and it will work, but a theme being able to override the template would be better and more flexible going forward. I personally don't have the PHP chops to get that done, but if you or someone else wants to introduce the template, I'll modify that (as well as all of the relevant CSS) to make it work.

I don't anticipate any BC changes if we have the default template reproduce the current markup.

Are these two spans what should be in a twig template? Should the entire link be in that template, or only the two spans and keep the link itself still using the generic '#type' => 'link' as currently?

Either would work.

That being said, if they're both equal amounts of work, it makes more sense to put the entire hyperlink into the template, as long as we can insert markup within the <a> tag.

Discussed this with @lauriii. He agreed that because 1) this issue happens in other themes (it happens in all the themes) and 2) the resolution is within the shortcut module, the core component should be changed to the Shortcut module.

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.

[Edited to correct missing screenshots]

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:

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 looks okay to me, but in my own testing the star is barely visible in each of the two states.

unchecked:

checked:

the none-forced color mode on the other hand looks good and also in line with #16 as @kentr stated in #67

Followup for #68. 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?

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

The Shortcut Module was approved for removal in #3476880: [Policy] Move Shortcut module to contrib.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3569117: [meta] Tasks to deprecate the Shortcut module and the removal work in #3569121: [meta] Tasks to remove the Shortcut module.

Shortcut will be moved to a contributed project before Drupal 12.0.0 is released.