Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.On table with drag&drop when dragging with the keyboard arrow keys there should be a visual feedback when moving to a place where the current element is not possible to be placed at.
Example:
When going left like in that image below you don't get any feedback about that this move was not allowed. Instead of just doing nothing there should to be at least something to be happening, like showing an information that that move was not possible.
A first approach would be to show a red Icon, instead of the black one, for about 1 second. Then switching back to the black one.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | Selection_245.png | 9.8 KB | kwoxer |
| #7 | Selection_242.png | 13.52 KB | kwoxer |
| #3 | 2912737-3.patch | 2.27 KB | geophysicist |
Comments
Comment #2
BarisW CreditAttribution: BarisW as a volunteer and at LimoenGroen commentedHey kwoxer,
Need review is only for when there is an actual patch to review. Let's put this in the default state.
Also, this isn't a major issue IMHO. Lastly, tags like 'needs accessibility review' are to be added when there is something for the accessibility team to test.
Comment #3
geophysicist CreditAttribution: geophysicist as a volunteer commentedComment #4
BarisW CreditAttribution: BarisW as a volunteer and at LimoenGroen commentedComment #5
kwoxer CreditAttribution: kwoxer commentedComment #6
kwoxer CreditAttribution: kwoxer commentedComment #7
kwoxer CreditAttribution: kwoxer commentedComment #8
kwoxer CreditAttribution: kwoxer commentedComment #9
BarisW CreditAttribution: BarisW as a volunteer and at LimoenGroen commentedThanks for the patch. Great work!
A few things:
Comment #10
kwoxer CreditAttribution: kwoxer commentedThank you very much @geophysicist.
I tested your Patch together with https://www.drupal.org/files/issues/2725259-31.patch and it works properly.
Here an image:
But as @BarisW said, screen readers are missing.
Comment #11
geophysicist CreditAttribution: geophysicist as a volunteer commentedHey
I will add screen readers, move code to es6 file as soon as possible (3-5 days)
Also will try to add tests.
Comment #12
kwoxer CreditAttribution: kwoxer commented@geophysicist how is it going with the table drag, did you found some time already? :)
Comment #13
geophysicist CreditAttribution: geophysicist as a volunteer commented@kwoxer not yet. Sorry about that. But i'm working in the US this month and i'll try to find some time to finish this task.
P.S. my docker machine "vienna2017" is still running.
Comment #16
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedComment #17
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedFrom the issue summary, and screenshot #10:
If colour is the only indication, then it doesn't satisfy WCAG 1.4.1 Use of Color: "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)"
I'm not sure what else to suggest as an indication. In native desktop applications, it would probably also involve whatever passes as a system bell (typically a sound, a screen flash, or colour inversion, respecting user's OS-level preferences). One way to do it is a visual pop-up text warning positioned on the same row (similar to a tooltip). That would need to linger for more than one second though.
Feedback after attempting a non-allowed movement isn't the only approach this could take. Turning the idea around, can we indicate what movements are allowed? For example, change the icon which is used for the drag handle. A tabledrag that doesn't allow nesting could have an icon which only had the vertical arrows instead of all four direction. Both approaches could be combined.
re #9:
For the time being, I wouldn't try to address screenreaders here. The tabledrag hasn't ever worked well with screen readers, even when it was working for sighted keyboard users. There are bigger issues to solve for screen readers, and fixing those will involve a bigger rework of tabledrag. I've filed #3027229: Modernize tabledrag accessibility. for that.
Comment #18
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedI manually tested patch #3 (with the latest patch at #2725259: [regression] Table Drag handles no longer respond to up/down arrow keys, it seems to work in all the right circumstances.
Comment #19
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedChanging the parent issue, there's an umbrella plan for various tabledrag accessibility/usability improvements now.
Comment #20
tim.plunkettFixing tags