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.

Remaining tasks

Drag-and-drop interfaces to assess (code):

Reference documentation to review:

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.

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