[whatwg] Accessibility for Drag and Drop

[Aron Spohr]

Hi everyone. I’m new to this list and I’ve got some ideas to make the Drag and Drop feature more accessible. Accessibility for drag and drop can mean different things: Obviously if the user can’t or doesn’t want to use a mouse pointer to perform a drag and drop operation and also making drag and drop more accessible for automated robots and browser plugins. I’ve been working with prototype implementations of Drag and Drop in different browsers for a few years and my ideas are based on the gaps we found in the current specification. I hope you find them useful. 

1. Every Element with the draggable attribute set to true should be focusable by default. I know that tabindex="n" would make almost any element focusable but I think making "draggable" elements focusable is something that shouldn't be left to best practises for webmasters and should be defaulted to by spec. An element that can have a focus usually indicates to the user that it supports some kind of interaction. That is definately the case for elements with the draggable attribute set to true. If they can be focused a user could use the Tab-Key to focus a "draggable" element and then press the context-menu key in order to get a copy function offered by the user agent. Maybe elements with draggable attribute set to true can be added to the list in section 7.5.1 ("Sequential focus navigation") so that they get focused by default. 

I think this should only apply to elements which have the draggable attribute set to true explicitly (and not to auto). That ensures that the pre-existing default behaviour of user agents doesn't change when working with ‘a’ and ‘img’ elements. i.e. ‘a’ elements are already focusable and allow this type of behaviour already, img wouldn’t unless the draggable attribute has been set to true explicitly. 

2. On the opposite side it’s actually pretty undefined how the user can “find” an area where something can be dropped. It’s obviously very much up to the webmaster if the content on the page indicates that something can be dropped somewhere. And that’s probably ok to some degree. However for accessibility it’s suboptimal. Similar to the draggable attribute, which indicates that something can be dragged away I believe it would be very useful to have the opposite, which does indicate that an element can accept drops. Not sure what the best name for such an attribute would be. I’m going with “dropallowed” for this email. If such a “dropallowed” attribute is set to true on any element this could result in this behaviour for the user agent: Make the element focusable by default (and maybe only then make it possible to trigger the ‘drop’ event for strictness). That way again, the element can be reached via the keyboard and a context
 menu can be opened solely with the keyboard in order to perform a “paste” operation. Special user agents (like screenreaders) could also easily indicate that something can be dropped onto (or pasted into) the element if the attribute was set. Search spiders or maybe even browser plugins may find it very useful to easily find all areas on a page which can accept a “drop”-like operation. With such an attribute this would be relatively simple and wouldn’t even need scripting capabilities. If such an attribute existed some elements like ‘textarea’ or ‘input’ would probably have it set to true (or auto) by default.

Aron Spohr