RE: Drag and Drop with Drupal 8

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.

I'd also be curious for general comments on whether folks view it as a 
good thing that 2.1 is seeking to eliminate dependence on complex gestures 
by authors.

Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:   "Sean Murphy (seanmmur)" <seanmmur@cisco.com>
To:     Matt King <a11ythinker@gmail.com>, "'Jennifer Sutton'" 
<jsuttondc@gmail.com>, "'Mike Gifford'" <mike@openconcept.ca>, "'w3c WAI 
List'" <w3c-wai-ig@w3.org>
Date:   2017-11-07 04:19 PM
Subject:        RE: Drag and Drop with Drupal 8



Matt,
 
Liked the concept you outlined. What about relationship? A applied 
relationship for objects I have seen implemented before  I have outlined 
below:
 
When you have a blank canvas and you are laying out elements. There is an 
relationship from the top edge (y) and the left edge (x) of the parent 
container. The top left hand corner of the child element is the reference 
point. The element will have a defined domention. For example using 
pixcels as the means of measuring which is just for example purposes to 
explain this concept which I have seen in Visual Basic 6 with Jaws for 
windows in the early 2000’s.
 
A container has 1000 pixcels across (x) and 1000 pixcels down (y). the 
person places a element (object) like a button  100 pixcels down from the 
top edge of the container () and 50 pixcels from the left edge (x). The 
screen reader says “50 by 100 pixcels for the button using the x/y 
coordinates. The screen reader knows the size of the button height and 
width in pixcels. If another object overlappeds the button, then the user 
is alerted of the new element being on top of the other element. In this 
quick example, there was extra information provided as well when objects 
were overlapped. This worked quite well for containers inside containers.
 
When I used VB6, this approach was quite usable and gave you an 
understanding where elements was on the page. The above would work with 
the concept you outlined as well. 
 
 











Sean Murphy
ENGINEER.CUSTOMER SUPPORT
seanmmur@cisco.com
Tel: +61 2 8446 7751
 
 
 

 





Cisco Systems, Inc.
The Forum 201 Pacific Highway
ST LEONARDS
2065
Australia
cisco.com






Think before you print.
This email may contain confidential and privileged material for the sole 
use of the intended recipient. Any review, use, distribution or disclosure 
by others is strictly prohibited. If you are not the intended recipient 
(or authorized to receive for the recipient), please contact the sender by 
reply email and delete all copies of this message.
Please click here for Company Registration Information.





 
 
From: Matt King [mailto:a11ythinker@gmail.com] 
Sent: Tuesday, 7 November 2017 6:00 PM
To: 'Jennifer Sutton' <jsuttondc@gmail.com>; 'Mike Gifford' 
<mike@openconcept.ca>; 'w3c WAI List' <w3c-wai-ig@w3.org>
Subject: RE: Drag and Drop with Drupal 8
 
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:
https://github.com/benetech/DiagramDevelopers-DragAndDrop/wiki/DragAndDrop-Analysis

 
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>
</div>
 
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.
 
Hth,
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:
            https://www.drupal.org/node/2920006

 
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.
Best,
Jennifer
 
A discussion of four possible patterns -- post via SalesForce:
https://medium.com/salesforce-ux/4-major-patterns-for-accessible-drag-and-drop-1d43f64ebf09


This, from Shopify, which has been begun, but wasn't finished, last I 
looked at it:
https://shopify.github.io/draggable/


This SitePoint article by James Edwards that came out a while ago, but 
likely has concepts worth considering:
http://www.sitepoint.com/accessible-drag-drop/


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:
https://medium.com/@alexandereardon/rethinking-drag-and-drop-d9f5770b4e6b



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. 
   https://www.drupal.org/node/2920006

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