W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2017

RE: Drag and Drop with Drupal 8

From: Matt King <a11ythinker@gmail.com>
Date: Mon, 6 Nov 2017 22:59:45 -0800
To: "'Jennifer Sutton'" <jsuttondc@gmail.com>, "'Mike Gifford'" <mike@openconcept.ca>, "'w3c WAI List'" <w3c-wai-ig@w3.org>
Message-ID: <00aa01d35795$fed8a1b0$fc89e510$@gmail.com>
I’d be happy to help out with designing the Drupal accessibility implementation for this function. A bonus would be that we come up with a reusable pattern and example that I could incorporate into the ARIA Authoring Practices.


In ARIA 1.1, very soon to be final, we deprecated aria-grabbed and aria-dropeffectk. Net, they didn’t really seem to be helping solve the problems they were intended to solve, and the ARIA working group believes there are better approaches.


Similarly, early working drafts of ARIA Authoring Practices included some draft guidance for drag and drop. We didn’t have agreement on its veracity and utility. Given the huge backlog of much more basic issues with the guide, we removed it. We will publish a first release of the Authoring Practices before the end of this year, and it will not include drag and drop.


In the mean time, a task force led by Benetech is digging more deeply into this space. See:



One goal of that work is to help figure out what, if anything, should be included in ARIA 2.0 to facilitate this type of interaction.


For the Drupal use case, I think the move and resize example Jennifer referenced that Jesse and Cordelia from Salesforce put together is a pretty good start for the interaction. The live region messages could use some refinement. And, it might be possible to make it work a bit more gracefully with some screen readers by putting the move and resize buttons in a toolbar:


<div role=”toolbar” aria-label=”Move and Resize”>

  <button>Move Block 1</button>

  <button>Resize Block 1</button>



By using toolbar, with Windows screen readers, you are more likely to end up in a mode where the screen reader will pass through arrow keys. Another option could be to use the application role instead of the toolbar role. We redefined application in ARIA 1.1, and I think this would be an appropriate use. However, I like toolbar better because it would allow the two buttons to be grouped in a single tab stop without requiring additional instructions. It would also facilitate extending functionality with more buttons.


When the “move block 1” button is pressed, I’d recommend changing the label on the button to “Moving block 1”. DOM focus would remain on that button during the moving process. And, during the move, aria-describedby could point to the element containing the live content that describes the current position of the block. It could also point to an element containing the instructions, e.g., press arrow keys to move the block. When the move is complete, the label would change back and the aria-describedby would be removed.


Given that the blocks getting moved around could:

·       contain content that screen reader users may want to read and navigate like a document

·       Could contain many focusable items

·       Could occupy variable numbers of cells in a virtual layout grid


ARIA gridcells or table cells might not be the most usable containers for the blocks of content getting moved around. ARIA grids are not ideal for content where the user may frequently wish to use reading mode (at least not the way screen readers currently implement their reading modes). And, table navigation functions are often confusing when the cells are irregularly shaped.


It is important that screen reader users be able to quickly navigate from one block to another, understand a block’s boundaries, position,  and dimensions, and be able to easily explore its contents. One approach that could accomplish this is to use a div for each block that has role region and a label that helps the user understand which block it is as well as its position. Some off-screen content that is contained in the block (preferably at the end) and referenced by aria-descirbedby that provides more detail about size and position would be helpful. That could be the very same content that is live when the block is getting moved or sized.


For non-screen reader users, it would be very helpful to have a way of quickly moving around the grid to choose which block to operate on. This is where the ARIA grid construct could be helpful. However, there are other ways to provide arrow key navigation among blocks without using an ARIA grid widget. For instance, we could add a “block chooser” button to the toolbar that is inside of each block. When pressed, it would highlight the block and visually indicate that pressing arrow keys moves the highlight around to different blocks rather than moving the currently highlighted block. If a screen reader user were using this, a live region that is outside the layout canvas could help the user understand which block is highlighted. At a DOM level, the focus would move from region to region, and when enter is pressed, the focus would land on the “block chooser” button that is inside the currently highlighted block.



Matt King


From: Jennifer Sutton [mailto:jsuttondc@gmail.com] 
Sent: Monday, November 6, 2017 11:54 AM
To: Mike Gifford <mike@openconcept.ca>; w3c WAI List <w3c-wai-ig@w3.org>
Subject: Re: Drag and Drop with Drupal 8


Greetings, WAI and Mike:


This kind of Drag and Drop functionality is needed, more and more, and even if/when it's done right, I think it's so rarely done that I'm not sure screen reader users (only, here) will actually have seen it often enough to understand how to do it.


In Mike's issue, here, for easy reference:



there's discussion of using ARIA grid. Again, grids are rare, and often not done right, so I'm not sure whether that would be necessary for drag and drop; it might be "over-ARIA-fication."

I'll add a few more links, below, but suffice it to say, in my mind, WordPress *may* also come to need this functionality, such as, perhaps, via the new Gutenberg editor. So, it would be great if folks could collaborate/learn from one another.

To that end, I'm bcc-ing some WordPress folks who, as far as I know, aren't on the WAI list. And I'm including some others who may have an interest/additional contributions.


To my way of thinking, user testing with a range of users will be essential to getting this right, but the CMSs are in an excellent position to serve as training grounds for end users + promote tested approaches.


There are several more links, below, perhaps for addition to Mike's Drupal issue. And good luck to all.




A discussion of four possible patterns -- post via SalesForce:


This, from Shopify, which has been begun, but wasn't finished, last I looked at it:

This SitePoint article by James Edwards that came out a while ago, but likely has concepts worth considering:

And finally, this, related to Drag and Drop and React, which may not have much to do with accessibility, but does seem to have some useful usability concepts:

On 11/5/2017 11:52 AM, Mike Gifford wrote:

We’ve built a bunch of great accessibility solutions in Drupal 8 Core, but we haven’t modernized our Drag/Drop solution significantly. Because of some great innovations with a Layout Builder, we’re having to work on a 2D solution to this problem.  


We’ve got links to some terrific ideas here, but it seems that there isn’t a good best practice out there that works for grids or other complex spatial organization. 



We’re looking for examples of what we might have missed here.  Also, if there are folks interested in working on a common GPL solution to this, that would be amazing.




Mike Gifford, President, OpenConcept Consulting Inc. 
Drupal 8 Core Accessibility Maintainer - https://drupal.org/user/27930
Twitter: @mgifford @openconcept_ca

Open source web development for social change - http://openconcept.ca
Drupal Association Member | Acquia Partner | Certified B Corporation


Received on Tuesday, 7 November 2017 07:00:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:37:11 UTC