Is swiping a path-based gesture?

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.

Example 1: Street Maps

Map interfaces allow you to swipe in any direction to move the map, e.g. swiping left moves the map to the left, or swiping upwards moves it upwards.

If you were to swipe upwards, halfway through swiping left, then it wouldn’t just move to the left, it would move up and to the left. If you were to swipe 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.

Example 2: Horizontal Sliders and Carousels

With horizontal sliders and carousels, you can only swipe in one directional axis — left or right — while any up or down movement is ignored. If you were to swipe 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 swipe 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 swiping 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: Native Interactions

Native interactions that are provided by a browser or operating system, such as mobile devices that use swiping to provide page navigation, scrolling, refresh, and similar functions, do not need to be considered for the purposes of 2.5.1. 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.


Categories: Development, KnowledgeBase Content, World of Accessibility

About James Edwards

I’m a web accessibility consultant with around 20 years experience. I develop, research and write about all aspects of accessible front-end development, with a particular specialism in accessible JavaScript. I can also turn my hand to PHP and MySQL when it’s needed. I started my career as an HTML coder, then as a JavaScript developer, but the more I learned, the more I realised just how important it is to consider accessibility. It’s the basic foundation of web development and a fundamental design principle of the web itself. If information is not accessible, then what’s the point of any of it? Coding is mechanics, but accessibility is people, and it’s people that actually matter.