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

Re: Regarding ARIA drag and drop?

From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Date: Fri, 14 Mar 2014 13:40:31 -0700
Message-ID: <1F5D1B0C17224E668E6DB69E47C93BEF@WAMPAS>
To: "Joseph Scheuhammer" <clown@alum.mit.edu>, "James Craig" <jcraig@apple.com>
Cc: "public-pfwg" <public-pfwg@w3.org>
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 Friday, 14 March 2014 20:40:48 UTC

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