adobe
Remove warning requesting that collections with DnD have a button with slot="drag"
Provide a general summary of the issue here
A draggable button isn't the only way to provide an alternative, accessible method for DnD.
I haven't found anything in W3 and the Aria spec that indicates this has to be mandatory.
A very common pattern is to have, within the item, a dropdown menu where one of the options is "move".
🤔 Expected Behavior?
slot="drag" should not be mandatory
😯 Current Behavior
The console shows the following warning:
Draggable items in a GridList must contain a <Button slot="drag"> element so that keyboard and screen reader users can drag them.
💁 Possible Solution
One option would be to be able to deactivate the warning in some way, although in my opinion it should not appear directly.
🔦 Context
No response
🖥️ Steps to Reproduce
See the console on https://codesandbox.io/p/sandbox/thirsty-sky-mtqsp9
Version
1.0.0
What browsers are you seeing the problem on?
Chrome
If other, please specify.
No response
What operating system are you using?
Windows
🧢 Your Company/Team
No response
🕷 Tracking Issue
No response
Thanks for the issue, do you want the menu item to trigger our drag and drop system? or would it bypass it entirely?
No, please, thanks to you.
I couldn't tell you exactly, I'm still experimenting.
Regardless of that, what I want is for the warning to be removed, since it is incorrect.
Any updates from your experimentation? We are of different minds depending on the need here.
Sorry, I don't understand what information you would like to know exactly. I want to bypass the restriction, and not offer an alternative drag and drop method. As I said, I think the warning is incorrect since I haven't found anything in W3 and the Aria spec that indicates this has to be mandatory.
Our stance is to ensure accessible patterns. This includes drag and drop. If it's something a mouse user can do, then it's something everyone can do. If you want to offer an alternative for activating drag and drop, that's fine, but we want to know more about the use case so that we can see if we can check for either implementation and provide docs around how we'd expect it to work.
For instance, maybe that "Move to" button enters our drag and drop Or maybe it opens a dialog where you have a list of names of other locations
If it's the first one, we'd need to add some ways of starting the drag and drop programmatically. For the second way, we'd need to discuss more.
So what we want to know is, how do you expect this to work in your app? Do you expect 1, or 2? Or some other option I haven't named?
I really don't like having to decide between those 2 options.
If I had to choose, I would say option 2 of those you mention, since my idea is at some point when I have time to implement option 2.
In the meantime though, I don't want to have an alternative method of DnD to mouse or touch. I consider those two (mouse and touch) to be sufficient and that we should be able to at least opt out of the warning in some way.
In fact, I think DnD with the keyboard is an anti-pattern. I didn't intend to make this thread a discussion about that but it seems that you are very convinced that DnD should always be able to be done with a keyboard.
I would think that if the library is called React-aria it is because it follows the aria spec. But here I think there is an attempt to impose a philosophy of accessibility that I do not find anywhere in the aria specification and that also seems incorrect IMHO.
From WCAG: https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
Thank you very much. That was what I was trying to find and couldn't. In that case, I would like to be able to implement option 2. That is, the "Move to" button opens a dialog where you have a list of names of other locations.