Accessibilité mobile d'un e-commerce : les règles WCAG à connaître
En bref — l'accessibilité sur mobile
La majorité du trafic et des achats e-commerce se fait aujourd'hui sur smartphone, et l'European Accessibility Act s'applique aux sites mobiles exactement comme aux versions bureau (même norme : EN 301 549 / WCAG 2.1 niveau AA). Les points spécifiques au mobile :
- Cibles tactiles assez grandes et espacées pour être touchées sans erreur du bout du doigt ;
- Zoom et reflow : le contenu doit rester lisible en agrandissant, sans défilement horizontal (critères 1.4.4 et 1.4.10) ;
- Orientation libre : ne pas verrouiller l'affichage en portrait ou en paysage (critère 1.3.4) ;
- Gestes simples : toute action faite par balayage ou pincement doit avoir une alternative à un seul appui (critère 2.5.1) ;
- Pas de fonction dépendant uniquement du mouvement de l'appareil — secouer, incliner (critère 2.5.4) ;
- Saisie facilitée : bon type de clavier, étiquettes visibles, autocomplétion.
Concevoir mobile-first et accessible va dans le même sens : les deux exigent des zones tactiles généreuses, une mise en page qui s'adapte et des parcours simples.
Une boutique peut être impeccable sur grand écran et inutilisable au pouce : boutons collés les uns aux autres, menu qui déborde dès qu'on zoome, carrousel qui ne répond qu'au balayage, formulaire qui ouvre le mauvais clavier. Or c'est sur mobile que se joue désormais l'essentiel des ventes — et c'est là que les barrières d'accessibilité coûtent le plus cher, en conversions comme en conformité. Voici ce que l'EAA attend précisément d'un site mobile, et comment le vérifier.
Pourquoi le mobile mérite une attention particulière
L'EAA ne crée pas de « norme mobile » séparée : la référence reste la même, EN 301 549, qui s'appuie sur les WCAG 2.1 niveau AA, applicables aux services de commerce électronique depuis le 28 juin 2025. Mais plusieurs critères ont été pensés précisément pour l'usage tactile et les petits écrans — ils ont été ajoutés dans la version 2.1 des WCAG justement pour couvrir le mobile. Les ignorer, c'est laisser une part majoritaire de votre audience devant une porte fermée.
Bonne nouvelle : l'accessibilité mobile et l'ergonomie mobile tirent dans le même sens. Une cible tactile confortable, une page qui se réagence proprement, un parcours d'achat court : ce sont des principes d'UX mobile classiques, qui se trouvent être aussi des exigences d'accessibilité. Vous n'avez presque jamais à choisir entre les deux.
Les 6 règles de l'accessibilité mobile
Des zones à toucher assez grandes et espacées
Un lien, un bouton, une case à cocher doivent pouvoir être activés du bout du doigt sans viser. La recommandation de référence : une cible d'au moins 44 × 44 px (critère 2.5.5, niveau AAA des WCAG 2.1) — la version 2.2 des WCAG a depuis introduit un minimum de niveau AA à 24 × 24 px (critère 2.5.8). En pratique, viser 44 px met à l'aise tout le monde. Surtout : espacez les cibles voisines pour éviter les appuis accidentels (un « – » et un « + » de quantité collés sont un piège classique).
Le contenu reste lisible quand on agrandit
Deux exigences se combinent. 1.4.4 (Redimensionnement du texte) : l'utilisateur doit pouvoir agrandir le texte jusqu'à 200 % sans perte d'information ni de fonction. 1.4.10 (Redistribution / reflow) : le contenu doit s'afficher sur une largeur équivalente à 320 px (soit un zoom à 400 %) sans défilement horizontal — il se réorganise en une seule colonne. Première erreur à bannir : la balise <meta viewport> qui interdit le zoom (user-scalable=no ou maximum-scale=1).
user-scalable=no ; un tableau de tailles qui force un défilement latéral ; un menu qui sort de l'écran au zoom.Portrait et paysage, au choix de l'utilisateur
Le critère 1.3.4 interdit de verrouiller l'affichage dans une seule orientation. Certaines personnes ont leur téléphone fixé sur un fauteuil ou un support en mode paysage ; forcer le portrait les bloque. Le contenu et les fonctions doivent rester disponibles dans les deux sens, sauf si une orientation est essentielle (un cas rare en e-commerce). Évitez le CSS ou le réglage applicatif qui impose une orientation.
Toujours une alternative à un seul doigt
Le critère 2.5.1 exige que toute fonction reposant sur un geste complexe — balayage, pincement-zoom, tracé, appui à plusieurs doigts — dispose d'une alternative à un seul point de contact (un simple appui). Un carrousel produit qui ne défile qu'au swipe doit aussi offrir des flèches « précédent / suivant ». Complément utile, le critère 2.5.2 (Annulation de l'appui) : l'action ne doit se déclencher qu'au relâchement du doigt, pour qu'on puisse glisser hors de la cible et annuler une erreur.
Ne jamais dépendre d'un secouage ou d'une inclinaison
Le critère 2.5.4 vise les fonctions activées par le mouvement du téléphone (secouer pour annuler, incliner pour faire défiler). Ces interactions doivent toujours : (a) avoir une commande à l'écran équivalente, et (b) pouvoir être désactivées pour éviter les déclenchements involontaires — essentiel pour les personnes ayant des tremblements ou tenant leur appareil sur un support. C'est rare en e-commerce, mais on le croise dans des mini-jeux promotionnels ou des effets « agiter pour révéler une offre ».
Le bon clavier, des étiquettes visibles, l'autocomplétion
Sur mobile, taper coûte cher : chaque facilité compte. Déclarez le bon type de champ pour faire apparaître le clavier adapté (type="email", type="tel", inputmode="numeric" pour un code postal). Gardez une étiquette visible au-dessus du champ — pas un simple placeholder qui disparaît à la saisie. Activez l'autocomplétion (autocomplete="email", "given-name", "postal-code"…) pour que le navigateur pré-remplisse l'adresse et les coordonnées : c'est exigé par le critère 1.3.5 et c'est un gain de conversion direct.
type="email" + autocomplete ; étiquette persistante au-dessus.type="text" (clavier générique), étiquette uniquement en placeholder.Récapitulatif des critères mobiles
| Point à vérifier sur mobile | Niveau | Critère WCAG |
|---|---|---|
| Taille & espacement des cibles tactiles | AAA / AA (2.2) | 2.5.5 / 2.5.8 |
| Texte agrandissable à 200 % | AA | 1.4.4 |
| Reflow à 320 px sans scroll horizontal | AA | 1.4.10 |
| Orientation non verrouillée | AA | 1.3.4 |
| Alternative aux gestes complexes | A | 2.5.1 |
| Action au relâchement (annulable) | A | 2.5.2 |
| Alternative au mouvement de l'appareil | A | 2.5.4 |
| Champ porte son nom visible (label in name) | A | 2.5.3 |
| Autocomplétion des champs d'identité | AA | 1.3.5 |
<meta name="viewport"> avec user-scalable=no ou maximum-scale=1, qui désactive le zoom. C'est un réflexe ancien pour « figer » la mise en page, mais il bloque net les critères 1.4.4 et 1.4.10 et pénalise toute personne qui a besoin d'agrandir. Vérifiez cette balise en premier : la corriger est souvent une ligne de code.
Comment tester l'accessibilité mobile
Quelques vérifications gratuites, en plus d'un scan automatique :
- Zoomez à 200 % puis à 400 % dans le navigateur (ou pincez pour zoomer sur le téléphone) : rien ne doit être coupé, et aucun défilement horizontal ne doit apparaître.
- Tournez l'appareil en paysage : tout reste-t-il accessible ?
- Naviguez au doigt sur un vrai téléphone : les boutons sont-ils faciles à toucher sans erreur ? Le carrousel a-t-il des flèches ?
- Activez le lecteur d'écran mobile (VoiceOver sur iOS, TalkBack sur Android) et parcourez une fiche produit jusqu'au paiement.
- Le mode responsive des DevTools du navigateur simule différentes tailles d'écran et le reflow.
→ Méthode complète : comment tester l'accessibilité de son site. Pour la saisie, voir le guide du tunnel de commande et des formulaires accessibles.
Vérifiez l'accessibilité de votre boutique gratuitement
DeclareAccess analyse une page de votre site avec le moteur axe-core selon les WCAG 2.1 AA, repère les manquements (contraste, cibles, structure, formulaires…) et génère la déclaration d'accessibilité prête à publier — modèle français (RGAA), allemand (BFSG), italien ou espagnol. Gratuit, sans carte bancaire.
Rapport WCAG par e-mail sous 24 h ouvrées.
C'est noté. Votre client e-mail va s'ouvrir avec la demande pré-remplie — il vous suffit de l'envoyer.
Questions fréquentes
L'EAA s'applique-t-elle aussi à mon application mobile ?
Oui. L'European Accessibility Act vise les services de commerce électronique quel que soit leur support : site web responsive comme application mobile native. Avoir une application accessible ne dispense pas le site web de l'être, et inversement. La même référence technique (EN 301 549, fondée sur les WCAG 2.1 AA) s'applique, avec des adaptations pour le logiciel natif.
Quelle taille minimale pour un bouton tactile ?
La recommandation historique des WCAG 2.1 est de 44 × 44 px (critère 2.5.5, niveau AAA). Les WCAG 2.2 ont ajouté un minimum de niveau AA à 24 × 24 px (critère 2.5.8). Comme l'EAA s'appuie aujourd'hui sur les WCAG 2.1, le minimum de 24 px n'est pas encore formellement exigé, mais c'est une bonne pratique forte : viser au moins 44 px et bien espacer les cibles met à l'aise tous les utilisateurs et anticipe la mise à jour de la norme.
Puis-je désactiver le zoom pour préserver ma mise en page ?
Non. Désactiver le zoom via user-scalable=no ou maximum-scale=1 dans la balise viewport empêche les utilisateurs d'agrandir le contenu, ce qui contrevient aux critères 1.4.4 (redimensionnement du texte) et 1.4.10 (reflow). Une mise en page bien conçue reste propre même au zoom ; le verrouillage du zoom est à supprimer.
Un carrousel qui défile au balayage est-il un problème ?
Pas en soi, à condition d'offrir une alternative. Le critère 2.5.1 impose qu'une fonction reposant sur un geste complexe (balayage, pincement) dispose d'une commande équivalente à un seul appui. Concrètement, un carrousel produit qui ne réagit qu'au swipe doit aussi proposer des flèches « précédent » et « suivant » cliquables.
Mon site est responsive : est-il automatiquement accessible sur mobile ?
Non. Le responsive design adapte la mise en page à la taille de l'écran, mais ne garantit ni des cibles tactiles suffisantes, ni un zoom autorisé, ni des alternatives aux gestes, ni le bon type de clavier. L'accessibilité mobile recoupe l'ergonomie responsive sans s'y réduire : il faut vérifier les critères spécifiques (cibles, reflow, orientation, gestes, saisie) en plus de l'adaptation visuelle.