- Issue created by @jessebaker
- @jessebaker opened merge request.
- 🇺🇸United States bnjmnm Ann Arbor, MI
This approach doesn't seem ideal for screenreader users, as each component being conveyed will now begins/ends with drop zone labels in all situations - not just when they are adding/moving components in the layout
The Github blog has a good writeup on how they approached Drag and Drop. It's not something we'd need to follow exactly, but it showcases several things we should consider.
One part that stands out is the form used to add/move items without drag and drop:
XB probably needs something like this as an accessible alternative for users unable to Drag and Drop. Although that should be done in another issue, it's implementation would likely require drop targets to have attributes with information similar to what was suggested here.
That's a long way of saying:
Lets not overwhelm users by using aria-label, but instead use custom attributes, and perhaps have dedicated before and after attributes that can be used by a future "position this component in layout" form - 🇬🇧United Kingdom jessebaker
I've removed mention of a11y from the issue - the original impetus for doing this work was not about a11y, but improving testability. I think you are spot on that the number of labels is likely to be overwhelming and it wasn't something I considered. Moving to use another attribute is a sensible/workable solution for testing and programmatic drag/drop.
DNDKit (the library we are using for the preview drag and drop interactions) has a lot of docs on a11y and keyboard (no mouse) use which we should be aware of when we tackle a11y.
https://docs.dndkit.com/api-documentation/sensors/keyboard
https://docs.dndkit.com/guides/accessibility