Dans chaque page web, les fonctionnalités utilisables ou disponibles au moyen d’un geste complexe peuvent-elles être également disponibles au moyen d’un geste simple (hors cas particuliers) ?
Un utilisateur avec des tremblements essentiels ou une mobilité réduite des mains ne peut pas réaliser un pincement à deux doigts, ni tracer une trajectoire précise sur un écran. Si votre application ne propose que ces gestes pour accéder à une fonctionnalité, elle l’exclut de fait. Ce critère impose qu’une alternative en un seul point de contact soit toujours disponible.
Deux familles de gestes sont visées. La première est le contact multipoint : deux doigts ou plus agissant simultanément (pincement pour zoomer, balayage bidigital pour naviguer dans un carousel, rotation à deux doigts). Pour chacune de ces interactions, une alternative ponctuelle doit exister : boutons « Précédent » et « Suivant » pour la navigation en liste, boutons « + » et « - » pour le zoom.
La seconde famille recouvre les gestes basés sur une trajectoire : dessiner un chemin sur l’écran, suivre un tracé. Un schéma de déverrouillage, un mot de passe saisi par tracé sur clavier virtuel. L’alternative est simple : permettre la saisie via des pressions successives sur les touches individuelles. Pas de tracé imposé.
Le périmètre est limité aux fonctionnalités que vous avez implémentées. Les gestes natifs du système d’exploitation ou du navigateur (zoom iOS, navigation par geste Chrome) ne relèvent pas de votre responsabilité.
2 tests pour vérifier qu'une alternative simple remplace chaque geste complexe
Alternative à contact unique pour les gestes multipoints
- Recensez toutes les fonctionnalités qui nécessitent un contact multipoint (deux doigts ou plus simultanément) : carousel par balayage bidigital, carte avec pincement pour zoomer, galerie avec rotation à deux doigts.
- Pour chacune, vérifiez qu’une alternative par contact en un seul point est disponible dans la même page : boutons « Précédent »/« Suivant » pour le carousel, boutons « + »/« - » pour le zoom.
- L’alternative doit être accessible par défaut, sans paramètre à activer.
- Si chaque fonctionnalité multipoint dispose d’une alternative ponctuelle, le test est validé.
Alternative à contact unique pour les gestes à trajectoire
- Recensez toutes les fonctionnalités qui exigent de tracer une trajectoire sur l’écran : schéma de déverrouillage, saisie de mot de passe par tracé sur clavier virtuel, dessin requis pour valider une action.
- Pour chacune, vérifiez qu’une alternative par contact ponctuel successif est disponible : si le mot de passe se compose en suivant un chemin sur le clavier virtuel, l’utilisateur doit pouvoir taper chaque lettre individuellement.
- Vérifiez si une exception s’applique avant de conclure à une non-conformité :
- Les gestes imposés par le système d’exploitation ou le navigateur sont hors périmètre.
- Si le tracé est intrinsèquement lié à la fonctionnalité (signature manuscrite, reconnaissance d’écriture), l’exception est valide.
- Si chaque fonctionnalité par trajectoire dispose d’une alternative ponctuelle ou relève d’une exception légitime, le test est validé.
Exemples
❌ Non conforme : Carousel navigable uniquement par balayage bidigital
<div class="carousel" id="carousel-produits">
<ul class="carousel__track">
<li class="carousel__item">Produit 1</li>
<li class="carousel__item">Produit 2</li>
<li class="carousel__item">Produit 3</li>
</ul>
<!-- Navigation gérée par swipe à deux doigts via Hammer.js,
aucun bouton Précédent/Suivant fourni -->
</div>La navigation entre les éléments du carousel n’est accessible qu’au moyen d’un geste à deux doigts. Un utilisateur présentant des tremblements, utilisant un joystick ou n’ayant qu’un seul doigt valide ne peut pas consulter les produits suivants. Le critère 13.10.1 est en échec.
✅ Conforme : Carousel avec boutons de navigation en complément du balayage
<section aria-label="Carousel de produits">
<button
type="button"
class="carousel__btn carousel__btn--prev"
aria-label="Produit précédent"
>
‹
</button>
<ul class="carousel__track" aria-live="polite">
<li class="carousel__item" aria-current="true">Produit 1</li>
<li class="carousel__item">Produit 2</li>
<li class="carousel__item">Produit 3</li>
</ul>
<button
type="button"
class="carousel__btn carousel__btn--next"
aria-label="Produit suivant"
>
›
</button>
</section>Les boutons « Précédent » et « Suivant » permettent de naviguer dans le carousel avec un seul doigt, au clavier ou via n’importe quel dispositif de pointage. Le geste de balayage bidigital reste disponible pour ceux qui le préfèrent, mais n’est plus la seule voie d’accès.
❌ Non conforme : Carte interactive avec zoom uniquement par pincement
<div
id="map"
class="map-container"
data-gesture="pinch-zoom"
aria-label="Carte interactive"
>
<!-- Zoom disponible uniquement via pincement à deux doigts.
Aucun bouton + / - fourni. -->
</div>Le zoom par pincement est un geste multipoint. Sans boutons « + » et « - » ou équivalents, les utilisateurs ne pouvant effectuer ce geste sont privés de la possibilité d’explorer la carte à différents niveaux de détail.
✅ Conforme : Carte interactive avec boutons de zoom en complément du pincement
<div aria-label="Carte interactive" class="map-wrapper">
<div id="map" class="map-container" data-gesture="pinch-zoom"></div>
<div class="map-controls" role="group" aria-label="Contrôles de zoom">
<button type="button" class="map-zoom-in" aria-label="Zoomer">
+
</button>
<button type="button" class="map-zoom-out" aria-label="Dézoomer">
−
</button>
</div>
</div>Les boutons « + » et « - » reproduisent en un seul tap ce que le pincement réalise en deux doigts. L’information cartographique est accessible à tous les utilisateurs, quel que soit leur dispositif ou leurs capacités motrices.
Astuces et pièges
⚠️ L’exception « essentiel » invoquée trop facilement
L’exception « le geste complexe est essentiel » ne s’applique qu’à un nombre très restreint de cas — la signature manuscrite en est l’exemple canonique. Un carousel, une galerie photo, un zoom de carte : aucun de ces cas n’est essentiel. C’est l’erreur la plus fréquente en audit : cette exception sert à couvrir une absence de boutons qui n’a jamais été implémentée.
💡 Tester sur un appareil physique, pas seulement en émulation
Les outils de développement des navigateurs simulent le toucher, mais ne reproduisent pas fidèlement tous les gestes multipoints. Pour valider ce critère, testez sur un vrai smartphone ou une vraie tablette. Vérifiez que les boutons alternatifs fonctionnent au doigt, et que le geste complexe original fonctionne toujours en parallèle.
⚠️ Slider personnalisé et gestes par trajectoire
Un <input type="range"> natif répond aux flèches clavier et au clic direct : il est conforme sans effort particulier. En revanche, si vous implémentez un slider personnalisé qui exige de glisser précisément le long d’un axe (trajectoire), vérifiez qu’un clic direct sur la piste permet aussi de définir la valeur sans tracé de trajectoire. C’est ce que couvre la technique WCAG G216.
⚠️ Les gestes système sont hors périmètre
Le pincement pour zoomer au niveau de l’OS (iOS, Android), la navigation par geste du navigateur, le retour arrière par balayage depuis le bord de l’écran : ces gestes ne sont pas de votre ressort. Le critère 13.10 ne s’applique qu’aux fonctionnalités que vous avez vous-même codées dans la page.
💡 L’alternative doit être disponible par défaut, sans option à activer
Certaines implémentations masquent les boutons de navigation derrière un réglage « mode accessibilité » ou une option utilisateur. Ce n’est pas conforme. L’alternative au geste complexe doit être présente et fonctionnelle dans la page dès le premier chargement, sans action préalable.
Questions fréquentes
Pourquoi un swipe à un seul doigt constitue-t-il un geste complexe selon le RGAA ?
Oui. Un glissement implique de suivre une trajectoire sur l’écran, même avec un seul doigt. Il entre dans le périmètre du test 13.10.2. Seul un tap (appui et relâchement sur un point fixe, sans mouvement) est considéré comme un geste simple au sens de ce critère.
Dans quels cas le critère RGAA 13.10 s'applique-t-il au drag-and-drop à la souris ?
Le texte RGAA cible les interactions au toucher, mais WCAG 2.5.1 couvre tout dispositif de pointage, y compris la souris. En pratique, un drag-and-drop sans alternative sera signalé lors d’un audit : soit via ce critère, soit via les exigences de navigation clavier. Prévoyez toujours une alternative indépendante du type de geste.
Comment auditer le critère RGAA 13.10 sans appareil tactile physique ?
Activez l’émulation tactile dans les DevTools de Chrome (F12 > icône mobile) ou Firefox. Naviguez en cliquant uniquement, sans drag. Toute fonctionnalité bloquée dans ce mode révèle un geste complexe sans alternative. Pour une couverture complète, testez ensuite sur un vrai appareil : les émulateurs ne reproduisent pas tous les événements multipoint.
Pourquoi un raccourci gestuel facultatif requiert-il quand même une alternative accessible en RGAA ?
Non, si la fonctionnalité principale reste accessible par un geste simple. Le swipe peut être un raccourci pratique, à condition que les boutons existent déjà. C’est d’ailleurs la logique recommandée : l’interface de base repose sur des contrôles simples, les gestes complexes enrichissent l’expérience sans conditionner l’accès.
Comment une application de dessin doit-elle gérer les alternatives aux gestes complexes selon le RGAA ?
Les gestes dont la trajectoire est l’objet même de la fonctionnalité sont explicitement exclus du critère. Tracer un trait libre ou apposer une signature : le geste est essentiel, aucune alternative n’est requise. En revanche, si la même application propose un zoom par pinch ou un défilement multi-doigts, ces fonctionnalités doivent avoir leurs équivalents à contact unique.