W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] Accessibility for Drag and Drop

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 28 Jul 2009 00:01:58 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0907272354370.23663@hixie.dreamhostps.com>
On Sun, 12 Jul 2009, Aron Spohr wrote:
>
> 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.

Whether draggable elements can be focused or not is up to the user agent. 
It's much like links -- in some browsers, whether they are focusable or 
not depends on the operating system accessibility preferences.


> 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.

Again, that would depend on the user agent's behaviour.


> 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.

The user agent can actually find where drops can occur by just acting as 
if the user had tried to drop everywhere. I'm not really sure how we could 
make an attribute work for this, since the model allows any element to be 
a drop target already.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 27 July 2009 17:01:58 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:14 UTC