W3C home > Mailing lists > Public > public-pfwg@w3.org > March 2014

Re: Regarding ARIA drag and drop?

From: Matthew King <mattking@us.ibm.com>
Date: Mon, 17 Mar 2014 05:43:44 -0700
To: "public-pfwg" <public-pfwg@w3.org>
Cc:
Message-ID: <OFDC78F1F7.CC63BAEC-ON88257C9E.004391B0-88257C9E.0045EC2A@us.ibm.com>
I am not sure I would find that very easy from the end user perspective 
unless that region target was quite large and easy to locate. I don't know 
if there is anyway to control the size of that drop target in current code 
because VO announces only the start and end of the region when switing; I 
find it hard to locate by touch.

I would find it much easier to press and hold on the item I want to add to 
the cart and have a menu appear with add to cart as the first item, add to 
wishlist as second, etc.

>From the human factors perspective, for blind users, I am not crazy about 
the idea of hunting for drop targets while dragging. While it is fewer 
gestures, most of the time, I do not think it is a good idea to expect the 
user to continuously hold to both drag and hunt with a single gesture. If 
the user can lift his or her finger in the process and use multiple 
gestures to locate the drop target, it overcomes many of the challenges of 
touch and uncertain orientation, unknown target size, etc. 

I can imagine interface where perhaps the entire top or bottom half (in 
portrate)  is announced as the drop target only while dragging and this 
could make it easier. But, it doesn't sound very discoverable. The screen 
would have to be read differently when dragging than it would while 
exploring and not dragging. Perhaps with enough hints it would be 
learnable.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   "Bryan Garaventa" <bryan.garaventa@ssbbartgroup.com>
To:     Matthew King/Fishkill/IBM@IBMUS, 
Cc:     "Joseph Scheuhammer" <clown@alum.mit.edu>, "James Craig" 
<jcraig@apple.com>, "public-pfwg" <public-pfwg@w3.org>
Date:   03/14/2014 03:56 PM
Subject:        Re: Regarding ARIA drag and drop?



Personally I would love it if the following syntax could be announced on 
touch screen devices when moving over it:
 
<div role="region" aria-label="Shopping Cart" aria-dropeffect="move" 
></div>
 
If it were announced when moving over it, you might be able to simply hold 
your finger down on the object you wish to drag until it grabs hold, then 
slide over to the region which might be announced as "Shopping Cart region 
droppable", then let go to complete the action.
If this were the case, this whole process would be much simpler :)
 
 
----- Original Message ----- 
From: Matthew King 
To: Bryan Garaventa 
Cc: Joseph Scheuhammer ; James Craig ; public-pfwg 
Sent: Friday, March 14, 2014 2:55 PM
Subject: Re: Regarding ARIA drag and drop?

Why can't you simply focus on the drop target and do the equivalent of 
paste? For keyboard, cut/copy/paste is a paradigm that can equal drag/drop 
can it not? If you can support selection for drag, you can support it for 
"copy" or "cut", which is the equivalent to "Drag". If the dragable 
element can be grabbed to drag, I would think it could have a context menu 
with "Copy" and "Cut". 

In the touch interface, hold for context actions is pretty common. 

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com 



From:        "Bryan Garaventa" <bryan.garaventa@ssbbartgroup.com> 
To:        "Joseph Scheuhammer" <clown@alum.mit.edu>, "James Craig" 
<jcraig@apple.com>, 
Cc:        "public-pfwg" <public-pfwg@w3.org> 
Date:        03/14/2014 01:40 PM 
Subject:        Re: Regarding ARIA drag and drop? 



No worries, I understand the concerns.

I'm trying to figure out several things with this, and it's related to a 
project for a client.

Essentially there are variable drag and drop objects that may be named 
anything, and they are being compared with other objects by dragging these 

first objects onto the ones to be matched. There are no definites, because 

the implementation is configurable with variable content by others. 
Additionally, this implementation needs to work equally across desktop 
browsers for keyboard support as well on iOS devices.

So, how does ARIA drag and drop help with this? From what I'm seeing, it 
doesn't really, because support in desktop browsers for keyboard users 
doesn't necessarily translate to screen reader accessible components.

I like the menu idea, but how do you name the drop targets when it's not 
possible to know what they are in advance?

I'll try exploring naming methods to see if doing this dynamically is 
feasible for such a project. It's sort of complicated.



----- Original Message ----- 
From: "Joseph Scheuhammer" <clown@alum.mit.edu>
To: "Bryan Garaventa" <bryan.garaventa@ssbbartgroup.com>; "James Craig" 
<jcraig@apple.com>
Cc: "public-pfwg" <public-pfwg@w3.org>
Sent: Friday, March 14, 2014 1:19 PM
Subject: Re: Regarding ARIA drag and drop?


> Hi Bryan,
>
> Your example has resurrected misgivings I've had about keyboard-based 
> drag-and-drop.  What follows might seem as an attack on your work.  It 
> isn't; I'm using it as a springboard.
>
> Specifically with respect to your example:  if the goal is to move books 

> from the shelf to the shopping cart, then I would add a button or 
context 
> menu to each book icon that allowed the user to move it to the cart with 

> one gesture.  That button/menuitem would be accessible to mouse, touch, 
or 
> keyboard depending on the device.
>
> The sequence of TAB to focus, ENTER to grab, TAB to drop target, ENTER 
to 
> release, etc. is awkward.  At least, I find it so.  As a user, once I 
have 
> focus on a book, and I know I want to purchase it, why can't I simply 
> indicate that with one keystroke (or mouse click, or touch, or voice 
> command)?
>
> With respect to my misgivings:  drag-and-drop is essentially a 
> GUI/pointing-device sequence of gestures.  Trying to mimic that process 
> using a series of keystrokes is misguided if it's the first or only 
> attempt at a keyboard alternative.  The UI development should begin by 
> focusing on what the user is trying to accomplish and use that as a 
guide. 
> In the context of your example, it's a matter of moving books between 
the 
> book shelf and the shopping cart.  That should be the starting point: 
> what simple, intuitive gesture(s) can accomplish that goal?  I don't 
think 
> the whole ARIA drag-and-drop keyboard machinery is needed here.  And, 
for 
> other contexts, while it might turn out that it is appropriate, that 
> should be the outcome of the design, not the presupposition.
>
> End of rant.
>
> Otherwise, your example is an interesting exploration of the issue. It 
> feels like a lot of work and research -- thanks for posting it.
>
> -- 
> ;;;;joseph.
>
>
> 'A: After all, it isn't rocket science.'
> 'K: Right. It's merely computer science.'
>              - J. D. Klaun -
>
> 
Received on Monday, 17 March 2014 12:44:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:01 UTC