add definition for “path-based gesture” for 2.2

[jake-abma]

w3c/wcag21#478 (comment)

“path-based gesture” with a definition of: “User input that depends on the path of the user's movement and not just the endpoints.”

[detlevhfischer]

I believe this definition as it stands is not helpful in understanding operational path-based gestures. The tricky thing here it to nail down what "depends on the path of the user's movement" exactly means. See, for what I consider a misunderstanding, the end on yesterday's telco. There was a quote from a definition of "path-based gesture" (which I had provided, possibly modified a bit by Alastair) that I intended to depart from the "start- and end point" language (which I find hard to understand when used in relation to operational pointer gestures). Here is @awkawk quoting it:

AWK: A path-based gesture involves an interaction where the user engages a pointer with the display (down event), carries out a directional movement in a pre-determined direction before disengaging the pointer (up event). The direction, speed, and also the delta between start and end point may each be evaluated to determine
Andrew: From what I've heard, I feel like we can resolve this that it doesn't include gestures with....
... We can decide on which pull request to use, but we have come to a conclusion.

RESOLUTION: The WG intended that path-based gestures in 2.5.1 does not include gestures that only depend on the start and end points.

Maybe it doesn't come out clearly in my use of pre-determined direction, but what I wanted to capture was that it is the intent, the determination of the user to make a directional gesture (following the affordances of an element, e.g. the constraint of a slider that can only move horizontally) that is central here - not whether the author implements the gesture in a way that it only works within certain constraints that are neither usually obvious nor necessarily important to the user.
So strictly speaking I don't mind this resolution above as in my view, there is more in play in performing a drag gesture than start and end point.

So I still think it is important for a fitting definition of path-based gesture to capture directional user intent (as prefigured in the affordances / constraints in sight and experienced in interface feedback when performing the pointer gesture) - whatever the wording we come up with. Based on this definition, directional drag would then be in scope regardless of wayward, parabolic or other movements due to users inability to perform a decisive straight path. We might need better language than my "pre-determined" to make the meaning of the definition clearer.

[alastc]

We have essentially been working on this in PR #714 (preview), based on the discussion on Tuesday the understanding description has:

A path-based gesture involves an interaction where the user engages a pointer (starting point), carries out a movement that goes through at least one mid-point before disengaging the pointer (end point). The mid-point defines the gesture as requiring a specific path, even if the complete path is not defined.

With a lovely diagram that I hand-crafted myself on an iPad ;-)

If that is sufficient and gets approved, we can close this.

If you'd rather we add a definition to the glossary we'll label it as WCAG 2.2 and incorporate that definition into the glossary as part of that work.

[mraccess77]

@alastc in your update you say a swipe gesture is a path based gesture (which I agree with) -- but I'm trying to understand how it matches the intermediate point criteria. In some samples I have seen on the Internet people are simply looking for a change in direction from the touch start location to the last touch move location (which is calculated on touch end). Maybe the platform creators do this differently than hacky devs -- but it feels like swipes are really just about the offsets of start and ending points with some tolerance for deviance of 30-60 pixels. So swipes aren't really about the start and end points but the delta within tolerances.

[alastc]

I've answered that in #714, I'd rather keep this thread to discussion of whether we have an official glossary definition.

[alastc]

Hi @jake-abma, do you still feel we need an official definition, or is the understanding doc now covering that?

If you do, could you have a look at the understanding doc and consider what a concise definition might be? I struggled to say it in less words that we have there!

[jake-abma]

@alastc if we never, ever, use it in another place it would be fine, otherwise will you refer to 2.5.1 Understanding in future for explanation? In that case this one probably deserve a spot in the glossary.

[jake-abma]

@alastc already spotted one: https://www.w3.org/TR/WCAG21/#dfn-single-pointer :-)

[jake-abma]

So to give some perspective, if you have interest in 2.5.2 and stumble upon "single pointer" you probably end up not understanding what path bases gesture means.

[patrickhlauke]

i'd agree it needs to be normative in the main definition section, rather than informative in the understanding doc

[alastc]

Ok, so cutting down the understanding doc paragraph a bit, how about:

Path-based gesture:
a pointer-drag interaction where the pointer has to go through at least one intermediate point to trigger a function. It is not just the endpoints that determine the outcome of the gesture, the intermediate point(s) defines the gesture as requiring a specific path, even if the complete path is not defined.

[jake-abma]

Can we add @alastc suggestion to a survey?

[alastc]

This was discussed at the meeting this week. There was concern about the process needed to add the definition. That's do-able, but would require an errata for 2.1.

Also, there was a suggestion the same defintion could apply to "depends on the path of the user's movement" in 2.1.1.

We'll revisit later.