Tabledrag icon doesn't adapt to forced-colors mode

Maybe better use real html symbol ⇵ for high contrast mode instead of bg-image? With this solution we will let browser to handle color automatically

Added initial commit.

Well, i tried to use two ⟷ symbols and rotate one of them, but unfortunately this solution doesn't work well. Arrows are misaligned in every browser and if you will try to fix these arrows for your exact browser - then arrows will be misaligned in another browser. I tried different css for positioning of it, but the original issue of it are glyphs. For example looks at this image:

The blue background here is a view box of the html symbol.
Red arrow is a unicode char
Green lines shows that arrow is not vertically centered.

So that means if i'll add one more same arrow and will rotate it 90 degrees - it's hard to control alignment of it crossbrowserly.

Instead, i decided to use these chars ⤩ and ⤧ (this and this) and rotate both 45 deg, coz the bug described above will never happen, since chars has equal width and height of glyphs actually.

This is current result in IE11 with enabled HCM:

This is MS Edge:

As you can see it's buggy a little bit now in MS Edge, i have added little opacity: 0.5; to one of those arrows and i got:

So as you can see for some reason in ME Edge one char hides another. I tried to google to understand why it happens, but didn't find solution how to solve it on css level.

Any other ideas?
Maybe we can embed a real svg and rework tabledrag handler completely? Not only for high contrast. I don't know

Is there a strict requirement for the icon to be the four-way arrows? What if we used a different character for a handle like the mathematical identical to or strictly equivalent to and then use cursor: move on hover?

- Updated the drag handle to use the `identical to` mathematical operator unicode character
- Added the modern (forced-colors: active) media query

Please stop using Unicode symbols like this, and go back to SVG approaches.

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.

The forced-colors media feature can be used to override the CSS fill colour of an inline SVG. For an example, see commit c788d3f in #3223281: Olivero: Primary nav search icon invisible in forced-colors mode in MS Edge.

An alternative approach is to use SVG as CSS background images, and use the forced-colors media feature to replace it with a variant image using a system colour in the SVG fill attribute. See the Claro theme for some examples.

A further reason to avoid the use of Unicode characters in CSS content is they are conveyed as content to assistive technology. It might not be a disaster if you use a Unicode character with an appropriate meaning, but using a maths symbol like "identical to" just because it looks good is very inadvisable. I've stopped counting how many times I've heard a screen reader actually say "Trigram for Heaven, button, collapsed" in a mobile navigation design.

It seems @mherchel had the idea of using Unicode for lots of icons sometime in early August, and went on a short spree of suggesting this in several issues, before the accessibility conversation we had in #3223281-19: Olivero: Primary nav search icon invisible in forced-colors mode in MS Edge. I'm still finding a few issues like this one where Unicode symbols are still the current proposal. Hey ho :-)

Since @mherchel suggested deciding whether to fix this in core or continue the work in Olivero I added a needs-a11y-review tag. Apologies if that was inappropriate; I wasn't sure if there was another "we need to discuss this and decide what to do"-style tag, but since there hadn't been any movement since the suggestion I thought this might move things along.

I came here because I wanted to help with #3219958: [META] Make Olivero the default theme and this is in the should-haves list, but now I'm not sure if the path forward is to fix it here or move the work to core TableDrag.

CSS linting problems:

modules/system/css/components/tabledrag.module.css
 50:15  ✖  Expected "#000000" to be "#000"           color-hex-length         
 52:1   ✖  Expected empty line before at-rule        at-rule-empty-line-before
 56:17  ✖  Expected "CanvasText" to be "canvastext"  value-keyword-case

CSpell failing on `canvastext`

Thanks for the update. Tagging for testing.

I know this needs to be tested on Windows but I checked that the patch didn't affect contrast for Mac+Chrome for Bartik, Claro, Olivero, and Seven:

Accessibility "Invert Colors" Disabled:

Accessibility "Invert Colors" Enabled:

Oh... the last 4 screenshots didn't reflect what I could see when the Accessibility Invert Colors setting was enabled. Anyway... things looked okay with that. Kind of like dark mode.

This still needs testing on Windows.

Code looks good and patches apply cleanly. Attached are screenshots taken in both Windows high-contrast mode and regular mode using various browsers and themes. Table drag icons display correctly and there are no regressions. Marking RTBC.

I think we need a change record here because anything that is changing the image via a CSS override will need to update.

After applying patch #32, the tabledrag icons display correctly for all three themes (Seven, Bartik, Olivero) in Windows high-contrast mode in Edge 11 and Firefox browsers. I don't see any regressions in non-high-contrast mode. Screenshots are attached. Marking RTBC.

I've got one question about #32 that I can't test quickly because I don't have access to a windows machine. I think #32 is losing the focus colour change from #787878 to #00000. And I wonder what that should look like in high contrast mode. I'm also not sure what background: linktext; does. I looked on https://developer.mozilla.org/en-US/docs/Web/CSS/background and couldn't find anything.

I just opened this up on my windows machine and can verify cindytwilliams's findings in #33, as well as Mike's assertion of a proper focus state.

The linktext keyword is defined as part of "System Colors" as part of a forced-colors color scheme and matches the text of non-active, non-visited links.

Moving back to RTBC

I looked at why we have the non-breaking space - according to #181066-95: Drag and drop of table rows (e.g. block admin) it was for Opera back in 2007. In 2013 Opera switched to a Chromium based engine so I think we're fine to remove it here.

This still has"Needs accessibility review" tag and I think that an accessibility maintainer should remove that - especially as @andrewmacpherson has already chimed in on the issue.

alexpott asked on Slack for me to review this.

I'd like to take some time for manual testing. I am thinking up ways to break this!

I'm skeptical of the approach between #17 and #28, because forced colour modes aren't the only technology which users employ to adjust colours. Using background colour to paint a foreground design object is risky concept. I think it could be very fragile in the face of user-applied styles (such as user stylesheets, and some browser add-ons like Midnight Lizard).

However, the change in #31-32 might be the thing that saves this technique (despite being motivated by change records). If someone uses a forced colour mode at the OS- or browser-level, then fingers-crossed they aren't also messing with colours in a user stylesheet. Those would be famous last words...

I've updated the title. "Proper contrast" is kinda missing the point of forced colour modes, hence the name change when the media feature went into the CSS rec. Some users employ it to reduce the contrast, because white page backgrounds are too much.

I'm pondering the linktext colour. This thing doesn't behave as a hyperlink, despite having that role.

Re. #28:

Note the that the 9.4.x patch does not support IE. We can open up a followup if needed.

I'm not so keen on leaving IE support to a follow-up, because that's rewarding it's users with the slow-lane treatment. If we can improve it in this patch, that would be preferable.

Do you have an idea for MSIE? If so, let's capture it in this issue, at least as a comment. The legacy vendor media query is a sufficiently specific way to target IE (though it gets legacy Edge too), so we have a fairly free hand to use any technique which works. We could swap out a CSS background image for an alternative, like Claro did for the wastebasket node-delete icon. I heard that MS were intending to remove the legacy media query from Chromium-Edge, but I don't know when that's due to happen.

We reviewed this issue at the accessibility office hours just now. Crediting attendees.

@mherchel demo'ed the approach and further explained the issue. The attendees of the call agreed with this formulation:

This sounds and looks good so far, and is clearly better than nothing. Shall we prevent perfect from being the enemy of good, go forward with this for now, and if we uncover a better solution, do it as a follow-up?

Writing as just me again. As with #2972776: [policy, no patch] Better scoping for bug fix test coverage, we need to reconsider if the desire to never commit anything that's imperfect, out of fear of introducing any new technical debt, is the right approach. The end result is often leaving huge swaths of technical debt unresolved while we strive for perfection on every attempt to improve or fix something.

TL;DR

• Manual testing confirms what I was worried about in #40.
• Patch #28 improves the icon appearance in forced-colors mode, but the icon disappears in some other situations.
• The change between patch #28 and patch #32 is crucial. Let's proceed with patch #32, which only applies the CSS mask technique when forced-colors is active.

As developers, we often focus on fixing the bug report at hand, but as testers, we also need to think about regressions in other situations. So when I'm reviewing an accessibility fix, it's not enough to think about who the patch helps; I like to think about who might be hindered by the new approach.

There are many ways for users to change colours, apart from Windows high-contrast mode. Most of them we can't detect/control, but we can at least anticipate them.

In comment #40, I speculated that the CSS mask technique would be fragile in the face of user stylesheets and browser add-ons which change background colours. So I wanted to do some manual testing to see if I could come up with ways to break things, or be sure this patch was robust enough.

Testing approach

I tested Drupal core 9.4.x with the patches from #28 and #32, and looked for improvements and regressions compared to the un-patched Drupal core.

I used MSIE 11, Firefox 100, and Edge 101 (all on Windows 10). I didn't test with the other Chromium-based browsers, because what I saw with Edge was enough.

We've seen many screenshots already, so I'm only adding ones which show the interesting situations I found.

I used the Olivero theme, because I noticed that Claro had alread proceeded with this approach, and I wanted to compare before/after.

Firefox v100 or Edge v101, with author-colours only

No user-specified colour overrides. Patches should not change any appearance here.

1. Un-patched: Grey tabledrag icon is visible (GOOD).
2. Patch 28: Grey tabledrag icon is visible (GOOD).
3. Patch 32: Grey tabledrag icon is visible (GOOD).

MSIE 11, with author-colours

No user-specified colour overrides. Patches should not change any appearance here.

1. Un-patched:Grey tabledrag icon is visible (GOOD).
2. Patch 28:

   

   The icon disappears, replaced by a grey rectangle (BAD). The CSS image mask isn't supported. Wasn't expecting this to work.

3. Patch 32:Same as un-patched. The grey tabledrag icon is present. (GOOD, no regressions.)

Firefox v100 or Edge v101, with Windows High Contrast

I used a custom user-specified Windows high-contrast theme, because I don't like to assume that one of the default black or white ones is being used. I have a pink text on a purple background, with blue buttons, and orange links.

1. Un-patched:

   

   • Icon is present (GOOD).
   • Icon colour does not adapt to Windows high-contrast (BAD). This is the main bug this issue is trying to fix.
2. Patch 28:

   

   • Icon is present (GOOD).
   • Icon adapts colour (GOOD, improvement). Cool, this is what the issue is trying to fix.
   • The icon get CanvasText system colour, which isn't right for operable controls. (MEH, could be better, discussed below.)
3. Patch 32:

   

   • Similar outcome as patch 32, but not quite the same.
   • Icon is present (GOOD).
   • Icon adapts colour (GOOD, improvement).
   • Icon gets the link colour (orange in my scheme). MEH, could be better, discussed below.

MSIE 11, with Windows high-contrast

1. Un-patched: The icon disappears completely (BAD), because MSIE strips out background images. We already knew this was broken. It would be good to fix it for MSIE too.
2. Patch 28:Same as un-patched. The icon disappears (BAD, no improvement).
3. Patch 32:Same as un-patched. The icon disappears (BAD, no improvement).

Firefox v102 or MSIE 11, with user stylesheet to override foreground and background colours

It's difficult to plan ahead for user-stylesheets, because (A) they could contain literally anything, and (B) they are private by nature, so web developers don't often get to see what a user-stylesheet contains.

Nonetheless, we can at least anticipate some typical use-cases. Changing colours is one such use-case. User stylesheets are supported by MSIE, Firefox, and some lesser-used browsers. They can also be applied using some browser extensions, or even Javascript bookmarklets.

Here, I'm testing with a very minimalist user-stylesheet which forcibly overrides the foreground and background colours. The effect is similar to using Windows high-contrast mode, but it doesn't require a Microsoft browser/OS, only changes the browser content, and leaves other applications alone.

    /* Specimen user-stylesheet */
    * {
        color: brown !important;
        border-color: brown !important;
        background-color: moccasin !important;
      }
    a:link, a:visited { text-decoration: underline !important; }
    a:link { color: mediumblue !important; }
    a:visited { color: darkmagenta !important; }
    

1. Un-patched:

   

   • The icon is present (GOOD).
   • The icon remains the author-specified grey. This is OK. There's no guarantee of legible contrast against the user-specified page background, but at least the icon is present. I don't think it's safe or feasible to try to meddle with this situation.
2. Patch 28:

   

   The icon disappears (BAD, regression). The background colour for the icon now matches the page background. Confirms my speculation from comment #40.

3. Patch 32:
   • Same as un-patched. No regressions (GOOD).
   • The icon is present (GOOD).
   • The icon remains the author-specified grey (OK, let's not meddle here).

Out of all the browsers we support, MSIE is the only one which offers an easy GUI for setting up a user stylesheet. To some users this is Internet Explorer's killer feature (not joking)! So I really want to avoid the disappearing icon problem here, for as long as D9 is around.

Firefox v100 or Edge v101, with Midnight Lizard

The Midnight Lizard browser extension allows users to apply a new colour scheme. It overrides foreground and background colours in a similar way to Windows high-contrast mode, but the browser cannot detect it with a CSS media query. It can also do some other cool things, like putting a translucent overlay over images so that vivid photos don't look overpowering.

1. Un-patched:

   

   • The icon is present (GOOD).
   • The icon doesn't adapt it's colour (OK. No guarantee of legible contrast, but not feasible to meddle with it).
2. Patch 28:

   

   The icon disappears (BAD, regression). Confirms my speculation from comment #40.

3. Patch 32:
   • Same as un-patched. No regressions (GOOD).
   • The icon is present (GOOD).
   • The icon doesn't adapt it's colour (OK. No guarantee of legible contrast, but not feasible to meddle with it).

Colour-changing technology I deliberately didn't test

Greyscale, invert, white-point adjustment: these are done at the level of the operating system's window compositor (e.g. macOS Quartz). Most can't be detected by web browsers. Invert has a media query, but the tabledrag icon isn't something we need to use it for.

Also Overlays! app, ClaroView, ScreenRuler, or the tinted overlay features from some screen magnifiers packages. We can't detect or control these; instead, meeting WCAG's colour contrast success criteria helps to ensure content remains legible when these tools are used.

What system colour shall we use for the tabledrag icon?

In the forced-colors mode (Windows high-contrast) I noticed that patch #28 made the tabledrag icon use the CanvasText system colour. That doesn't seem ideal, because it doesn't give you any clue that it's an operable control.

Meanwhile, patch #32 doesn't explicitly declare a system colour, so the icon gets the link colour, because it's an <a href> element. That's better, because it signifies that it's an operable control. However it's potentially confusing because it doesn't actually behave as a link.

I reckon it might be better to use the button foreground/background system colours, but then that would disagree with the element's role. To fix that, we'd need a markup change, which we avoided here so far, and it would be good to make this issue just about CSS/appearance.

In any case, it's a minor issue. It can wait until later; tabledrag could do with a bigger overhaul in my view anyway. Let's stick with patch #32 for now.

Note that Claro has already gone with the link system colour.

Outcome

Patch #28 improves the situation with Windows high-contrast mode (forced-colors, but leads to serious regressions with at least 2 other technologies which provide user-specified colours. I'd say that's sufficient to reject it.

The change in patch #32 turns out to be crucial. It only targets forced-colors: active, and does not lead to the regressions I found with patch #28. It's a far safer and more cautious approach.

Recommendations

Let's proceed with the approach in patch #32, and restrict the CSS mask technique to forced-colors: active. This way we can preserve the status quo in other situations.

I'd still like to see if we can fix the icon in MSIE 11 with Windows high-contrast. I've been tinkering with this, but I'll come around to that in another comment. I'm happy to leave it to follow-up issue, but please actually create the issue before committing this one.

It's good from me. Anything else left to consider?

Committed ebe52e3 and pushed to 10.0.x. Also committed to 9.5.x. Thanks!