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 15:03:22 -0700
Message-ID: <D4BD143D7DAF4947BD4E5726338174C8@WAMPAS>
To: "Matthew King" <mattking@us.ibm.com>
Cc: "Joseph Scheuhammer" <clown@alum.mit.edu>, "James Craig" <jcraig@apple.com>, "public-pfwg" <public-pfwg@w3.org>
It's a good idea, however the drop target may be an empty container somewhere on the page, and VoiceOver doesn't announce drop target information, so there is no way to determine which region is droppable.

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

  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" 
  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 22:03:25 UTC

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