Olivero: No differentiation in background color between the hover and drag states within tabledrag

Thanks for the MR.

1. Code changes seem straight forward.

2. MR applies to Drupal 10 only. Need MR or patch for 9.3 and 9.4.

[drupal-9.4.x-dev/9.4.x] [drupal-9.4.x-dev]$ patch -p1 < 1733.diff 
patching file core/themes/olivero/css/base/variables.css
Hunk #1 FAILED at 138.
1 out of 1 hunk FAILED -- saving rejects to file core/themes/olivero/css/base/variables.css.rej
patching file core/themes/olivero/css/base/variables.pcss.css
Hunk #1 FAILED at 99.
1 out of 1 hunk FAILED -- saving rejects to file core/themes/olivero/css/base/variables.pcss.css.rej
patching file core/themes/olivero/css/components/tabledrag.css
Hunk #1 FAILED at 28.
1 out of 1 hunk FAILED -- saving rejects to file core/themes/olivero/css/components/tabledrag.css.rej
patching file core/themes/olivero/css/components/tabledrag.pcss.css
Hunk #1 FAILED at 10.
1 out of 1 hunk FAILED -- saving rejects to file core/themes/olivero/css/components/tabledrag.pcss.css.rej

3. Tagging for issue summary as it could use the issue summary template and have explicit steps to reproduce.

4. This can be tested on Drupal 10 with steps to reproduce.

Good to know, thanks!

This will need rebased to 10.1.x (it may be easier to open a new MR than to attempt a rebase for over a year of commits).

Also, steps to reproduce would be super helpful

Uploading a patch for 10.1.x

Per #1 the text-to-background contrast ratio is fine, what I'm not sure about is if the differences between the different background colors is enough. The background-color differences are between 1.06 and 1.12, but I'm not sure if the background colors need to have any specific CCR amount.

Per accessibleweb:

You need to maintain 3:1 contrast ratio during all of that elements states (focus, hover, active, etc). The requirement doesn’t mean that states need to contrast 3:1 with each other. For instance, an element's hover state does not need to contrast 3:1 with its focus state, or even its resting state.

However, WCAG SC 1.4.1:

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)

We change the mouse cursor over the tabledrag handle, which is another visual indicator of interactivity, but there's no non-color visual difference while and element is "active". But I'm also not sure we need one. Tagging for a11y review, and per @xjm's comments in other issues, accessibility issues are not minor. Screenshots attached.

We change the mouse cursor over the tabledrag handle, which is another visual indicator of interactivity, but there's no non-color visual difference while and element is "active". But I'm also not sure we need one.

We don't need a non-color visual difference, but the reasoning is a little fuzzier than just "Meets WCAG 123". We already have the "show row weights" alternative to address accessibility limitations. I suspect it was created with mouse/pointer related disabilities in mind, but it also happens to be quite good for users with color or contrast perception issues. There's nothing wrong with implementing the approach here IMO, especially since it is addressing a recent regression.

I would like to see a tabledrag-specific followup created, however. I was initially going to say this is fine because seeing table row move as you drag is the non-color indicator. Then I realized the table row doesn't really move with the drag action until the mouse has traveled a decent distance. Compare that to the Sort A List example on this page. That an unambiguous not-color-only visual queue, and tabledrag would feel much nicer were it to do that.

Per my review in #11, and @bnjmnm's review in #13, moving to RTBC.

Followup: #3332668: Tabledrag should provide quicker/smoother visual feedback when dragging