Applications mobiles accessibles : les points de contrôle

Le site web a été audité et corrigé ; l’application mobile, développée par un autre prestataire, n’a jamais été testée avec un lecteur d’écran. C’est une situation courante, et l’écart se voit vite : boutons annoncés « bouton » sans autre précision, formulaires impossibles à valider, texte qui déborde dès que l’utilisateur agrandit la police. L’accessibilité mobile obéit aux mêmes principes que le web, avec des points de contrôle propres.

Ce guide les regroupe par situation d’usage plutôt que par numéro de critère, pour qu’une équipe de développement ou de recette puisse les vérifier écran par écran.

Le cadre applicable

Les WCAG 2.2, publiées par le W3C en octobre 2023, s’appliquent aux applications mobiles ; le W3C publie des indications pour les transposer aux logiciels hors web. La norme européenne EN 301 549 contient des exigences pour les logiciels et sert de référence aux obligations européennes. En France, le RGAA 4.1.2 sert de méthode d’évaluation pour les services publics, y compris leurs applications. Le European Accessibility Act, applicable depuis le 28 juin 2025, étend des obligations à des services privés comme la banque, le transport ou le commerce en ligne.

Points de contrôle par situation d’usage

Avec un lecteur d’écran (VoiceOver, TalkBack)

• Chaque élément interactif a un nom qui dit ce qu’il fait (« Supprimer le document », pas « Icône »).
• Le rôle est annoncé correctement : bouton, lien, case à cocher, onglet, en-tête.
• L’état est annoncé : sélectionné, développé, désactivé.
• L’ordre de lecture suit l’ordre logique de l’écran.
• Les images décoratives sont ignorées ; les images informatives ont une description.
• Les messages d’erreur et de confirmation sont annoncés sans que l’utilisateur ait à les chercher.
• À l’ouverture d’une fenêtre ou d’un panneau, le focus s’y place ; à sa fermeture, il revient au point de départ.

Avec une taille de texte agrandie

• Le texte suit la taille choisie dans les réglages du téléphone (Dynamic Type sur iOS, taille de police sur Android).
• À la taille maximale, aucun texte n’est tronqué ni superposé ; les écrans défilent si nécessaire.
• Les boutons s’agrandissent avec leur texte.

Au toucher

• Les cibles tactiles font au moins 24 par 24 pixels CSS (WCAG 2.2, critère 2.5.8) ; viser les tailles recommandées par les plateformes, autour de 44 points sur iOS et 48 dp sur Android.
• Les cibles sont assez espacées pour ne pas toucher la voisine par erreur.
• Toute action par geste complexe (balayage à plusieurs doigts, pincement, tracé) a une alternative par simple appui (critère 2.5.1).
• Toute action par glissement a une alternative sans glissement (critère 2.5.7).
• Aucune fonction ne dépend uniquement du fait de secouer ou d’incliner l’appareil (critère 2.5.4).

Dans les deux orientations

• L’application fonctionne en portrait et en paysage, sauf si une orientation est indispensable (critère 1.3.4).
• Le contenu se réorganise sans perte d’information lors d’un changement d’orientation.

Avec un clavier ou un dispositif de commande externe

• Tous les éléments interactifs sont atteignables avec un clavier Bluetooth ou un contacteur.
• Le focus est visible et ne reste jamais bloqué dans une zone.

Pour la perception et la compréhension

• Le texte atteint un contraste de 4,5 pour 1 ; les icônes et composants porteurs de sens, 3 pour 1.
• Aucune information n’est donnée par la couleur seule.
• Le mode sombre, s’il existe, respecte les mêmes contrastes.
• Les champs de formulaire ont une étiquette visible et persistante, pas seulement un texte indicatif qui disparaît à la saisie.
• L’authentification n’exige pas de mémoriser ou de recopier un code sans aide : le collage et les gestionnaires de mots de passe sont autorisés (critère 3.3.8).
• Les vidéos ont des sous-titres ; les contenus audio, une transcription.

Organiser les tests

1. Lancer les scanners des plateformes (Accessibility Inspector sur iOS, Accessibility Scanner sur Android) pour éliminer les erreurs évidentes.
2. Choisir trois à cinq parcours essentiels : créer un compte, se connecter, réaliser la démarche principale, contacter le service.
3. Parcourir chacun avec VoiceOver puis TalkBack, écran éteint si possible, pour vérifier qu’il est réalisable sans la vue.
4. Refaire les parcours à la taille de texte maximale, puis en paysage.
5. Faire tester par des personnes handicapées, utilisatrices régulières de ces aides techniques. Leurs usages réels diffèrent souvent de ceux d’un testeur qui les découvre.
6. Consigner les anomalies avec l’écran, le parcours, l’aide technique et sa version.

Publier et maintenir

Pour les services publics, la déclaration d’accessibilité s’applique aussi à l’application : état de conformité, contenus non accessibles, moyen de signaler un problème. Chaque nouvelle version doit repasser au moins les parcours essentiels, car une régression d’accessibilité passe facilement inaperçue dans une recette fonctionnelle.

Ces contrôles font partie de l’expertise web accessible de DOSOBE ; le cadre général est présenté dans le dossier complet sur l’accessibilité numérique.

Questions fréquentes

Les applications mobiles sont-elles soumises aux obligations d'accessibilité ?

Oui. En France, l'obligation d'accessibilité des services publics en ligne couvre les applications mobiles, évaluées selon le RGAA. La norme européenne EN 301 549 contient des exigences pour les logiciels, dont les applications. Le European Accessibility Act, applicable depuis le 28 juin 2025, étend les obligations à certains services privés, comme la banque ou le commerce en ligne.

Les outils automatiques suffisent-ils ?

Non. Les scanners d'accessibilité des plateformes détectent une partie des problèmes (contrastes, étiquettes manquantes, tailles de cibles). Ils ne disent pas si l'ordre de lecture a du sens ou si un parcours est réalisable avec un lecteur d'écran. Un test manuel reste indispensable.

Quelle taille minimale pour une cible tactile ?

Les WCAG 2.2 fixent un minimum de 24 par 24 pixels CSS au niveau AA (critère 2.5.8), avec des exceptions. Les recommandations d'Apple et de Google sont plus généreuses, autour de 44 points sur iOS et 48 dp sur Android, et sont à privilégier.