Comment 1 by jteh on 2014-01-23 10:59
The question is really what isn't clear to users. Drag and drop is a mouse concept. If a sighted user knows the move the mouse to the start position, hold the mouse button down and drag the mouse to the destination, it logically follows that any user will have to move the mouse cursor, hold down (lock) the mouse button, move the mouse cursor to the destination and release (unlock) the mouse button. You can argue I'm a developer so this is simple for me, but this requires no technical knowledge at all; it's simply a matter of understanding what "drag and drop" means. How does a sighted user learn?

Comment 2 by nishimotz on 2014-01-23 12:04
I do not know about Thunderbird very well, however, I know some sort of Drag and Drop UIA events occurs via keyboard operation and they are announced by Windows 8.1 Narrator.

For example, the position of Windows 8.1 start screen tiles can be relocated via Alt+Shift+Arrow keys and such events are captured by a patch as follows.

diff --git a/source/NVDAObjects/UIA/__init__.py b/source/NVDAObjects/UIA/__init__.py
index ee71843..ededf34 100644
--- a/source/NVDAObjects/UIA/__init__.py
+++ b/source/NVDAObjects/UIA/__init__.py
@@ -740,6 +740,14 @@ class ListItem(UIA):
                                parent.event_valueChange()
                super(ListItem, self).event_stateChange()

+       def event_UIA_dragStarted(self):
+               import tones
+               tones.beep(500, 20)
+
+       def event_UIA_dragCompleted(self):
+               import tones
+               tones.beep(1000, 20)
+
 class Dialog(Dialog):
        role=controlTypes.ROLE_DIALOG

diff --git a/source/_UIAHandler.py b/source/_UIAHandler.py
index 227e6b0..f045c00 100644
--- a/source/_UIAHandler.py
+++ b/source/_UIAHandler.py
@@ -115,6 +115,8 @@ UIAEventIdsToNVDAEventNames={
        UIA_ToolTipOpenedEventId:"alert",
        #UIA_AsyncContentLoadedEventId:"documentLoadComplete",
        #UIA_ToolTipClosedEventId:"hide",
+       UIA_Drag_DragStartEventId:"UIA_dragStarted",
+       UIA_Drag_DragCompleteEventId:"UIA_dragCompleted",
 }

 class UIAHandler(COMObject):

Comment 3 by briang1 (in reply to comment 1) on 2014-01-23 15:50
Replying to jteh:

The question is really what isn't clear to users. Drag and drop is a mouse concept. If a sighted user knows the move the mouse to the start position, hold the mouse button down and drag the mouse to the destination, it logically follows that any user will have to move the mouse cursor, hold down (lock) the mouse button, move the mouse cursor to the destination and release (unlock) the mouse button. You can argue I'm a developer so this is simple for me, but this requires no technical knowledge at all; it's simply a matter of understanding what "drag and drop" means. How does a sighted user learn?

I think what happens is this. User does not quite understand the differerences between the various cursors for focus, and comes across a piece of software which states, simply drag and drop the files into this window, or some such, and so they do a search of the manual for drag and drop. there is no cross ref to how to do it from such a search. The user needs to know whet they don't know, so to speak to find out how its done. If Drag and drop, see section (insert it here) was there I think it would stop a lot of problems.
That was my point really.

Comment 4 by driemer.riemer@... on 2014-01-23 17:50
I too aggree that drag and drop should be included, because many people, who are blind, don't understand how it works. This is due to them not really ever dragging and dropping themselves. It indeed is one of the most common questions asked on the nvda list.

I tend to agree. Personally speaking too, I have never performed a drag and drop via the keyboard, but I reckon it could prove useful in several scenarios. Holding the left mouse button and then moving a mouse and then releasing the left mouse button sounds far simpler and would be better learnt by a sighted user since the mouse is the primary navigation device used. However, in the case of visually impaired users, it is a procedure that needs to be understood and manually learnt rather than being naturally grasped. These remarks are based on my perception of drag and drop when I was sighted versus now that I am blind. CC @Qchristensen, @josephsl and other documentation specialists

For a sighted user, drag and drop using a physical mouse isn't usually too tricky to get the hang of (YMMV of course). Emulating it with the keyboard tends to be a relatively complex task which requires an understanding of the screen layout and an awareness of how the mouse moves around the screen. I'm sure I have also encountered places which don't respond in the same way to keyboard emulated drag and drop.

For many common tasks, there are better ways of accomplishing the task with the keyboard than trying to emulate drag and drop (eg copying a file from one folder to another in File Manager, or using the "browse" button that usually exists as an option instead of drag and drop to upload a file to a web page, etc).

I think it would be good to have some examples of where emulating drag and drop is the most efficient way of a user accomplishing a particular task.

May I be the first to volunteer NOT to write the instructions for that :)

Seriously though, there are several issues with changing the column order of the Thunderbird message list, and it's a good example of a task that would be really hard to do with the keyboard only emulating the mouse.

Firstly, when you do use the mouse and drag columns around, the only feedback of where you are about to drop it, is a thicker line in-between two columns indicating where it will go. If you do drag over a column header or text in a message, that text is announced, As I drag the correspondents column over the subject column for instance, if I am over the right half of the subject column, the thicker line indicates that the correspondents column would be placed directly to the right of the subject. As I move over the left half of the column, the thick line jumps across and it would be placed to the left. If I drift down and the mouse moves over the top message, the subject of that message is announced. It is difficult to gauge the right place to drop the column.

Because the column headers aren't readily accessible with the keyboard, it is difficult to move the mouse to them accurately with the keyboard. Using the Golden cursor add-on it is possible:

1. From the message list table, press HOME to move to the first item.
2. Press NVDA+numpad divide to move the mouse to the current navigator object.
3. Press NVDA+WINDOWS+UP ARROW to move the mouse up until NVDA reads "Read sort by read".
4. Press NVDA+WINDOWS+RIGHT ARROW to move the mouse right until NVDA announces "Correspondents, sort by Correspondents".
5. Press SHIFT+numpad divide to lock the left mouse button.
6. Press NVDA+WINDOWS+LEFT ARROW until NVDA announces "Attachment, sort by attachment".
7. Press SHIFT+numpad divide to unlock the left mouse button and "drop" the correspondents column to the left of the subject column.

That's certainly possible, (and despite my initial reluctance, I appear to have written the instructions for it) however, it relies on a particular add-on being installed and even then, steps such as step 6 (moving the mouse pointer), often involve quite a few presses of that keystroke to get it where you want it.

Ideally, you would also want some kind of verification to indicate the current order of the columns so you could decide if you wanted to move more columns. If we were asking Mozilla for help with Thunderbird, it would be better to ask for a window we can navigate normally, with each column listed where you could both set whether they are visible or not, and select the order. If documenting the drag and drop method I outlined above anywhere, it would have to be in the Golden Cursor documentation and it's not a method I would broadly recommend if there was a way of doing it with the keyboard directly.

See also an issue discussing improving the UX around drag and drop "Drag Mouse Feature #1755"

@feerrenrut Do you think we should hold off on this ticket till #1755 is implemented? If so, perhaps we could add the Blocked label to this ticket. For context, the referenced ticket suggests changing the way NVDA facilitates drag and drop using the keyboard, and if some functionality is likely to change in the near future, then documentation of that functionality would also need to keep pace.