This is an article pulled from KnowledgeBase, a digital accessibility repository available through TPGi’s ARC Platform. KnowledgeBase is maintained and consistently updated by our experts, and can be accessed by anyone with an ARC Essentials or Enterprise tier subscription. Contact us to learn more about KnowledgeBase or the ARC Platform.
To quote from Understanding SC 2.5.1: Pointer Gestures:
A path-based gesture involves an interaction where not just the endpoints matter. If going through an intermediate point […] also affects its meaning then it is a path-based gesture.
So is swiping a path-based gesture?
Perhaps unsurprisingly, the answer is — it depends.
Gesture Definitions
The original version of this article (June 2023) didn’t differentiate swiping from dragging, sliding or flicking. However that lack of distinction created some ambiguity, since the differences may indeed affect whether a particular gesture can be considered path-based.
The only one of these terms that’s explicitly defined by WCAG is dragging movement:
An operation where the pointer engages with an element on the down-event and the element (or a representation of its position) follows the pointer until an up-event.
This definition is the basis of 2.5.7 Dragging Movements in WCAG 2.2.
From that, we can infer working definitions for the following types of pointer gesture:
- Path-based gestures are dragging movements where the path is significant.
- Sliding is the same as dragging movement.
- Swiping is either a directional dragging movement where a gesture is recognized after the pointer has moved a minimum distance, or, a directional gesture that’s only recognized on the pointer-up event (or both).
- Flicking (aka. Flinging) is a directional gesture that’s only recognized on the pointer-up event.
From these definitions, we can identify two gestures that don’t need to be considered any further:
- Flicking is never a path-based gesture because only the direction is significant, or even specified (notwithstanding things like pressure and acceleration, which are unrelated concerns).
- Consequently, flick-swiping is also never a path-based gesture.
Therefore only drag-based gestures need to be examined in further detail.
Example 1: Street Maps
Map interfaces allow you to drag in any direction to move the map, e.g. dragging left moves the map to the left, or dragging upwards moves it upwards.
It might actually move in the opposite direction depending on the circumstances, but let’s just say that it moves the same way for the sake of argument, the same principles apply either way.
If you were to drag upwards while you’re already dragging left, the map wouldn’t just move to the left, it would move up and to the left. If you were to drag up, to the left, then down again, the map would follow all of those movements. Even if your pointer ended up in the same place as if you’d only moved left, the movements you made to get there are significant.
This is a path-based gesture because the path you took is just as significant as the end point.
Remember that we’re only talking about dragging and drag-swiping here, since flick-swiping is a different gesture that’s never path-based.
In a hypothetical case where flick-swiping is the only available single pointer interaction, this would technically be not applicable for SC 2.5.1 Pointer Gestures and SC 2.5.7 Dragging Movements — because it’s not path-based, and it’s not a dragging movement.
This is rather unfortunate, because one of the intents of 2.5.7 is to support virtual pointer interaction, such as eye-tracking or speech-controlled mouse movement, which generally can’t perform such gestures, or can’t do so accurately. Such an interface should fail 2.5.7 on the basis of intent, but technically it doesn’t.
Example 2: Horizontal Sliders and Carousels
With horizontal sliders and carousels, you can only drag or drag-swipe in one directional axis — left or right — while any up or down movement is ignored. If you were to drag up, to the left, then down again, only the left movement is considered, the vertical movement makes no difference.
This is not a path-based gesture because the path you took is not significant, only the end point matters.
Example 3: Edge Cases
Some carousels only capture horizontal movement within the carousel region, and allow vertical movement outside that to be passed through to the browser. For example, if your dragging moves far enough upwards that it’s outside the carousel, then that triggers vertical scrolling of the page; hence you have to restrict your movements to within that region, in order for left and right movements to work.
In that case, it is a path-based gesture because the path has now become significant.
Although arguably, this is a bad implementation — the interface should ignore vertical movement while there is horizontal movement — but in conformance terms, this implementation would be a path-based gesture.
Example 4: Book Readers
Many book reader applications support gesture navigation, such as swiping left or right to turn the page, or swiping downwards to show settings or bookmarks. These would constitute edge cases based on whether there’s potential for the gestures to conflict, for example:
- If left/right swiping is the only available gesture, then up/down motion wouldn’t matter, therefore this would not be a path-based gesture.
- If separate up/down gestures are also available, then this places constraints on the motion range of the left/right gestures, therefore this would be a path-based gesture.
As with the street map examples, these conditions only apply to drag-swiping, since flick-swiping is never a path-based gesture.
Example 5: Native Interactions
Native gestures provided by a browser or operating system do not need to be considered for the purposes of SC 2.5.1. These would include things like viewport scrolling and pull-to-refresh, as well as navigation gestures used by mobile screen readers. Only author-implemented functionality is included in the normative requirements.
However the bad carousel example would still be included, if the carousel is an author implementation while the scrolling is native functionality, because it’s still fundamentally an author implementation.
Resources
- Read this article in ARC (must be an ARC Essentials or Enterprise subscriber)
- Understanding SC 2.5.1: Pointer Gestures
- Understanding SC 2.5.7: Dragging Movements
Comments