Re: 7.6 Drag and drop (accessibility)

Having given some further thought to the Drag and Drop API I realize that there is, in the API spec, no method of associating a textual label with @draggable and @dropzone elements.  This can obviously be done with aria-label, aria-labelledby, or <label for="idref">. Should this be part of the API spec?  It is essential for accessibility that drag and drop targets have a textual label associated. In my opinion, in order to conform with WCAG 2.0, this is a must, not a may.

There is also no WAI-ARIA attribute mapping ( see http://www.w3.org/TR/wai-aria/states_and_properties#attrs_dragdrop ). Should this be included as part of the Drag and Drop API, or in a separate document?
Thanks again,
Everett Zufelt
Accessibility Consultant & Web Developer

Web
http://zufelt.ca
Phone (toll free U.S. & Canada)
1-877-ZUFELT-8 (1-877-983-3588)

Follow me on Twitter
http://twitter.com/ezufelt
View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt



On 2011-11-23, at 9:46 AM, E.J. Zufelt wrote:

> Good morning,
> 
> This morning I read through "7.6 Drag and drop" (http://dev.w3.org/html5/spec/dnd.html). I was reading in light of the three open "NEEDSINFO" drag and drop accessibility bugs (http://www.w3.org/Bugs/Public/show_bug.cgi?id=7721, http://www.w3.org/Bugs/Public/show_bug.cgi?id=10713, http://www.w3.org/Bugs/Public/show_bug.cgi?id=13591). Since all three of these bugs are requesting the same action, clarify the spec to make it easier to implement drag and drop when not using a pointing device (mouse), I think that we can close 2 of the bugs.
> 
> @Hixie is correct in one of his comments to the bugs. We cannot specify that a UA support keyboard based drag and drop, as some UAs are designed for systems without a keyboard. The spec states that the API is an event mechanism, and therefore does not define what a drag and drop operation actually is. This seems appropriate, given the nature of the drag and drop style of operation needing to be implemented differently, depending on the available user input mechanisms.
> 
> The following represents my comments for how the spec can be improved. I welcome input and improvement prior to posting against one of the bugs.
> 
> 7.6
> 
> 1. "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."
> 
> Either we should remove this section completely, or 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.
> 
> 7.6.5
> 
> 2. "When the user attempts to begin a drag operation, the user agent must run the following steps."
> 
> Note that this says nothing about how the user attempts to start a drag operation. In my opinion the language here is appropriately input device agnostic.
> 
> 3. "If the drag operation was invoked on a selection, then it is the selection that is being dragged."
> 
> For assistive technology that presents contents in a virtual buffer it may be difficult for the assistive technology / user agent pair to identify what text has been selected. Possibly the UAAG needs to be updated (if it doesn't already) to contain a section on making a selection using assistive technologies that present information in a virtual buffer.
> 
> 3. "img elements and a elements with an href attribute have their draggable attribute set to true by default."
> 
> Should this also be true for elements with any particular combinations of WAI-ARIA role, states and properties?
> 
> 4. "The drag-and-drop feedback must be generated from the first of the following sources that is available:
> The drag data store bitmap, if any. In this case, the drag data store hot spot coordinate should be used as hints for where to put the cursor relative to the resulting image. The values are expressed as distances in CSS pixels from the left side and from the top side of the image respectively. [CSS]
> The elements in the drag data store elements list, if any.
> The drag data store default feedback."
> 
> The API currently does not appear to provide a mechanism by which an alternative textual representation of the drag and drop feedback may be specified.
> 
> 5. "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)."
> 6. "Update the drag feedback (e.g. the mouse cursor) to match the current drag operation, as follows:"
> 7. "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:"
> 8. "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. Alternatively all input device specific language and examples should be removed.
> 
> 
> Thanks,
> Everett Zufelt
> Accessibility Consultant & Web Developer
> 
> Web
> http://zufelt.ca
> Phone (toll free U.S. & Canada)
> 1-877-ZUFELT-8 (1-877-983-3588)
> 
> Follow me on Twitter
> http://twitter.com/ezufelt
> View my LinkedIn Profile
> http://www.linkedin.com/in/ezufelt
> 
> 
>