clarifying whether swipe is a path-based gesture

[gundulaniemann]

I seem to remember it was agreed in the working group that swipe is not a path-based gesture, and this is also what I read from the Understanding document of 2.5.1.
Nevertheless, when reading thoroughly several times and adding the dragging movements understanding document, I seem to come to a different conclusion.

In
https://www.w3.org/WAI/WCAG21/Understanding/pointer-gestures.html
it says:
"A path-based gesture involves an interaction where not just the endpoints matter. If going through an intermediate point (usually near the start of the gesture) also affects its meaning then it is a path-based gesture. The user engages a pointer (starting point), carries out a movement that goes through at least one intermediate-point before disengaging the pointer (end point)."

From this, I understand a swipe (which does neither have a definite intermediate point nor a defined end point) is not a path-based gesture.

Nevertheless further down, below Figure 1, it says:
"Examples of path-based gestures include swiping, sliders and carousels dependent on the direction of interaction, and other gestures which trace a prescribed path such as the drawing a specific shape."
So explicitly 'swipe' is mentioned as path based gesture.

In https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements
in the last paragraph of the intent it says
"Path-based gestures covered in Success Criterion 2.5.1 Pointer Gestures are pointer interactions that involve at least an initial directionality."

If the group agrees that swipe movements are path-based gestures, I suggest to make it clearer in the Understanding document of 2.5.1.
For better understanding, I suggest to take over the wording of an 'initial directionality'.
In addition, I feel, that neither sliders nor carousels are gestures, but they have gestures to control them.

So I suggest to replace the second sentence in the last paragraph of the intent with the following:
"If starting with an initial directionality or going through an intermediate point (usually near the start of the gesture) also affects its meaning then it is a path-based gesture."

I also suggest to replace the first sentence after Figure 1 by the following:
"Examples of path-based gestures include swiping, gestures to control sliders and carousels dependent on the direction of interaction, and other gestures which trace a prescribed path such as the drawing a specific shape."

[detlevhfischer]

I seem to remember it was agreed in the working group that swipe is not a path-based gesture, and this is also what I read from the Understanding document of 2.5.1.

@gundulaniemann I don't know what makes you think that swipe is not path-pased. The 2.5.1 Understanding text says

"Examples of path-based gestures include swiping, sliders and carousels dependent on the direction of interaction, and other gestures which trace a prescribed path such as drawing a specific shape.

Further down you write:

From this, I understand a swipe (which does neither have a definite intermediate point nor a defined end point) is not a path-based gesture.

Swipe has what you might call an implied intermediate point - to count as swipe, the gesture depends on starting off in a particular direction, so for a left swipe, you can see the implied intermediate point somewhere to the left of the starting point. Moving the pointer first up (or down) then left will not trigger the action (it may do nothing or scroll the page instead). And if it does trigger it, we habe a dragging movement instead.

For better understanding, I suggest to take over the wording of an 'initial directionality'.

I would not mind using that phrase to make it clearer, that was my preferred choice, actually - I seem to remember there were some compelling reasons to introduce the notion of (implied, virtual) intermediate point instead. @alastc might be better placed to respond to this, I believe the wording originated with him (or with @mbgower ).

[patrickhlauke]

probably stating the obvious, but: i think part of the problem is that "swipe" as a term is loaded with different connotations. some people see it as a very directional "flick" (which is a path-based gesture), while others also call those draggable sliders or carousel type interactions (where you place a finger down, and then the carousel follows your finger even if you move it slowly/up and down/etc, until you lift the finger) a "swipe" (which are not path-based, since they do allow for the pointer/finger to "stray")

[emleml]

Hi, I have also come across this question on a recent audit.
This is really just a simple horizontal scroll/swipe on a list of tabs at the top of a screen. Turning on my screen reader I can navigate through each tab and it will scroll the component into view. I'm assuming, if this app was built in HTML, it is simply a container with a scroll overflow.
I think the definition of swipe needs to be defined or refined in the success criteria. Whilst, yes, I can move my finger all over the screen for this container and the container's position will just end up following my finger, even if it is all the way at the bottom of the screen, so it is less of a 'flick' motion and more a continuous scroll, I would suggest the taxonomy of the word swipe is constantly used to mean 'swiping through a container to view more items' even if this action is not path-based, and this could cause common confusion. In fear of misinterpreting the diagram, I am still more inclined to suggest single pointer actions, like previous and next buttons, however it feels like that is slightly overengineering the solution when it is simply a horizontally scrolling container - with the common phrasing of 'swiping' confusing things.
When do mobile apps ever have true 'swiping' functionality if the common 'carousel follow your finger' does not count as a path-based gesture? (and in this case, we probably should not be mentioning carousels).

[detlevhfischer]

@emleml The behaviour you describe would probably fall under dragging in WCAG terminology. However, if you start moving your finger vertically and then horizontally and the slide does not follow, the gesture would count as swipe and fall under 2.5.1 - you'd then need things like arrows to move your list of tabs.

I agree that the term swipe can easily be misunderstood, and the differentiation of swiping and dragging is not straightforward. 2.5.1 would also cover gestures that are not quick flicking gestures but do require (initial) directionality. One of the problems is that the need for an initial directional movement may depend on the user agent; for example, for horizontal sliders on a touch device, moving up the pointer (finger) may cause scrolling the view instead of moving the slide, while using another UA with pointer (say, a mouse), no directionality may be required. Having an SC that can be interpreted differently depending on the user agent (thus falling back on the accessibility baseline you define) is not ideal, but that is the result of the normative text of 2.5.1 right now.

If 2.5.7 Dragging Movements makes it into WCAG 2.2, the distinction of swipe and dragging movement will matter less since both SC will then require single pointer operable alternatives.

[emleml]

Thanks @detlevhfischer - understood. Definitely agree that if and once dragging movements comes in this is a mostly moot point.

I have another slight interesting overlap where I feel there is still confusion.

In 1.4.10 reflow it states that if horizontal scrolling is essential to the presentation then the horizontal scrolling can be retained; such as data tables, diagrams etc. In this case, would the horizontal scroll still be a failure of dragging movements but be inapplicable to reflow? In this case I suggest reflow has its wording clarified here as people may be comfortable using the caveat of "essential functionality" to allow horizontal scrolling/'dragging'

[mbgower]

@detlevhfischer is this resolved?

[detlevhfischer]

@mbgower I think we can consider this resolved but @gundulaniemann may think otherwise - the point @emleml makes above about 1.4.10 seems orthogonal to the original issue, it appears to concern the way the user agent handles scrolling and the author insofar as he/she has to ensure that stuff that doesn't wrap is essentially scrollable.

[bruce-usab]

Does anyone disagree that pass/fail for a swipe-only UI component is addressed by SC 2.5.8? I second the ping to @gundulaniemann as to if we can close.