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.

[alastc]

I think Detlev has the clearest explanation:

@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.

Except that I don't think it would come under dragging as nothing follows the pointer. So there are three things:

• Path based gestures which requires directionality at the start of the gesture.
• Dragging which requires something to follow the pointer after the down event.
• Everything else, such as non-directional gestures where nothing follows the pointer.

Overall, it would help if @gundulaniemann could reply, but I'm going to add tags for understanding, and remove wcag2.2 as it doesn't impact the dragging SC directly.

[SerenaG93]

I've read all the comments but it's not clear to me if swiping on a mobile carousel to scroll through slides violates SC 2.5.1. The slides out of viewport can be reached by screen reader and keyboard through sequential navigation, but not with a single touch. So are arrows needed? Or swipe in this case isn't a path-based gesture, so it doesn't fail the SC?

[idolofmanyhands]

I'd like to know this as well

[jha11y]

Any update on this? And are gestures to scroll that are a fundamental input mode for mobile operating systems (iOS and Android specifically) exempt from 2.5.1?

[patrickhlauke]

Any update on this? And are gestures to scroll that are a fundamental input mode for mobile operating systems (iOS and Android specifically) exempt from 2.5.1?

Note This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

[WestonThayer]

What qualifies as "web content that interprets pointer actions"? For example, adding CSS overflow-x: scroll to a horizontally scrolling section of an already vertically scrolling page will require a path based gesture to scroll the horizontal area (at least on iOS and Android). overflow-x: scroll is web content. Is it interpreting pointer actions?

[detlevhfischer]

@WestonThayer My understanding so far is that with containers using the CSS overflow attribute it is the operating system or user agent that provides the scroll functionality. Since authors do not explicitly define the swipe behavior (regardless whether pointer gesture or dragging movement) here, this would be out of scope.

It would seem odd to require single point interaction alternatives implemented in all cases where containers do not (or cannot usefully) resize when content is updated or manipulated (sized, spread, added to), and where CSS overflow then ensures that content is not cut off. I agree however that CSS ist part of defining web content, so the distinction is not evident, and we may need to specify author-defined behavior more narrowly.

[mraccess77]

I would consider a swipe gesture a path-based gesture. I do agree that some gestures may not be interpreted by the content and instead by the user agent and would meet the exception.