504533 - Keyboard support is missing from Drag and Drop HTML 5

Status: NEW

(Core :: DOM: Core & HTML, enhancement, P3)

Description

[Remy Sharp]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1) Gecko/20090624 Firefox/3.5

The WHATWG spec says that keyboard support for Drag and Drop should be implmented through the copy and paste keyboard operation:

http://www.whatwg.org/specs/web-apps/current-work/#copy-and-paste

I would expect that once on a draggable element (which I can tab to using
tabIndex="0") when I copy, it should trigger the dragstart event, and then
tabbing on to an element with the drop event listener, I should be able to
paste to send across the dataTransfer object.

Reproducible: Always

Steps to Reproduce:
1. Tab to the images (which have tabIndex="0" set so they're focusable)
2. Copy from the keyboard
3. Nothing happens
Actual Results:  
Nothing - hense the lacking support.

Expected Results:  
When I copy the element, it should trigger the whole event model. 

In this specific case, it should trigger the dragstart event - which will log in the #debug element that dragging has started (you can test this by dragging via the mouse).

I would then tab to the drop target, and use the paste keyboard command, and this will fire the drop event passing through the dataTransfer object in the event.

Without keyboard support, the drag and drop is not accessible to users who rely on the keyboard for navigation - even though the HTML 5 spec explains how it should be supported.

Comment 1

[Marco Zehe (:MarcoZ)]

Confirming. This is a no-go for a new feature folks!

Comment 2

[Johnny Stenback (:jst)]

Olli, do you think you can look into this one for 1.9.2?

Comment 3

[Justin Lebar (not reading bugmail)]

I'm taking a look at implementing this.

The spec says "When the user invokes a copy operation, the user agent must act as if the user had invoked a drag on the *current selection*."  In order to get the test page to work, we'd have to invoke a drag on the currently focused element upon receiving ctrl+c, because tabbing to an image doesn't select it.

I'm OK saying that if there's no selection and the user presses ctrl+c, we start a drag on the currently-focused element.  But I don't think we should actually copy anything to the clipboard if there's no selection.

Starting a drag when nothing is actually copied might be a little weird.  At least, we'd probably want to have the spec revised.

Do you all have any thoughts about this?

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

Joseph if you have time, could you comment? I think I agree with Justin's thinking here, but we'll need to have the spec clarified.

Comment 5

[Justin Lebar (not reading bugmail)]

Based upon my re-re-reading of the spec, I'm now less convinced that we could get the OP's testcase to work by implementing the spec without major changes.

My current understanding of section 7.9.6.1 is that on copy, we fire a dragstart followed by a dragend.  It appears that copy isn't analogous to clicking and holding to begin a drag on an element, but rather it's like dragging the element into an off-browser program called the clipboard.

Section 7.9.6.3 says that on paste, we fire a dragend event whose dataTransfer contains the data *in the clipboard*.

In order to get the OP's testcase to work with copy/paste, we'd have to change the spec to say that a copy initiates a drag on the selected/focused element, and a paste ends that drag.  But I think this adds a lot of complexity to the drag'n'drop model.  For instance, suppose you:
 * Copy element A
 * Drag and drop element B
 * Focus element C
 * Paste.
Presumably, the paste should be related to A's drag session, but that means that while we were dragging B, we had two different drag sessions.

If we don't change the spec like this, then the testcase is going to have to have special logic to understand drag'n'drop from the clipboard as opposed to from the mouse.  At that point, it might as well detect cut/copy/paste events on the document.

I actually think that the current model in HTML5 (as I understand it) is pretty reasonable.  But I'm not sure that it lets you use drag'n'drop in an accessible manner on pages not designed with accessibility in mind, and I'm not convinced it enables websites to be more accessible than they could be without it (since they can always observe cut/copy/paste), so I'm not sure it should block 1.9.2.

Maybe we can add keyboard shortcuts to FF for "begin drag on focused node" and "drop onto focused node".  It seems to me that that might solve the problem without adding much complexity.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

I think we are going to have to pioneer keyboard support for native DnD. Justin, can you work with the specification folks to make sure we have something that is implementable?

Comment 7

[Neil Deakin]

(In reply to comment #5)
> Based upon my re-re-reading of the spec, I'm now less convinced that we could
> get the OP's testcase to work by implementing the spec without major changes.
> 
> My current understanding of section 7.9.6.1

Please do not waste time implementing that. It's a bad idea, poorly specified and not at all compatible with any other browser.

Drag and drop does not need to be keyboard accessible directly, only the actions that would result from them. Pages can and should provide clipboard or other actions instead. The better way (although not perfect) way to do clipboard is to finish up bug 407983. A spec based on that would be much better since IE, Safari and Chrome already implement it.

Note also that, apart from 'starting a drag', Linux already allows keyboard usage of drag/drop.

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #6)
> I think we are going to have to pioneer keyboard support for native DnD.

Just to clarify, by "native" I meant html5; this use of "native" is common when talking about ARIA semantics vs native markup semantics. Sorry for confusion.

Comment 9

[Joseph Scheuhammer (:clown)]

Replying to David (comment #4).

I'm not overly familiar with HTML5 dnd.  I can summarize ARIA dnd (http://www.w3.org/WAI/PF/aria-practices/#dragdrop).

For keyboard a11y, ARIA dnd divides the operation into four phases:
1. User selects objects to drag.
2. System identifies drop targets and drop function(s).
3. User navigates among/to desired drop target.
4. User drops

The DHTML style guide recommends various keystrokes for the phases.  Roughly:

1. Space to mark an object as selected.  Control and shift modifiers are used to create contiguous and non-contiguous selections.
2. Control+M to signal that selection is done (think "start-of-move").  System determines
drop targets.
3. Navigate via tab and/or arrow keys to desired drop target.
4. Control+M to drop on target (think "end-of-move") invoking default drop operation, or Shift+F10 to invoke a context menu that displays valid drop operations.

Note that the above is a summary.  There are exceptions.  In particular:

Re phase 1.  It's likely the context provides more natural keystrokes for the selection phase. For example, if the items are in a list box, then selection should be done via cursor keys, with shift, and control modifiers.  In other words, use the "natural" selection keystrokes for the context.  If there are none defined, use the space/shift/control as stated in the style guide.

Re phase 2.  If the underlying operation is a copy/paste, use C and P instead of M.  If it's cut/paste, use X and P.

Re phase 3.  There may be no need to navigate to a drop target.  Consider deleting files in the Mac Finder.  First, select the files to delete.  Then, use cmd+delete to move them to the trash.  Don't require users to navigate to the trash icon (the drop target) using the keyboard in order to put the selected files therein.

For the full recommendation, see http://dev.aol.com/dhtml_style_guide#draganddrop

Comment 10

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #7)
> (In reply to comment #5)
 > Note also that, apart from 'starting a drag', Linux already allows keyboard
> usage of drag/drop.

Neil, do you think we should implement at least this drag start (via kb)? I'm not clear on our drag implementation and when/if the native desktop takes over?

Comment 11

[Neil Deakin]

On Linux you might be able to. I don't think it's possible on other platforms. The native api is just a method that is called. On Mac, for example, it fails if the mouse isn't pressed. So Linux only may not have much value.

Comment 12

[David Bolter [:davidb] (NeedInfo me for attention)]

Neil, do you think the way to go here is to make bug 407983 block this, and push the spec to a clipboard model?

Comment 13

[Johnny Stenback (:jst)]

Seems like there's a lot of uncertainty here still, and that it's unlikely we'll sort this out in the really near future, so not going to hold 1.9.2 for this bug.

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

I was just about to implement this.
But sure, the draft spec isn't necessarily stable here.

Comment 15

[Johnny Stenback (:jst)]

Smaug says the spec about this is still not stable, and this certainly doesn't need to block alpha1 IMO. Updating blocking status...

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

HTML5 draft doesn't have dnd for keyboard anymore.

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

http://html5.org/tools/web-apps-tracker?from=4643&to=4644

Comment 18

[Fabian]

The implementation suggestion of using a copy/paste model for keyboard users was abandoned, yet the spec is deliberately device-agnostic. Hixie repeatedly stated that making D&D work by keyboard is up to user agents and fits within the spec.

Could this bug be reopened so we can discuss how keyboard accessibility and exposure to assistive technologies can be handled?

Comment 19

[Fabian]

Possible way of supporting Drag & Drop by keyboard:

Give all elements with a draggable attribute, or with either a dropzone attribute or a dragenter, dragover or drop event listener attached, a tabindex focus flag by default so they can be reached by sequential keyboard navigation.

When focusing an element with a draggable attribute:

- Give an indication that the element is draggable, e.g. by showing a move icon near the element.
- Provide both a keyboard shortcut (e.g. Space) and a contextual menu item "Drag this element" in order to start a drag.
- Upon further navigation after starting a drag, apply all drag-related events to traversed elements in a similar way as if performing the drag by mouse.
- Provide the appropriate visual indicators that a drag is in progress, e.g. by showing a highlighted move icon near any focused element. If present, use the same icons or images defined by the page author to indicate the drag-in-progress. When appropriate, show the drop-not-allowed indicator when focusing elements where dropping is not allowed.
- When a drag is in progress, at all times allow the keyboard shortcut Escape in order to cancel the drag, as well as a contextual menu item "Cancel drag".
- When focusing an element with either a dropzone attribute or a drop event listener attached, visually indicate the drop possibility by showing an appropriate icon reflecting the dropeffect.
- Support both a keyboard shortcut (e.g. space) and a contextual menu item "Drop" to finalize the drag.


When focusing an element with either a dropzone attribute or a drop event listener attached while no drag operation is currently in progress:

- Provide an indication that the element supports dropping, e.g. by showing an appropriate icon reflecting the dropeffect.
- Provide both a set of keyboard shortcuts (e.g. 1) Space and 2) the appropriate shortcut for pasting, usually ctrl+v) and contextual menu items (e.g. 1) "Select file to attach" and 2) "Attach clipboard content"). The file upload may be restricted to cases where files are actually an accepted drop content.
- Selecting a file attach operation should provide the Open File dialog, where one or more files can be selected. The files shown in the dialog may be filtered according to the dropzone attribute's keywords, if applicable.
- Upon selecting the file or confirming the clipboard attach, perform all relevant drag-related events to finalize the drag.

Comment 20

[Fabian]

Can someone please reopen this bug so we can move this issue further towards a solution? Currently it seems to fall off all radars.

Comment 21

[Marco Zehe (:MarcoZ)]

Done.

Comment 22

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 23

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381

Comment 24

[Andrei Purice]

Hey Remy,
Can you still reproduce this issue or should we close it?

Comment 25

[Remy Sharp]

Yes, after 13 years, yes, I can still replicate this particular bug.

Did you try to replicate also?

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last months and this bug has severity 'major'.
:hsinyi, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 27

[Suhaib Mujahid [:suhaib]]

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.