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

  1. 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.
  2. Use the things we learn to define what features (behaviours) an accessible drag-and-drop interface will need.
  3. 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):

Reference documentation to review:

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:

Mockup illustrating a possible design for moving Layout Builder blocks with a keyboard

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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

andrewmacpherson created an issue. See original summary.

andrewmacpherson’s picture

Issue summary: View changes

Copied 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:

  • It only has examples of draggable rows, not 2-dimensional movement.
  • The first example has clear grab-buttons with a clear icon, text fallback, and focus styles.
  • The grab behaviour isn't as discoverable in the second example.
  • The grab-button is a <button> so we'd expect enter and spacebar to both activate it. However enter and spacebar have two different behaviours:
    • Enter toggles the grab state. To move it you either press enter (grab), arrows keys, enter (ungrab).
    • Spacebar acts more like a shift key, so it's grabbed while spacebar is held down. To move it, press spacebar + arrow keys together.

    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.

  • Escape cancels the re-ordering, and leaves things where they were before you tried dragging. Nice, assuming you discover it.
  • aria-live announcements say what the new position is.
  • The DragonDrop has it's own 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 own aria-live region.
  • The aria-live messages tend to queue up, so you can sometimes hear a long sequence of grabbed/ungrabbed messages. Meh, needs a throttle.
  • The grab-buttons are all 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.
  • The DragonDrop demo does not use HTML tables or ARIA grid semantics. It's just draggable rows, so it gets away with an ordered list. For our layout builder, I still think we'll need ARIA grid.
andrewmacpherson’s picture

just in case we re-parent this.

andrewmacpherson’s picture

Issue summary: View changes

Adding 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.

andrewmacpherson’s picture

Issue summary: View changes

Dragula deserves a more thorough review though, so moving to the tasks section.

andrewmacpherson’s picture

Issue summary: View changes

Found a pull request for keyboard controls in hootsuite/grid. https://github.com/hootsuite/grid/pull/31

DuaelFr’s picture

Issue summary: View changes

Adding some leads to check.

andrewmacpherson’s picture

Issue summary: View changes

Adding...

johnny/jquery-sortable. This one has lots of methods and events, like afterMove.
dbushell/Nestable

droplet’s picture

If 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)

andrewmacpherson’s picture

Title: Evaluate drag-and-drop grid JS libraries for accessibility » Research and define accessibility of drag-and-drop grid interfaces.
Issue summary: View changes

Just 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.

Bojhan’s picture

I 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.

mgifford’s picture

I 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.

mgifford’s picture

Bryan 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.

mgifford’s picture

Issue summary: View changes

adding 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)."

mgifford’s picture

Issue summary: View changes
Related issues: +#2865199: Adopting ARIA Grid pattern

Adding link suggested by @jessebeach - http://oaa-accessibility.org/example/17/

andrewmacpherson’s picture

Issue summary: View changes

This 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.

mgifford’s picture

This 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.

mgifford’s picture

droplet’s picture

@ #16,

the homepage of Shopify/draggable is a demo. (but do not keyboard accessiable at the moment)

EclipseGc’s picture

@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

mgifford’s picture

@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.

mgifford’s picture

Issue summary: View changes
mgifford’s picture

Issue tags: +wcag21

Michael 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

andrewmacpherson’s picture

Nice research @mgifford

tim.plunkett’s picture

Issue tags: +Blocks-Layouts
mgifford’s picture

mgifford’s picture

@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

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

yoroy’s picture

mgifford’s picture

Issue summary: View changes
mgifford’s picture

Issue summary: View changes
mgifford’s picture

Issue summary: View changes
mgifford’s picture

@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.

mgifford’s picture

Issue summary: View changes
mgifford’s picture

Issue summary: View changes
mgifford’s picture

Still 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.

Rene Bakx’s picture

#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

mgifford’s picture

Issue summary: View changes

Thanks @Rene for providing the link. I've added it to the issue description.

mgifford’s picture

So 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

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andrewmacpherson’s picture

Title: Research and define accessibility of drag-and-drop grid interfaces. » Research accessibility of drag-and-drop grid interfaces.
Issue summary: View changes

So 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.

andrewmacpherson’s picture

Aside 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.

andrewmacpherson’s picture

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

xjm’s picture

Priority: Normal » Major
Issue summary: View changes
FileSize
196.84 KB

Adding 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.

Wim Leers’s picture

Issue summary: View changes

In 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:

This ability to move around the page directionally is called spatial navigation.

Figure 1: Application using 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/.

mgifford’s picture

Issue summary: View changes
mgifford’s picture

Wanting 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

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

mgifford’s picture

Issue summary: View changes
Issue tags: -JavaScript +JavaScript

Adding sitepoint example

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mgifford’s picture

Issue summary: View changes

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mgifford’s picture

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mgifford’s picture

Issue summary: View changes

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mgifford’s picture

Issue tags: +wcag251
Freddy Rodriguez’s picture

The dxpr builder seems a good test case.

mgifford’s picture

Issue summary: View changes

Adding new article, The Road to Accessible Drag and Drop (Part 1) https://www.tpgi.com/the-road-to-accessible-drag-and-drop-part-1/