Toolbar icons may not meet contrast when in forced colors mode

Tagging for https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

Claro has overrides for these. If they are only fixed in the toolbar module, the changes won't appear in Claro.

Perhaps the correct solution involves removing the Claro overrides.

Some of the icons also need attention for the "pressed" and / or "active link" states. Here's a screenshot.

@cwilcox808 said this RE forced-colors styling for the "pressed" state of the buttons:

For aria-pressed="true", you could maybe set border-color: Highlight;, buttons in that state wouldn't have a visual change on hover but focused buttons would still have the addition of the outline.

Hi,
I was able to reproduce the issue locally by switching to forced colors mode. In comment #6, @kentr suggested removing the Claro overrides. However, I had a follow-up question: if we remove those overrides, do we have alternative images or icons to use in their place? If not, what would we be replacing them with?

Would appreciate some clarification before proceeding. Thanks!

@libbna

In comment #6, @kentr suggested removing the Claro overrides. However, I had a follow-up question: if we remove those overrides, do we have alternative images or icons to use in their place? If not, what would we be replacing them with?

Now that Gin will replace Claro, I'd say disregard my suggestion in #6.

But just to clarify the thought behind it: I was suggesting removing the Claro overrides for these particular icons altogether so that the icons won't go back to being broken when the admin theme is Claro (i.e., with the Standard installation profile).

@kentr thanks for clarification but now how can we resolve this issue? Now that claro is being replaced, I guess we can replace the overrides too. No?

@libbna,

My thinking is that fixing the icons in the Toolbar module will still resolve the issue in any theme that doesn't override them.

Olivero doesn't AFAIK, so the changes will take effect on non-admin pages by default. And for Drupal CMS admin pages, the change will also appear there if Gin doesn't override the icons.

If there's a need to resolve the problem for Claro, it can be a separate issue that's specific to Claro.

I just learned that Gin inherits a lot of Claro code: #3530849: [META] Gin 6.x: Preparation for merging into core.

So, limiting this change to the Toolbar module may not solve the problem in Gin (if it exists at all). But I'm guessing that any change to Claro libraries for #3530849: [META] Gin 6.x: Preparation for merging into core is best done specifically as part of that effort so that it can be analyzed beforehand.

I incorrectly assumed that when not in Claro, the toolbar styles are provided by the Toolbar module.

It turns out that Claro overrides the toolbar styles even when it's not the default theme: #3070493: Introduce a mechanism to provide an alternate Claro design for the toolbar in the future.

If Claro is the admin theme and Olivero (or a random other theme) is the default theme, Claro will dictate the toolbar styles for the default theme also.

So, it looks like we do have to change both the Toolbar module and Claro for this issue.

Adding a suggestion:

#3090120: Improve accessibility semantics for Toolbar buttons with trays will hopefully result in the role="button" added by JavaScript instead of it being present in the initial markup.

If that issue lands before this is completed, it would be great to include here some CSS rule(s) based on role="button" that will set the system-color of toolbar buttons to ButtonText after they are processed by JavaScript.

Something along these lines:

@media (forced-colors: active) {
  .toolbar .toolbar-item[role="button"] {
    color: buttontext;
  }
  .toolbar .toolbar-item[role="button"]::before {
    /* Assuming background images are converted to mask images. */
    background-color: buttontext;
  }
}

There's related discussion here.

I do not recommend letting #3090120: Improve accessibility semantics for Toolbar buttons with trays block this issue, though.

The Toolbar Module was approved for removal in #3476882: [Policy] Move Toolbar 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 #3484850: [meta] Tasks to deprecate Toolbar module and the removal work in #3488828: [meta] Tasks to remove Toolbar module.

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

Toolbar has moved to contrib