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
