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

That's my understanding...

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Sat, Jun 23, 2018 at 9:39 AM, Jonathan Avila <jon.avila@levelaccess.com>
wrote:

> 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://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>
>
>
>