- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Fri, 22 Jun 2018 10:44:35 -0500
- To: Detlev Fischer <detlev.fischer@testkreis.de>
- Cc: WCAG group <w3c-wai-gl@w3.org>
+1 Kindest Regards, Laura On 6/22/18, Detlev Fischer <detlev.fischer@testkreis.de> wrote: > Hi all, > > I have attempted to draft an answer > > https://github.com/w3c/wcag21/issues/937#issuecomment-399449006 > > to the issue I have raised, "Second thoughts on pointer gestures and > drag-and-drop". > > It essentially exempts drag-and-drop interaction from the scope of > pointer gestures. This is what I have written - compare pull request > https://github.com/w3c/wcag/pull/379 > > "The path-based operation used in drag-and-drop interfaces is not > covered by this success criterion. While drag and drop interaction > involves a free-form path to move elements to (or within) some drop > target, it does not use pre-defined gestures in the same way as the > swiping or dragging of content or controls, or the drawing of specific > shape patterns. While we encourage authors to create alternatives for > drag-and-drop interfaces that can be operated with a single pointer > without path-based gestures, the complexity of providing such > alternatives is likely to significantly increase interface complexity, > and is therefore not required by this success criterion." > > A paragraph above, I have also qualified "a complex path" by adding > "matching a pre-defined pattern (such as an L- or Z-shape)" to separate > it more clearly from freeform paths drawn by users in drag-and-drop > interactions. > > I really don't like this exception, but I think requiring all > drag-n-drop stuff not only to be keyboard-operable (as the example > referenced in issue #937) but ALSO have alternative controls for each > draggable object to move it stepwise in all 4 directions, or have some > interface for specifying destinations of focused elements, is both > complex and burdensome, may be hard to get to work well across UAs, adds > a significant amount of cruft / interface complexity, and is for all > these reasons very unlikely to be accepted by developers. > > So in view of the epic discussion on broad vs. narrow interpretations of > 1.4.11 (I lean towards the narrow view here, too), this is another > example of narrowing the scope of a new SC to make it more palatable to > those who make efforts to implement it (and also in recognition of the > absence of good techniques, author-side or UA-side, to potentially meet > this SC for drag-and-drop). > > I'd be glad if this could go into a survey to put to bed this thorny > issue (at least for 2.1). All comments welcome, of course! > > Detlev > > > > > > --- > Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. > https://www.avast.com/antivirus > -- Laura L. Carlson
Received on Friday, 22 June 2018 15:45:03 UTC