Accessibilité des applications mobiles : exigences WCAG 2.2 pour iOS et Android

Plus de 72% des adultes en situation de handicap possèdent un smartphone, et selon une enquête, environ 86% des utilisateurs de lecteurs d’écran s’appuient sur un appareil mobile — une part plus élevée que les utilisateurs d’ordinateurs de bureau ou portables. Pourtant, les mêmes organisations qui auditent leurs sites web avec rigueur ont souvent des applications mobiles qui n’ont jamais été testées par rapport au moindre critère d’accessibilité. Cet écart se réduit rapidement, sous l’effet de l’évolution de la réglementation, de la multiplication des contentieux et — surtout — des propres recommandations du W3C qui établissent explicitement la correspondance entre WCAG 2.2 et les applications natives iOS et Android.

Pourquoi WCAG 2.2 s’applique à votre application mobile

Il existe un mythe tenace selon lequel WCAG serait une norme réservée au web. Ce n’est pas le cas. Le W3C ne dispose pas de directives distinctes pour l’accessibilité mobile — l’accessibilité mobile est intégrée dans le cadre WCAG existant, et le Mobile Accessibility Task Force (MATF) du W3C a produit des recommandations dédiées intitulées Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile) qui font correspondre chaque critère de succès de niveau A et AA aux applications mobiles natives, aux applications web mobiles et aux applications hybrides.

La conséquence pratique est significative. Lorsque vous lisez un critère de succès WCAG qui fait référence à une « page web », le document WCAG2Mobile remplace ce terme par « écran » ou « vue ». Lorsqu’un critère évoque un « agent utilisateur », il s’agit du système d’exploitation mobile. Les quatre principes POUR — Perceptible, Utilisable, Compréhensible, Robuste — se traduisent directement dans la manière dont un utilisateur interagit avec une vue SwiftUI sur iOS ou une mise en page Jetpack Compose sur Android.

Sur le plan juridique, la pression n’est plus théorique. En vertu du Title II de l’ADA, les règlements mis à jour du DOJ publiés en avril 2024 exigent explicitement que les gouvernements des États et locaux rendent leurs applications mobiles accessibles au niveau WCAG 2.1 AA. Les organismes de santé acceptant Medicare ou Medicaid sont soumis à des exigences similaires en vertu des règles du HHS finalisées en mai 2024. Et bien que les actions en justice visant les applications mobiles du secteur privé soient encore moins fréquentes que celles visant les sites web, au moins un plaignant à fort volume a spécifiquement ciblé des applications mobiles pour défaut d’accès équitable au titre de l’ADA, une tendance qui devrait s’accélérer à mesure que les échéances de conformité au Title II arriveront en 2026.

L’European Accessibility Act (EAA), entré en vigueur le 28 juin 2025 et qui s’appuie sur la norme EN 301 549 comme standard technique présumé, exige également la conformité à WCAG 2.2 pour les produits et services numériques, y compris les applications mobiles vendues ou proposées sur les marchés de l’UE. Pour toute organisation ayant une base d’utilisateurs mondiale, WCAG 2.2 sur mobile n’est pas une ambition future — c’est une obligation actuelle.

Ce qui a changé dans WCAG 2.2 et qui compte le plus pour le mobile

WCAG 2.2, publié en tant que Recommandation du W3C en octobre 2023, ajoute neuf nouveaux critères de succès et supprime le désormais obsolète 4.1.1 Parsing. Il est entièrement rétrocompatible : la conformité à 2.2 implique la conformité à 2.1 et 2.0. Plusieurs des nouveaux critères ont été rédigés en pensant explicitement aux modes d’interaction mobile, et même ceux formulés autour de l’utilisation du clavier ont des analogues directs dans les technologies d’assistance pour iOS et Android.

Il vaut la peine de comprendre la filiation ici. Après 2018, le Mobile Accessibility Task Force a veillé à ce que les considérations mobiles façonnent à la fois WCAG 2.1 et 2.2. Des critères comme 1.3.4 Orientation (AA), 1.4.10 Reflow (AA), 2.5.1 Pointer Gestures (A), 2.5.4 Motion Actuation (A), et les nouveaux 2.5.7 Dragging Movements (AA), 2.5.8 Target Size Minimum (AA) et 3.3.7 Redundant Entry (A) reflètent tous des schémas spécifiques d’ergonomie mobile identifiés grâce à des tests en conditions réelles avec des utilisateurs en situation de handicap sur smartphones et tablettes.

Les neuf nouveaux critères de succès introduits dans WCAG 2.2 ciblent des obstacles spécifiques rencontrés par de vrais utilisateurs : des parcours de connexion qui pénalisent toute personne ayant des problèmes de mémoire, des interfaces qui exigent une main ferme pour des appuis précis, des fonctions d’aide enfouies à des endroits différents sur chaque écran, et des indicateurs de focus qui disparaissent derrière des barres de navigation fixes. Chaque critère colmate une faille concrète — et presque tous ont une application directe sur mobile.

Les nouveaux critères WCAG 2.2 et leur application à iOS et Android

2.5.8 Target Size Minimum (Niveau AA)

C’est sans doute le nouveau critère le plus impactant pour les équipes mobiles. Il exige que les cibles interactives — boutons, liens, champs de formulaire, cases à cocher, interrupteurs — aient une taille minimale de 24 × 24 pixels CSS, ou qu’un espacement de 24 pixels existe entre des cibles adjacentes si la cible elle-même est plus petite. La logique est simple : les utilisateurs ayant des tremblements, la maladie de Parkinson ou une dextérité limitée trouvent réellement impossible de toucher de manière fiable un bouton icône de 16 pixels, et même les utilisateurs sans handicap commettent nettement plus d’erreurs sur de petites cibles.

Pour le développement mobile natif, le minimum de 24 × 24 de WCAG 2.2 est en réalité un plancher, pas un plafond. Les Human Interface Guidelines d’Apple recommandent une cible tactile minimale de 44 × 44 points sur iOS et iPadOS. Le Material Design de Google recommande 48 × 48 pixels indépendants de la densité (dp) sur Android. Si votre application respecte les recommandations de la plateforme Apple ou Google, vous dépassez déjà le minimum WCAG 2.2 — mais beaucoup d’applications ne le font pas. Ces minuscules boutons de fermeture sur les feuilles modales, les cases à cocher filiformes dans les écrans de paramètres et les actions de barre d’outils uniquement en icône qui mesurent 20 × 20 dp sont autant de non-conformités prêtes à être mises en évidence lors d’un audit.

Remarque pratique : l’exigence de WCAG porte sur la zone interactive cliquable, pas sur la taille visuelle de l’icône. Une icône de 16 points entourée de 14 points de marge intérieure de chaque côté a une cible d’appui effective de 44 × 44 points. Cela signifie que les développeurs peuvent satisfaire le critère sans agrandir visuellement les éléments — mais ils doivent définir cette marge de manière explicite, sans compter sur le système pour le faire automatiquement.

2.5.7 Dragging Movements (Niveau AA)

Ce critère exige que toute fonctionnalité mise en œuvre via un geste de glissement — curseurs, réorganisation par glisser-déposer, « pull-to-refresh », défilement de carrousel — soit également réalisable par une action à un seul pointeur ne nécessitant pas de glissement. Sur iOS et Android, les technologies d’assistance natives de la plateforme gèrent certains gestes différemment, mais l’application elle-même doit exposer des alternatives non basées sur le glissement pour tout comportement de glisser personnalisé qu’elle implémente.

En pratique, cela signifie qu’une liste réorganisable par glisser-déposer doit offrir une alternative telle qu’un bouton de type « haut/bas ». Un curseur de plage personnalisé qui ne répond qu’à un geste de glissement doit également répondre à des appuis sur des points spécifiques ou fournir des boutons d’incrément/décrément. Le critère ne s’applique pas si le système d’exploitation sous-jacent ou la technologie d’assistance fournit automatiquement l’alternative, mais les développeurs doivent le tester explicitement plutôt que de supposer que ce sera toujours pris en charge pour eux.

2.4.11 Focus Not Obscured — Minimum (Niveau AA) et 2.4.12 (Renforcé, Niveau AAA)

Ces critères traitent d’un schéma extrêmement courant dans les applications web et mobiles natives : l’élément focalisé étant partiellement ou totalement masqué par une interface fixe — une barre de navigation inférieure persistante, un bouton d’action flottant, une barre d’outils supérieure qui chevauche la zone de défilement. Le critère minimal (Niveau AA) exige que lorsqu’un composant reçoit le focus, au moins une partie de celui-ci reste visible. La version renforcée (Niveau AAA) exige que l’intégralité du composant focalisé soit visible.

Pour le mobile natif, le « focus clavier » est interprété au sens large pour inclure l’anneau de focus utilisé par Switch Control ou Switch Access, Full Keyboard Access (iOS 15+), et Voice Control/Access. Une application où l’élément focalisé glisse sous une barre de navigation inférieure lors d’un balayage Switch Control ne respecte pas ce critère, même s’il n’y a pas de clavier physique en jeu. L’interface de l’application doit éviter de masquer les contrôles focalisés avec des superpositions créées par l’auteur, des barres fixes ou des surfaces transitoires.

2.4.13 Focus Appearance (Niveau AA)

Ce critère définit des exigences minimales pour les caractéristiques visuelles de l’indicateur de focus : il doit avoir une surface minimale équivalente au périmètre du composant × 2 pixels CSS, et un ratio de contraste d’au moins 3:1 par rapport aux couleurs adjacentes. Sur les plateformes mobiles natives, l’anneau de focus pour VoiceOver et TalkBack est contrôlé par le système d’exploitation, et les développeurs ne peuvent pas en modifier l’apparence — ce qui signifie qu’ils bénéficient généralement d’une exception pour ce critère spécifique. Cependant, le style de l’application ne doit pas réduire activement la visibilité du focus, par exemple en superposant un voile translucide sur les contrôles focalisés.

3.3.8 Accessible Authentication — Minimum (Niveau A)

Ce critère représente une avancée majeure pour l’accessibilité cognitive. Il exige que les processus d’authentification ne reposent pas uniquement sur un test de fonction cognitive — c’est-à-dire que l’utilisateur ne doit pas être obligé de mémoriser un mot de passe, de résoudre un puzzle ou de retranscrire un CAPTCHA — à moins que l’application ne fournisse une alternative accessible. Sur iOS, cela signifie prendre en charge le trousseau Apple et Sign in with Apple pour permettre aux utilisateurs de s’authentifier sans mémoriser leurs identifiants. Sur Android, cela signifie prendre en charge le framework Autofill de Google, l’authentification biométrique et ne pas bloquer l’utilisation de gestionnaires de mots de passe tiers.

Plus concrètement : si votre application bloque les actions de collage dans les champs de mot de passe, elle est probablement non conforme au critère 3.3.8. Si votre flux d’authentification à deux facteurs exige que l’utilisateur saisisse manuellement un code OTP à partir d’une notification sans fournir de mécanisme de copier-coller, il introduit une charge cognitive inutile. L’application Messages d’Android propose déjà un bouton « copier le code » dans les notifications OTP précisément pour cette raison — alignant le comportement de la plateforme avec l’intention du critère.

Idée clé : Prendre en charge l’authentification biométrique (Face ID, Touch ID, Android Biometric API) n’est pas seulement une amélioration UX — c’est un mécanisme de conformité à WCAG 2.2 pour les utilisateurs ayant des handicaps cognitifs qui ne peuvent pas se souvenir de leurs mots de passe de manière fiable.

3.3.7 Redundant Entry (Niveau A)

Si un parcours multi-écrans dans votre application — paiement, onboarding, formulaire d’admission médicale — demande à l’utilisateur de saisir plusieurs fois la même information, vous devez soit préremplir la valeur déjà saisie, soit offrir un moyen de la sélectionner à partir des entrées précédentes. Ce critère s’applique directement aux applications mobiles natives. Le cas classique de non-conformité est un formulaire d’adresse de livraison qui demande ensuite une adresse de facturation sans option « identique à l’adresse de livraison », obligeant les utilisateurs ayant des limitations motrices ou des handicaps cognitifs à retaper plusieurs fois le même texte.

3.2.6 Consistent Help (Niveau A)

Si votre application fournit un mécanisme d’aide — un bouton de chat de support, une icône d’aide, un lien « nous contacter » — il doit apparaître à un emplacement cohérent sur tous les écrans de l’application. Les utilisateurs ayant des handicaps cognitifs s’appuient sur le placement prévisible des mécanismes de navigation et de support. Placer le bouton d’aide dans l’en-tête sur certains écrans et dans la barre d’onglets sur d’autres, ou le cacher dans un menu de paramètres dans certains parcours, viole ce critère.

Les critères WCAG 2.1 qui restent essentiels pour le mobile

Les nouveaux critères WCAG 2.2 attirent l’essentiel de l’attention, mais plusieurs exigences WCAG 2.1 introduites spécifiquement en pensant au mobile sont encore régulièrement violées dans les applications natives, et les responsables de la conformité ne doivent pas les négliger lors des audits.

1.3.4 Orientation (AA) interdit de verrouiller une application en orientation portrait ou paysage, sauf si cette orientation est essentielle à la fonction du contenu. De nombreuses applications se verrouillent en portrait pendant les parcours d’onboarding ou dans les lecteurs vidéo intégrés sans justification. Cela affecte de manière disproportionnée les utilisateurs dont les appareils sont montés sur un fauteuil roulant et ne peuvent pas être pivotés. 1.4.10 Reflow (AA) exige que le contenu puisse être présenté sans défilement horizontal lorsqu’il est affiché à 320 pixels CSS de large (l’équivalent d’un zoom à 400%), ce qui, en termes mobiles, signifie prendre en charge Dynamic Type et le réglage de la taille du texte du système sans casser la mise en page ni tronquer le contenu.

2.5.1 Pointer Gestures (A) exige que toute fonctionnalité utilisant des gestes multipoints ou basés sur un tracé — un pincement pour zoomer, un balayage à deux doigts — dispose également d’une alternative à un seul pointeur. 2.5.4 Motion Actuation (A) exige que les fonctionnalités déclenchées par le secouement ou l’inclinaison de l’appareil puissent également être actionnées via des contrôles d’interface standard, et que les utilisateurs puissent désactiver les déclencheurs basés sur le mouvement pour éviter les activations accidentelles.

Pour la présentation visuelle, 1.4.3 Contrast Minimum (AA) exige un ratio d’au moins 4.5:1 pour le texte normal et 3:1 pour le texte de grande taille. De nombreuses applications échouent encore ici parce que le texte indicatif dans les champs de saisie, les libellés de boutons désactivés et le texte sur des arrière-plans photographiques sont en dessous du minimum. Les développeurs doivent s’assurer que tous les textes, contrôles et contenus fonctionnent avec Dynamic Type, Bold Text, le mode sombre et les options de contraste au niveau du système sur iOS et Android.

Recommandations de mise en œuvre spécifiques aux plateformes

iOS et SwiftUI / UIKit

Apple fournit un support d’accessibilité natif étendu via l’API UIAccessibility et, dans SwiftUI, via des modificateurs d’accessibilité. Pour la prise en charge de VoiceOver, chaque élément interactif doit avoir un libellé, une indication et une valeur d’accessibilité significatifs. Les contrôles personnalisés qui n’héritent pas des composants UIKit standard doivent adopter explicitement un trait d’accessibilité approprié — .isButton, .isHeader, .isLink — afin que VoiceOver les annonce correctement. L’Accessibility Inspector de Xcode peut aider à mettre en évidence les libellés manquants et les incohérences de traits pendant le développement.

Pour Dynamic Type, les polices système UIFont.preferredFont(forTextStyle:) de UIKit et .font(.body) de SwiftUI se mettent automatiquement à l’échelle en fonction de la taille de texte préférée de l’utilisateur. Les tailles de police codées en dur en points qui n’utilisent pas scaledValue(for:) ne respecteront pas 1.4.4 Resize Text. Pour les tailles de cibles, vous pouvez étendre la zone cliquable d’une petite icône en utilisant contentEdgeInsets dans UIKit ou le modificateur .contentShape() dans SwiftUI sans modifier la présentation visuelle de l’élément.

// SwiftUI : étendre la zone d’appui sans changer la taille visuelle
Image(systemName: 'xmark')
    .frame(width: 20, height: 20)
    .contentShape(Rectangle().size(CGSize(width: 44, height: 44)))
    .accessibilityLabel('Close')
    .accessibilityAddTraits(.isButton)

Android et Jetpack Compose / Views

L’accessibilité sur Android est exposée via l’API AccessibilityNodeInfo, que TalkBack et Switch Access consomment. Dans Jetpack Compose, le bloc Modifier.semantics permet de définir des descriptions de contenu, des rôles, des descriptions d’état et de fusionner les sémantiques descendantes. Pour les interfaces basées sur View, ViewCompat.setAccessibilityDelegate() permet de manipuler par programmation les propriétés d’accessibilité sur n’importe quelle vue.

Pour la taille des cibles tactiles, les recommandations Material Design préconisent un minimum de 48 × 48 dp. Si un composable ou une vue est visuellement plus petit, vous pouvez utiliser Modifier.minimumInteractiveComponentSize() dans Compose (introduit dans Material3) pour imposer automatiquement un minimum de 48 dp, ou envelopper une petite vue dans un TouchDelegate pour étendre sa zone cliquable dans l’ancien système View. Pour la mise à l’échelle du texte, assurez-vous que toutes les tailles de texte sont spécifiées en sp (pixels indépendants de l’échelle), et non en dp, afin qu’elles respectent les préférences de taille de police de l’utilisateur définies dans les paramètres d’affichage d’Android.

// Jetpack Compose : bouton icône accessible avec taille minimale
IconButton(
    onClick = { onClose() },
    modifier = Modifier
        .minimumInteractiveComponentSize() // impose un minimum de 48dp
        .semantics { contentDescription = 'Close dialog' }
) {
    Icon(
        imageVector = Icons.Default.Close,
        contentDescription = null // décrit par le parent
    )
}

Tester votre application par rapport à WCAG 2.2

Tester l’accessibilité mobile nécessite une combinaison d’outils automatisés et de tests manuels avec de vraies technologies d’assistance. Les outils automatisés — notamment axe DevTools Mobile de Deque, Accessibility Scanner de Google pour Android et Accessibility Inspector d’Apple dans Xcode — peuvent détecter les libellés manquants, les contrastes insuffisants et les cibles tactiles en dessous des minimums de la plateforme. Cependant, les outils automatisés ne détectent qu’une fraction des problèmes d’accessibilité réels. Des tests manuels avec VoiceOver sur iOS et TalkBack sur Android sont essentiels pour vérifier l’ordre de lecture, la pertinence des libellés et la gestion logique du focus dans les parcours complexes.

Pour les critères spécifiques à WCAG 2.2, les tests manuels sont particulièrement importants. Pour tester 2.5.8 (Target Size), utilisez votre vrai doigt — pas un curseur de souris dans l’iOS Simulator — pour tenter d’interagir avec de petits contrôles. Pour tester 3.3.8 (Accessible Authentication), vérifiez que votre parcours de connexion autorise le collage dans les champs de mot de passe, prend en charge les gestionnaires de mots de passe (1Password, Bitwarden, trousseau système) et prend en charge l’authentification biométrique. Pour tester 2.4.11 (Focus Not Obscured), naviguez entièrement dans votre application via Switch Control sur iOS ou Switch Access sur Android, et confirmez qu’aucun élément focalisé ne disparaît derrière une barre de navigation, une superposition modale ou un bouton flottant.

Un plan de test d’accessibilité complet doit inclure des tests sur au moins deux appareils physiques — un iPhone et un appareil Android — avec la taille de police par défaut de l’utilisateur et la taille de police maximale du système, avec VoiceOver et TalkBack activés respectivement. Les tests uniquement sur simulateur manqueront les différences de rendu réelles et le comportement des technologies d’assistance.

Envisagez d’intégrer des vérifications d’accessibilité dans votre pipeline CI/CD. Espresso (Android) et XCUITest (iOS) permettent tous deux d’écrire des tests UI automatisés qui vérifient les propriétés d’accessibilité — descriptions de contenu, traits et états activés — afin que les régressions soient détectées avant la fusion du code plutôt que découvertes lors d’un audit en production.

Les arguments juridiques et économiques pour agir maintenant

Au-delà de l’impératif moral d’inclusion, l’argument économique en faveur de l’accessibilité mobile est concret. Les entreprises en pointe sur l’inclusion du handicap génèrent 1.6 fois plus de revenus et 2.6 fois plus de bénéfices nets que leurs pairs sectoriels. Les personnes en situation de handicap aux États-Unis disposent de près d’un demi-billion de dollars de revenu disponible. Et étant donné que 69% des consommateurs en ligne en situation de handicap abandonnent les applications et sites web qu’ils trouvent difficiles à utiliser, chaque barrière d’accessibilité est une conversion qui n’aura jamais lieu.

Le risque juridique s’intensifie. Les actions en justice visant des entreprises présentant des défaillances d’accessibilité numérique continuent de croître d’année en année. L’adoption par le DOJ de WCAG comme standard technique pour la conformité à l’ADA, les échéances d’application du Title II en 2026 et l’entrée en vigueur de l’EAA en juin 2025 créent collectivement une exigence de conformité multi-juridictionnelle qui englobe désormais explicitement les applications mobiles natives. Un audit WCAG 2.1 antérieur ne démontre pas automatiquement la conformité à WCAG 2.2 — les parcours d’authentification, les champs de formulaire, les composants interactifs et la gestion du focus doivent tous être réévalués au regard des neuf nouveaux critères de succès.

De manière critique, l’accessibilité sur mobile n’est pas une fonctionnalité que l’on peut ajouter à moindre coût après le lancement. Corriger des non-conformités WCAG dans une application déjà publiée implique des ressources mises à jour, des composants reconstruits, des mises en page révisées, des parcours retestés et potentiellement des systèmes d’authentification refactorisés. Les équipes qui intègrent la conformité WCAG 2.2 dans leurs design systems et bibliothèques de composants dès le départ — en imposant des tailles minimales de cibles tactiles, des jetons de contraste, des rôles sémantiques et des modèles d’authentification au niveau des composants — paient une fraction du coût par rapport à la remédiation d’une application inaccessible après son lancement.

Points clés à retenir

• WCAG 2.2 s’applique aux applications natives iOS et Android. Les recommandations WCAG2Mobile du W3C font correspondre chaque critère de succès de niveau A et AA aux écrans et vues mobiles, ce qui signifie que votre application native est concernée — pas seulement votre site web mobile.
• La taille des cibles tactiles est la nouvelle cause de non-conformité la plus fréquente dans les audits mobiles. Le minimum de 24 × 24 de WCAG 2.2 est un plancher ; Apple recommande 44 × 44 pt et Google recommande 48 × 48 dp. Étendez les zones cliquables avec des marges internes et des API natives de la plateforme, plutôt qu’en agrandissant visuellement les icônes.
• Bloquer le collage dans les champs de mot de passe viole probablement 3.3.8 Accessible Authentication. Prenez en charge les trousseaux système, les gestionnaires de mots de passe, la biométrie et le remplissage automatique des OTP pour répondre aux exigences d’accessibilité cognitive des parcours de connexion sur les deux plateformes.
• Les tests manuels avec VoiceOver et TalkBack sont incontournables. Les outils automatisés ne détectent qu’une fraction des problèmes d’accessibilité. Testez sur des appareils physiques avec la taille de police maximale, les technologies d’assistance activées, sur chaque parcours utilisateur critique.
• Intégrez l’accessibilité dans votre design system dès maintenant, pas après le lancement. Corriger des applications inaccessibles après leur lancement est bien plus coûteux que faire respecter des standards de composants accessibles dès le premier jour. Avec les échéances d’application du DOJ, du HHS et de l’EAA qui arrivent en 2025–2026, la fenêtre pour un travail de conformité à faible coût se referme.