RE: Proposed answer for issue #937 (pointer gestures and drag-n-drop)

Hi Detlev, thank you for putting this together.  Aside from drag and drop can I confirm swipe left or swipe right gesture actions implemented by the content would be covered as something that needs a single pointer activation.  For example, swipe in from the left side of the screen to open a menu would require a menu button.    Correct?

Jonathan

From: Detlev Fischer <detlev.fischer@testkreis.de>
Sent: Friday, June 22, 2018 10:09 AM
To: WCAG group <w3c-wai-gl@w3.org>
Subject: Proposed answer for issue #937 (pointer gestures and drag-n-drop)


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





[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

Virenfrei. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>