Mobile Gestures: Discoverability and Alternatives

What is a gesture, and what makes it hard to discover?

Gestures matter most in mobile-first products, where nearly everything happens under the thumb. A gesture has no visible form. A button is seen and tapped; a side swipe to delete a task, or a pinch to zoom a map, only works if the user knows it exists. That is the central difference: a gesture adds a layer of knowledge the user has to bring with them or learn. Apple frames it this way in its guidelines: a custom gesture should be discoverable, straightforward to perform, distinct from other gestures, and not the only way to perform an important action.

That is why the first test for a gesture is simple: does the user reach the function without having learned the gesture first? If not, the gesture must be the second way in, never the first.

What does WCAG say about gestures?

Criterion 2.5.1 (Pointer Gestures, level A) matters most here. In essence, it says that any functionality using multipoint or path-based gestures must be operable with a single pointer, without requiring a path-based gesture, unless the gesture is essential.

Four ideas are worth understanding well:

• An essential gesture is a narrow exception. It is one that, if removed, would fundamentally change the function. The source’s example is entering a signature, while confirming your identity need not be a stroke. A pinch to zoom is not essential, because the same result can be reached with buttons.
• It only covers gestures the content author defines. Operating system, browser, or assistive technology gestures, such as swiping down for system notifications, fall outside the criterion.
• Dragging has its own criterion. Dragging movements are assessed under 2.5.7 (Dragging Movements, level AA), not 2.5.1. An alternative to dragging also cannot rely only on a path-based gesture such as swiping.
• The failure is documented. Failure technique F105 describes exactly this: a function that only works with a path-based gesture, with no single-pointer alternative.

The intent of the criterion is to help people who cannot perform gestures precisely and people who use adapted tools, such as a head pointer, an eye-gaze system, or a speech-controlled mouse emulator. That is why the alternative is not a compatibility detail. It is part of the design.

Why does this matter for a junior designer?

Because gestures are among the decisions most often made “to look modern” and least often reviewed afterward. A junior who proposes swiping to delete, with no visible button, is designing a hidden function. Hidden functions get used rarely, even when they work well.

A gesture is also a common obstacle for people who use an adapted pointer or cannot make precise strokes. Checking the single-tap alternative is, in practice, testing the accessibility of the flow. To start, try screen reader testing.

How do you design the alternative and the discoverability?

1. Always offer a visible path. If users can delete a task by swiping, there must also be a delete button, in the task’s menu or on its detail screen. That button must also meet the touch target sizes.
2. Use visual cues. A card peeking in from the edge suggests more content to the side. A thin bar at the bottom suggests the screen scrolls. These are hints, not guarantees.
3. Keep gestures consistent across the app. If swiping left deletes on one screen and archives on another, users cannot learn the pattern.
4. Avoid clashing with system gestures. Apple asks designers not to define custom gestures that conflict with those that access system UI, because people expect those controls to work consistently. An app gesture that starts at the screen edge competes with them.
5. Explain the gesture in onboarding and in the help menu. A gesture explained once and then forgotten is still useful when a visible path exists.

A quick discoverability test: give a user the task with no guidance and watch whether they find the gesture or the visible alternative within a minute. If they do not, the gesture is hidden, and the visible path needs more weight in the design.

WCAG gives two clear examples. A map that supports pinch zoom also offers plus and minus buttons. And a news carousel that responds to fast horizontal swipes also has forward and backward buttons that work with a single tap.

When is a gesture a good idea?

• When the gesture is part of the function, not only a shortcut. Drawing or signing are cases where the gesture is the content.
• When it is a shortcut for frequent users and a visible path exists. Apple puts it as using shortcut gestures to supplement standard ones, not replace them: swipe-to-archive in an email app works if the archive button stays in the menu.
• When the operating system already sets the pattern. Apple recommends not using a familiar gesture for an action unique to your app, nor inventing a new gesture for a standard action such as pressing a button or scrolling a list.

A simple question helps decide: if the gesture disappeared, would anyone miss it? If not, it is decoration, and it can go.

By contrast, a gesture should not be the only way to perform a destructive action, nor a complicated two-finger, path-based gesture for something done a hundred times a day.

Example

Illustrative example: a notes app where each note is deleted by swiping left.

• Problem: new users do not know the gesture exists, and screen reader users cannot delete notes at all.
• Fix: the swipe still works, but each note also gets a three-dot menu with “Delete”. The menu is visible and can be operated with a single tap.
• Check: the action is tested with a screen reader and one-handed. The confirmation step from the menu is verified, since deleting is destructive.

Both routes now lead to the same confirmation step, so there is one behavior to test and one to explain in onboarding. The gesture does not disappear; it stops being the only route. That change is what makes the flow work for everyone, not only for people who discover the gesture.

Common mistakes

• Making a gesture the only way to perform an action.
• Using pinch to zoom on a map without zoom-in and zoom-out buttons.
• Creating different gestures for the same action on different screens.
• Assigning gestures to zones where the operating system already acts.
• Designing complicated gestures for functions users perform every day.
• Testing gestures only with a mouse or a simulator, without a real phone.

Sources

• W3C, Understanding SC 2.5.1: Pointer Gestures
• W3C, Understanding SC 2.5.7: Dragging Movements
• Apple, Human Interface Guidelines: Gestures