High contrast mode needs some more refinement

forgot the mobile viewport. made a few additions to the issue summary

mmm, i can't reproduce it @rkoller

so you said:

enable automatic dark mode ticked, forced colors active and preer contrast set to more

In the system OS settings on Mac OS i have enabled dark mode
in MS Edge browser i have enabled forced-colors: active
and this preer contrast set to more i think you were talking about system OS settings again? I see range bar in the settings to increase contrast (or this setting somehow i can apply inside of MS Edge)?

no all those three settings were set within ms edge (@mherchel provided the instructions for this handy feature testing high contrast mode a while ago on slack if i remember correctly). you have to add the render tab either to the quick view or move it to the activity bar on top in the ms edge devtools:

and i then only set and adjust those three settings highlighted:

Added WCAG 2.2 success criteria and moved steps to reproduce into its own section for easier readability.

I can't find solution for this, maybe some hints?

Maybe we can replace CSS mask-image with embedded svg icons ? Or to use iconic font and content css property (but embedded technology is better)

I have updated the latest screenshot in the issue summary

For folks testing in high contrast, here is a guide.
https://www.lambdatest.com/blog/windows-high-contrast-mode/

We recently landed 📌 Navigation leverage icon core API Needs work , which had a positive impact on Windows High Contrast mode. I'll be doing some testing on the latest 11.x with the goal of updating the issue description to reflect the outstanding issues.

Added a few more issues that I noticed.

I believe #4 in the IS (regarding the outline of the hovered menu entry) is caused by automatic dark mode. I can't reproduce it in basic forced colors emulation or MacOS Edge with Page Colors.

I suggest removing that item. @rkoller, does this sound right, and do you agree that item can be removed?

Is #6 in the IS referring to the hamburger icon that #8 refers to?

I'm also adding Page Colors to the IS for seeing forced-colors mode. It's a little nicer DX than forced-colors emulation in DevTools.

For IS #9 (gap in menu right border) I'm only seeing the issue in Firefox (Mac).

Also noticed another issue: The icon next to the username at top is hard to see. It may not be a UX / accessibility problem, though.

Screenshot attached from Chromium.

Tweaking the STR a little more.

I retract my previous comment about the interrupted menu right border. I now see it in Edge with Page Colors.

Suggestion for the remaining hard-to-see inline SVG icons:

• For the color issue, use currentColor in some form.
• For the chevrons, give them a stroke with a larger width.

Here's POC CSS:

@media (forced-colors: active) {
    svg[class*="toolbar"] path[stroke] {
        stroke: currentColor
    }
    
    svg[class*="toolbar"] path[fill] {
        fill: currentColor
    }

    :is(
        .toolbar-button__chevron, 
        .admin-toolbar__expand-button-chevron
    ) path {
        stroke-width: 5%;
        stroke: currentColor;
    }
}

Screenshot:

thanks for getting some momentum back into this issue @kentr!

re #21 🐛 High contrast mode needs some more refinement Active yep in regard to point 4 i agree, good catch. just retested without the automatic dark mode and the hover looks totally fine and clearly visible to me. on the other hand the active menu item for the current site is close to invisible, but that has already an issue for the none forced color mode ( 📌 Make the active menu item visually stand out more Needs work ). so i wonder about two things, should the forced color mode with the active menu item be fixed in the aforementioned issue or within the scope of this issue? and in regard to updating the issue summary, instead of removing point 4 i wonder would it be the better choice to strike it through and leave a note. that way the references of the others points after the current point 4 wouldnt have to be updated throughout the comments?

in regard to point 6 in the issue summary. i have to admit writing up that issue was a while ago and the issue summary also got updated by other people. not sure i did point 8 back then, that was probably added afterwards by someone else? in regard to point 6, that screenshot was taken with the automatic dark mode checkbox ticked and as outlined it was about the barely visible hamburger icon AND the missing top bar border. you were unable to distinguish what is the page and what is the top bar. but looking at the site without the automatic forced color mode active the issue about distinguishing the top bar due to a not visible border is not an issue without the automatic forced color mode. or wait i was too hasty. the missing top bar border is still an issue for desktop viewports! there it is missing while it is visible for the mobile view port. maybe point 6 should be rescoped to the not visible bottom border in desktop view port and point 8 should be solely about the hamburger. that way the two images used are more appropriate? if you agree i can update both points in a follow up comment.

re #22 🐛 High contrast mode needs some more refinement Active yep i've noticed that as well now. in your example you are referring to the icon in the top bar on a user profile page but the invisible icon also applies to node edit forms. they are using the same image there as well. and the gap i am also still experiencing for the mobile view port in edge.

@rkoller

in regard to updating the issue summary, instead of removing point 4 i wonder would it be the better choice to strike it through and leave a note

👍 Good idea.

on the other hand the active menu item for the current site is close to invisible, but that has already an issue for the none forced color mode (#3426468: Make the active menu item visually stand out more). so i wonder about two things, should the forced color mode with the active menu item be fixed in the aforementioned issue or within the scope of this issue?

I don't know. It may need more than a system-color change.

I tested ActiveText in all Edge Page Colors themes and using the emulation in Chromium DevTools. The color is indistinguishable from LinkText. Shouldn't ActiveText be a distinct color?

There was a Chromium bug related to this.

Here's a screenshot in Page Colors Dusk theme. The "Appearance" item is current and has the following CSS.

@media (forced-colors: active) {
    .toolbar-button.current {
        color: ActiveText;
    }
}

Firefox uses a distinct color for ActiveText.

maybe point 6 should be rescoped to the not visible bottom border in desktop view port and point 8 should be solely about the hamburger. that way the two images used are more appropriate? if you agree i can update both points in a follow up comment.

👍 Sounds good.

Adding a new issue: More actions button should have a border (related Slack discussion).

This may be fixed by 📌 Improve visibility of More actions menu button Active , but does the menu "Close" icon also need a border?

Did a little research, and I believe I misunderstood ActiveText. Apparently it's for links that are being activated (pressed), not for the "active" link that corresponds to the current page.

made the following changes to the issue summary

• striked point 4 as outdated and added a note
• rescoped point 6, making it about the missing bottom border on the desktop view port
• added point 10, about the invisible icon @kentr raised in #22 🐛 High contrast mode needs some more refinement Active

and there is one more potential detail that could be added to the issue summary, the background color for the workspace is not displayed in forced color mode. in "regular" mode you have a green background for the workspace that is live while all the other none live workspaces have an orange background (SC1.4.1 might apply here?). in addition to that the yellow font color used on the live workspace implies that it would lead to a page but strictly speaking just an area on top of the current page is displayed.

in "regular" mode you have a green background for the workspace that is live while all the other none live workspaces have an orange background (SC1.4.1 might apply here?).

Looks like that is mentioned in #2910673: Workspace UI usability review → .

in addition to that the yellow font color used on the live workspace implies that it would lead to a page but strictly speaking just an area on top of the current page is displayed.

I'd vote for making that element a progressively-enhanced button like in the MR for 📌 Use ARIA disclosure pattern for Toolbar buttons with trays Active .

Then the style can be something like this:

@media (forced-colors: active) {
  .toolbar-button[role="button"] {
    color: buttontext;
  }  
}

I'm uncertain if this is a Navigation issue or a Workspaces issue. It would be nice if Navigation handled it for all menu components.

I'd also really like to see this pattern be global, with a policy of progressively-enhancing all cases like this. Then it could be:

@media (forced-colors: active) {
  a[role="button"] {
    color: buttontext;
  }  
}