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

+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