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
- The upcoming CSS Spatial Navigation Level 1 specification — being worked on in https://github.com/WICG/spatial-navigation
- W3C's Draft CSS Spatial Navigation Level 1
- Sitepoint Drag & Drop & GitHub Code
- Scalable Accessible Drag and Drop by Bryan Garaventa & Whatsock Drag Template
- Discord's react-dnd-accessible-backend
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
- Screen readers and drag-and-drop, part 1: draggable elements
- React Aria & React Spectrum
- TPGi The Road to Accessible Drag and Drop (Part 1)
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.
Original mockups for #2995689: Allow reordering blocks without a pointer device:
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.
Comment | File | Size | Author |
---|---|---|---|
#45 | Add - Page - Example Content - Toolbar - 1.2,2.png | 196.84 KB | xjm |
Comments
Comment #2
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedCopied from #2905922-80: Implementation issue for Layout Builder
Via @webaxe on Twitter, we've learned of DragonDrop (demo) which has a nice(-ish) keyboard and screen reader experience.
Here's an initial review of the DragonDrop demo:
<button>
so we'd expect enter and spacebar to both activate it. However enter and spacebar have two different behaviours:This different behaviour is a bit hard to discover. I initially pressed + released spacebar, then used arrows. My first impression was that it was broken.
aria-live
announcements say what the new position is.aria-live
region, i.e. we wouldn't use drupal.announce(). This is fine, in fact it's already the case that our autocomplete widgets have their ownaria-live
region.aria-live
messages tend to queue up, so you can sometimes hear a long sequence of grabbed/ungrabbed messages. Meh, needs a throttle.aria-describedby
a piece of visible help text. This gets announced after every movement, which is very verbose and repetitive. It will likely respect the verbosity settings of different screen readers, but they don't all offer this. I didn't like this part.Comment #3
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedjust in case we re-parent this.
Comment #4
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedAdding bevacqua/Dragula and Hootsuite/grid
I didn't think much of Dragula after a 5 minute try-out. Nothing considered for screen readers. Active issue queue in github, but no mention of screen readers or accessibility there.
Comment #5
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedDragula deserves a more thorough review though, so moving to the tasks section.
Comment #6
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedFound a pull request for keyboard controls in hootsuite/grid. https://github.com/hootsuite/grid/pull/31
Comment #7
DuaelFrAdding some leads to check.
Comment #8
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedAdding...
johnny/jquery-sortable. This one has lots of methods and events, like afterMove.
dbushell/Nestable
Comment #9
droplet CreditAttribution: droplet commentedIf we are not used for "Layout Builder to core" only, then Performance + React compatible is more matter than accessibility at first. (Because the drag actions are customisable usually and it's a must-have requirement for the CORE lib IMO). So to make it achieves our accessibility standard (with our perfect markups) is easier than another 2 issues I mentioned previously)
Comment #10
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedJust to be clear, this issue isn't about adopting a 3rd party library in core. Yet ;-)
The main goal is to figure out what we are trying to build, and how we can achieve as much accessibility as possible. The first problem is that we don't know of any drag-and-drop UIs (or libraries) in the wild which have a good level of accessibility.
I've expanded the issue summary, and defined the goals better.
Comment #11
Bojhan CreditAttribution: Bojhan as a volunteer commentedI am just wondering, to what extent would forms options suffice as alternative? We went down this road before, and I remember it being really hard to get right.
Comment #12
mgiffordI wanted to get @JesseBeach view on this and she said:
"It works for flat grids (no grids in grids) with simple content -- text or a single actionable item."
Not sure that the Layout Builder fits that. Not very simple content.
Comment #13
mgiffordBryan Garaventa of whatsock.com has posted this guide (click to expand it):
http://whatsock.com/tsg/#tgl-2-12
With this demo:
http://whatsock.com/tsg/Coding%20Arena/Drag%20and%20Drop/demo.htm
It doesn't seem to allow me to re-organize the books on the shelf though (pretty amazing list of books I have to say!).
Thanks for the pointer Jennifer.
Comment #14
mgiffordadding link and reference to http://w3c.github.io/html/editing.html#drag-and-drop
"However it is implemented, drag-and-drop operations must have a starting point (e.g., where the mouse was clicked, or the start of the selection or element that was selected for the drag), may have any number of intermediate steps (elements that the mouse moves over during a drag, or elements that the user picks as possible drop points as he cycles through possibilities), and must either have an end point (the element above which the mouse button was released, or the element that was finally selected), or be canceled. The end point must be the last element selected as a possible drop point before the drop occurs (so if the operation is not canceled, there must be at least one element in the middle step)."
Comment #15
mgiffordAdding link suggested by @jessebeach - http://oaa-accessibility.org/example/17/
Comment #16
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedThis weekend I found Shopify/draggable. This one actually claims to be accessible, unlike many other libraries I've found. It doesn't seem to have an online demo, and I have yet to find time to test it.
It has a large number of namespaced JS events, so we can latch our own behaviours onto these. (For example: "DragOverContainerEvent gets triggered when hovering over a container, other than the sourceContainer in DragStartEvent".) We could perhaps fire brief drupal.announce() messages after certain events, if we thought some extra information was necessary.
Comment #17
mgiffordThis issue is being discussed on the w3c-wai-ig@w3.org mailing list as right now there isn't a good pattern.
Mark Weiler writes:
"Is there WCAG 2.0 success criteria a drag and drop component should meet (e.g., 1.1.1, 2.1.1, 2.1.2, 1.3.1, 1.3.2, 2.4.3, 3.3.2)?"
Sean Murphy thought that 4.1.2 might also be related as well as success criterion related to errors and information. ARIA 1.0 had information on drag and drop but ARIA 1.1 dropped it.
Sean then writes:
"I have seen some implementation of drag and drop. None of them work with a screen reader. Some of the times I have seen it, I didn’t think it was required. The best pattern I can think of is:
Using the cut, copy and paste keyboard commands built into the OS. There are challenges around this as you do not want to override the ability of cut/copy/paste when a web page is selected. If the shortcut keys can be isolated to the elements, then this would work.
Using the spacebar to select the item to be copied. When the focus is on the area where the content is meant to be pasted. Pressing spacebar again.
I prefer the first option as it is more natural for a keyboard user."
Matt King responded with:
"I like cut/paste paradigm for a lot of things, especially in lists like in MacOS Finder or Windows Explorer.
However, I have found moving blocks or cards around with arrow keys pretty efficient. One reason why it works so well is you only have one action for ending the process and are able to have the landing position be at the very start or very end of the positional grid. With the paste paradigm, there is always the issue of moving something to the first or last position, depending on whether you have paste drop after or before the currently focused item. And, there is always a bit of learning that goes along with where paste will drop it. IOS addressed this by having multiple actions for ending the move, which adds a little complexity but is much better for a touch interface.
If using arrow keys with a live region where the live region tells you the current position, you always know where it will land and can land it in any position with a single landing command.
BTW, hats off to GitHub for responding to my request to make GitHub projects keyboard accessible. you can now rearrange cards in a GitHub project this way. It is not yet as screen reader friendly as I would like it. But, they got a lot of it right."
I set up a GitHub project to test it out and it worked reasonably well for me here https://github.com/mgifford/a11y-contracting/projects/1
Definitely some issues there, but something to work from.
Comment #18
mgiffordhttps://github.com/benetech/DiagramDevelopers-DragAndDrop/wiki/DragAndDr...
Comment #19
droplet CreditAttribution: droplet commented@ #16,
the homepage of Shopify/draggable is a demo. (but do not keyboard accessiable at the moment)
Comment #20
EclipseGc CreditAttribution: EclipseGc at Acquia commented@mgifford
That definition applies to layout_builder. We do grids in grids as well, but you can only ever interact with one grid at a time (only one grid edit on a given url. Other grids, which might be embedded, must be edited on their own in a separate space).
FWIW, the discussion internally to the Layout team has been that we want to include arrow key support to allow for quick and easy moving of the blocks. At least, that's our current idea.
Eclipse
Comment #21
mgifford@EclipseGc great to know you're already thinking about usefulness of adding arrow key support.
There's some good conversation going on right now about how to make this accessible:
http://lists.w3.org/Archives/Public/w3c-wai-ig/2017OctDec/0081.html
Sounds like a good priority to force grids to be edited separately even if they are embedded in another grid. Think that's a reasonable explanation.
Comment #22
mgiffordComment #23
mgiffordMichael Gower from IBM Accessibility commented that this might be tied to WCAG 2.1 as well:
"Does the existence of the new 2.5.1 Pointer Gestures SC in WCAG 2.1 affect this conversation? It will effectively outlaw the use of drag and drop as the only means of gesture-based action. If that passes, the requirement for all functionality to be operated with "a single untimed pointer gesture" will likely result in workarounds for touch/mouse users that keyboard users will be able to take advantage of."
https://www.w3.org/TR/WCAG21/#pointer-gestures
Comment #24
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedNice research @mgifford
Comment #25
tim.plunkettComment #26
mgiffordSome more research to consider:
https://www.linkedin.com/pulse/important-considerations-regarding-access...
Comment #27
mgifford@andrewmacpherson got a good response to dragon-drop feedback [#2920006:2] earlier today - https://github.com/schne324/dragon-drop/issues/6#issuecomment-352192786
Also traction on Shopify's draggable efforts https://github.com/Shopify/draggable/issues/48#issuecomment-351845449
Comment #29
yoroy CreditAttribution: yoroy at Roy Scholten commentedMaybe this is useful: https://medium.com/salesforce-ux/4-major-patterns-for-accessible-drag-an...
Comment #30
mgiffordComment #31
mgiffordComment #32
mgiffordComment #33
mgifford@yoroy - Wanted to note that this link was already in the description. Thanks for highlighting it though. Made me want to re-organize the lists a bit because I missed it too.
I also wanted to thank all the support from Jennifer Sutton on refining this further and promoting it within the broader accessibility community.
Comment #34
mgiffordComment #35
mgiffordComment #36
mgiffordStill looking for the code from - https://react-beautiful-dnd.netlify.com/
Discussions online with https://twitter.com/seancurtis
It's a React solution so potentially could work well with new admin patterns.
You press space to select the item that you want to move (and to unselect it). Works fine with keyboard only users.
Comment #37
Rene Bakx#36 you mean the actual source? It's a project from Atlassian and you can find the source here : https://github.com/atlassian/react-beautiful-dnd
Comment #38
mgiffordThanks @Rene for providing the link. I've added it to the issue description.
Comment #39
mgiffordSo if we're moving to React, then maybe it makes sense to look most closely at this issue:
https://github.com/atlassian/react-beautiful-dnd/releases/tag/v5.0.0
Comment #41
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedSo far, this issue has gathered some approaches (libs, tutorials, etc) but it hasn't done an in-depth comparison of these. It's time to move onto that because layout builder accessibility is a pressing concern now. I've started a list of comparison points to consider.
Comment #42
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedAside from layout builder, it's also worth making our
tabledrag.js
better. Currently that doesn't really work for screen readers, and we kept the fallback method with row weights. But things have moved on, and some of the approaches here can help to improve tabledrag, even if they weren't a good match for layout builder.Update: I filed #3027229: Modernize tabledrag accessibility.
Comment #43
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedComment #45
xjmAdding the original mockups from #2995689: Allow reordering blocks without a pointer device to the issue summary so that we have them for the next-gen version.
Comment #46
Wim LeersIn following up on all things related to the HTTP Workshop before DrupalCon, I just stumbled upon https://drafts.csswg.org/css-nav-1/, which seems to cover many of the accessibility challenges in Layout Builder!
In fact, it specifically covers keyboard navigation in a grid-like layout:
It even comes with a polyfill, saw its last commits 7 hours ago, and probably most importantly: there's a demo of various complex use cases: https://wicg.github.io/spatial-navigation/demo/.
Comment #47
mgiffordComment #48
mgiffordWanting to followup about a thread on Twitter with Florian Riva, about CSS Spatial Navigation:
https://twitter.com/Florianrival/status/1119323033267732481
https://twitter.com/Florianrival/status/1119323625960742912
https://twitter.com/Florianrival/status/1119324143672025089
He also pointed to this project again as a good React base for this type of process:
https://github.com/atlassian/react-beautiful-dnd
Comment #52
mgiffordAdding sitepoint example
Comment #55
mgiffordComment #57
mgiffordAdding https://www.darins.page/articles/screen-readers-drag-drop-1 to list
Comment #59
mgiffordComment #61
mgiffordComment #62
Freddy RodriguezThe dxpr builder seems a good test case.
Comment #63
mgiffordAdding new article, The Road to Accessible Drag and Drop (Part 1) https://www.tpgi.com/the-road-to-accessible-drag-and-drop-part-1/