On each web page, can features that are usable or available through a complex gesture also be available through a simple gesture (except in special cases)?
A user with hemiplegia, or whose fine motor control is impaired by tremor, cannot perform a two-finger pinch or trace a precise trajectory on a screen. If your map only displays pinch-to-zoom and your carousel only a swipe, these features are inaccessible to them. No simple gesture: no access.
Two categories of complex gestures are involved. The first: multipoint contacts (pinch to zoom, rotate with two fingers, swipe with multiple fingers simultaneously). The second: gestures that follow an imposed trajectory on the screen, such as drawing a letter on a gesture keyboard or tracing an arc to trigger an action. In both cases, a single-contact alternative must exist on the page.
Concretely, list all touch interactions. For each complex gesture identified, verify that a button or simple control accomplishes the same action: "+" and "-" buttons for zoom, "Previous" and "Next" arrows for a carousel, individual keys for a gesture keyboard.
The alternative does not need to be as fast. It just needs to work.
2 tests to verify that a simple alternative replaces each complex gesture
Alternative to multipoint contact for gestures
- Identify all features that require multipoint contact: pinch to zoom, rotate an element with two fingers, simultaneous multi-finger swipe.
- For each identified feature, verify that a single-contact alternative exists and accomplishes the same action ("+" and "-" buttons for zoom, "Previous" and "Next" buttons for a carousel).
- All multipoint features have a single-contact alternative: test validated. At least one does not: test failed.
Alternative to contact for path-based gestures
- Identify all features that require following a precise trajectory on the screen: gesture keyboard, drawn password, arc or custom curve gesture.
- For each identified feature, verify that a single-contact alternative exists and accomplishes the same action: individual keys on a standard keyboard, classic text input, dedicated button.
- All trajectory features have a single-contact alternative: test validated. At least one does not: test failed.
Note: exclude gestures imposed by the browser or operating system, and gestures where the trajectory is the object of the feature itself (signature tracing, for example).
Examples
❌ Non-compliant : Carousel navigable only by touch swipe
<div class="carousel" id="carousel">
<ul class="carousel-track">
<li class="slide"><img src="produit-1.jpg" alt="Brown leather jacket"></li>
<li class="slide"><img src="produit-2.jpg" alt="Black leather jacket"></li>
<li class="slide"><img src="produit-3.jpg" alt="Red leather jacket"></li>
</ul>
<!-- No buttons: navigation only via touchmove -->
</div>The user can navigate between slides only by horizontal swipe. Anyone unable to perform this gesture — reduced motor control, keyboard user, mouse user — never sees the other carousel elements. The feature is technically present, but inaccessible.
✅ Compliant : Carousel with navigation buttons complementing the swipe
<div class="carousel" id="carousel">
<ul class="carousel-track">
<li class="slide"><img src="produit-1.jpg" alt="Brown leather jacket"></li>
<li class="slide"><img src="produit-2.jpg" alt="Black leather jacket"></li>
<li class="slide"><img src="produit-3.jpg" alt="Red leather jacket"></li>
</ul>
<button type="button" class="carousel-prev" aria-controls="carousel" aria-label="Previous product">‹</button>
<button type="button" class="carousel-next" aria-controls="carousel" aria-label="Next product">›</button>
</div>The swipe remains available for those who prefer it. The buttons offer a single-contact alternative: a simple tap is enough. A user with essential tremor, a mouse, or a keyboard navigates products without difficulty.
Tips and pitfalls
⚠️ Single-finger swipe is also a complex gesture
Many developers think only pinch-to-zoom falls within the criterion's scope. A horizontal or vertical swipe describes a trajectory on the screen: it falls under test 13.10.2, even if it involves only one finger. If your carousel or sliding panel only works by swipe, the criterion applies.
⚠️ Native browser or system gestures do not concern you
The criterion only covers features you have implemented in your code. The iOS browser "back" gesture, the macOS trackpad system pinch, the device's native scroll: these are not your JavaScript listeners, not your responsibility. Focus on touch events you manage yourself.
⚠️ Handwritten signature and artistic traces are the only true exceptions
If the drawn trajectory is the object of the feature itself (signing a contract, drawing freely in a graphic tool), the complex gesture is essential and no alternative is required. Conversely, a map zoom, a value slider, or a gesture keyboard for a password are not in this case: their simple alternatives exist and must be implemented.
💡 Test with touch emulation mode in DevTools
In Chrome or Firefox, enable touch emulation (F12 > mobile icon). Navigate by only tapping, without any sliding. Any blocked feature reveals a complex gesture without an alternative. It's the fastest way to identify issues before even touching a physical device.
⚠️ Drag-and-drop is a trajectory gesture
Reordering elements by drag-and-drop involves following a trajectory: test 13.10.2. The classic alternative: "Move up" and "Move down" buttons accessible by keyboard, or a "Cut"/"Paste" mode. Drag-to-reorder interfaces without a keyboard alternative often also fail criterion 13.11.
Frequently asked questions
Why does a single-finger swipe constitute a complex gesture according to RGAA?
Yes. A slide involves following a trajectory on the screen, even with a single finger. It falls within the scope of test 13.10.2. Only a tap (press and release at a fixed point, without movement) is considered a simple gesture under this criterion.
In what cases does RGAA criterion 13.10 apply to mouse drag-and-drop?
The RGAA text targets touch interactions, but WCAG 2.5.1 covers any pointing device, including the mouse. In practice, drag-and-drop without an alternative will be flagged during an audit: either via this criterion or via keyboard navigation requirements. Always provide an alternative independent of the gesture type.
How to audit RGAA criterion 13.10 without a physical touch device?
Enable touch emulation in Chrome DevTools (F12 > mobile icon) or Firefox. Navigate by clicking only, without drag. Any feature blocked in this mode reveals a complex gesture without an alternative. For complete coverage, then test on a real device: emulators do not reproduce all multipoint events.
Why does an optional gesture shortcut still require an accessible alternative in RGAA?
No, if the main feature remains accessible by a simple gesture. The swipe can be a handy shortcut, as long as buttons already exist. This is moreover the recommended logic: the base interface relies on simple controls, complex gestures enrich the experience without conditioning access.
How should a drawing application handle alternatives to complex gestures according to RGAA?
Gestures whose trajectory is the object of the feature itself are explicitly excluded from the criterion. Drawing a free line or applying a signature: the gesture is essential, no alternative is required. Conversely, if the same application provides zoom by pinch or multi-finger scrolling, these features must have their single-contact equivalents.