Re: Regarding ARIA drag and drop?

This thread strikes me very much as an academic exercise for the design
reason Matt cites, which has also previously been cited by Joseph.

I suspect, even for a sighted user, certainly for switch users, offering
"Add to Cart," and "Add to Wishlist" in a menu on the selectable object
makes sense. I suppose one might provide a visually clever drag in
addition to the context menu, but I can't understand forcing the user to
do all that extra work, when they may not be physically equipped so to
do easily, and for no real reason. To my mind this is the definition of
an academic exercise. How many angels can dance on the head of a pin,
after all?

Janina


Matthew King writes:
> 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 -
> >
> > 
> 
> 
> 

-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina@asterisk.rednote.net
		Email:	janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/

Received on Monday, 17 March 2014 13:01:40 UTC