10713 2010-09-24 08:48:12 +0000 Drag and Drop: Add guidance for keyboard-only interaction 2013-01-16 14:19:49 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified PC Windows NT CLOSED LATER http://dev.w3.org/html5/spec/Overview.html#dnd a11y, a11ytf, a11y_drag-drop P2 normal --- 7721 8800 1 gez.lemon dave.null cooper everett ian joshue.oconnor laura.lee.carlson mike public-html-a11y public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 39256 0 gez.lemon 2010-09-24 08:48:12 +0000 It's good that the specification makes it clear at the start and throughout that the drag and drop mechanism should be device independent, but it would be helpful if there was guidance for keyboard-only implementation. See the proposal sent to the HTML Accessibility Working Group for a drag and drop keyboard accessible workflow: http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0444.html 39661 1 ian 2010-09-28 06:42:32 +0000 I'm not sure which part of that e-mail I'm supposed to be looking at. Is this requesting just a paragraph similar to the one starting "On a visual medium with a pointing device..."? But for some other medium and other input device? Which ones exactly? Audio medium with a keyboard input device? What should it say? 40081 2 ian 2010-09-30 08:10:41 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: see comment 1. 40122 3 everett 2010-09-30 09:35:50 +0000 (In reply to comment #1) > I'm not sure which part of that e-mail I'm supposed to be looking at. > > Is this requesting just a paragraph similar to the one starting "On a visual > medium with a pointing device..."? But for some other medium and other input > device? Which ones exactly? Audio medium with a keyboard input device? What > should it say? I can write some text if it will be given serious consideration for inclusion. 40197 4 everett 2010-09-30 16:08:03 +0000 (In reply to comment #3) > (In reply to comment #1) > > I'm not sure which part of that e-mail I'm supposed to be looking at. > > > > Is this requesting just a paragraph similar to the one starting "On a visual > > medium with a pointing device..."? But for some other medium and other input > > device? Which ones exactly? Audio medium with a keyboard input device? What > > should it say? > > I can write some text if it will be given serious consideration for inclusion. Reopenning bug. 40256 5 ian 2010-09-30 18:52:46 +0000 No need to provide actual text, just an idea of what it should say. I'm just not clear on what the bug is requesting. If you could answer the specific questions in comment 1, that would be sufficient, I think. 45061 6 cooper 2011-02-03 16:29:43 +0000 Assign to Gez to provide information or determine the issue is moot and close the bug http://www.w3.org/2011/02/03-html-a11y-minutes.html#item01 61573 7 everett 2011-12-15 00:15:28 +0000 "On a visual medium with a pointing device, a drag operation could be the default action of a mousedown event that is followed by a series of mousemove events, and the drop could be triggered by the mouse being released. When using an input modality other than a pointing device, users would probably have to explicitly indicate their intention to perform a drag-and-drop operation, stating what they wish to drag and where they wish to drop it, respectively." Please provide analogous sections to the "visual medium with a pointing device" for at least "visual medium with a keyboard", "non-visual medium with a keyboard", and "visual medium with a touch input device". Note that this is non-normative, but the clarification drives home the fact that the different modalities of access directly influence the drag and drop operation. Other sections of the API that have non-normative text that could use amendment" "The immediate user selection changes as the user selects different elements (either by pointing at them with a pointing device, or by selecting them in some other way)." "Update the drag feedback (e.g. the mouse cursor) to match the current drag operation, as follows:" "Otherwise, if the user ended the drag-and-drop operation (e.g. by releasing the mouse button in a mouse-driven drag-and-drop interface), or if the drag event was canceled, then this will be the last iteration. Run the following steps, then stop the drag-and-drop operation:" "If the current drag operation is "none" (no drag operation), or, if the user ended the drag-and-drop operation by canceling it (e.g. by hitting the Escape key), or if the current target element is null, then the drag operation failed. Run these substeps:" Further examples should be provided, analogous to the categories I suggested in 1 above. To clarify, all non-normative examples should be provided for at least the four modalities described. 63485 8 ian 2012-02-01 00:05:11 +0000 We're definitely not listing four modalities each time, that's just going to make the text impenetrable. Could you briefly elaborate on roughly what you would like the spec to say for these three cases in the introduction?: - "visual medium with a keyboard" - "non-visual medium with a keyboard" - "visual medium with a touch input device" 63486 9 ian 2012-02-01 00:05:56 +0000 Reassigning to me since otherwise this will drop off my radar. 69940 10 ian 2012-07-13 17:47:45 +0000 This bug was cloned to create bug 17769 as part of operation convergence. 81474 11 cooper 2013-01-16 14:18:53 +0000 HTML A11Y TF has said we don't need to track drag and drop bugs because they were filed before an overhaul of that part of the spec, but will review that part of the spec again.