Problem/Motivation
As part of #2884601: Add a Layout Builder to core we want to add a drag-and-drop interface for arranging block layouts spatially.
This should be accessible, but so far it isn't very clear what behaviours we need in order to achieve this. So we need to research approaches for making it accessible. The layout builder is our initial use-case, but we may find others.
Proposed resolution
- Find some drag-and-drop interfaces, assess them for accessibility. These could be:
- JS libraries, jquery plugins, web components
- Web applications in general (even if they are not re-usable components)
- Drag-and-drop interfaces in desktop applications
- Drag-and-drop interfaces in mobile applications
- Accessibility reference material, tutorials, etc.
- Use the things we learn to define what features (behaviours) an accessible drag-and-drop interface will need.
- Decide whether it's worth having a re-usable component or library in core, versus building drag-and-drop interfaces on a case-by-case basis.
Approaches which we can review
Drag-and-drop interfaces to assess (code):
- DragonDrop (demo). Reviewed in comment #2 - see Smashing Magazine article below
- jQuery.ui.sortable - has a relevant bug - https://bugs.jqueryui.com/ticket/9633. TODO the range of configuration options and demos need further study.
- Dragula - 5 min review in comment #4, not very accessible. TODO a more thorough review
- hootsuite/grid (demo) - accessibility unknown. Has a pull request for keyboard controls.
- gridstack.js (demo)
- GrapesJs (demo)
- johnny/jquery-sortable (demo).
- dbushell/Nestable (demo).
- Drag and Drop: aria-activedescendant
- Shopify/draggable
- benetech DragAndDrop
- React Beautiful DND Example& React Beautiful DND Code
Reference documentation to review:
- Smashing Magazine: Enter The Dragon (Drop): Accessible List Reordering
- Salesforce UX: 4 Major Patterns for Accessible Drag and Drop
- Grace Noh: Drag and Drop for Design Systems
- W3C ARIA Authoring Practices
- Other docs from the W3C WAI-ARIA suite
- The AccDc training + reference material from whatsock.com
- The article by Bruce Lawson. TODO find link.
- HTML 5.3 Draft
Analysis method
Comparison points and questions to consider. (TODO: any more?)
- Library dependencies
- License
- Support status and release process
- Is it 1-dimensional (up/down) or 2-dimensional (up/down/left/right)
- By what means are allowed movements or destinations computed? (When, how, ...)
- What are the scope of the accessibility claims for each approach? (e.g. implemented keyboard control, but haven't addressed informing screen reader users of action outcomes)
- Similarly, how do these work in practice?
- What constitutes "grabbed"? When a grab-handle button has focus? Or when a grab-handle button is pressed (toggle to grab/drop)? This point may have a big impact for speech control.
TODO: Analysis results
TBD.
User interface changes
This is a research task, initially to support draggable layout builder in core.
API changes
This is research, which may eventually lead to a new JS component in core.
Data model changes
Unknown. A new API may have some configuration options.