Accessibilité dans les applications mobiles - Guide complet en pratique

Parler d’accessibilité est facile. Implémenter l’accessibilité dans une application réelle, avec des délais serrés, une dette technique et une conception complexe, est une autre histoire.

Ce guide « pratique » s'adresse aux développeurs mobiles (Android/iOS/Flutter/React Native) et aux concepteurs qui ont besoin de se salir les mains aujourd'hui. Laissons de côté la philosophie et passons directement au workflow d'implémentation.

Le « Kit de survie » d'accessibilité mobile

Avant d’écrire du code, vous avez besoin des bons outils de test. Sans eux, vous programmez dans le noir.

Accessibility Scanner : application Google disponible sur le Play Store. Il prend une capture d'écran de votre écran et vous propose des corrections (augmentation du texte, du contraste, de la zone tactile).
VoiceOver (iOS) / TalkBack (Android) : Apprenez les gestes de base.
- Faites glisser votre doigt vers la droite : élément suivant.
- Balayez vers la gauche : élément précédent.
- Appuyez deux fois : Activer/Cliquer.
Color Blindness Simulator : Des applications comme « Sim Daltonism » (Mac/iOS) vous permettent de regarder l'écran de votre application comme si vous souffriez de différents types de daltonisme.

Liste de contrôle de mise en œuvre pratique

1. Ordre de mise au point (ordre de déplacement)

Le lecteur d'écran lit l'écran de haut en bas, de gauche à droite (dans les langues occidentales). Mais des mises en page complexes peuvent gâcher tout cela.

Problème : Le lecteur lit le pied de page avant le contenu principal.
Solution pratique :
- Android : utilisez android:accessibilityTraversalBefore et android:accessibilityTraversalAfter pour forcer l'ordre logique si le XML n'est pas dans l'ordre visuel.
- iOS : Ajustez le tableau accessibilityElements dans votre View Controller.

2. Regroupement de contenu (Regroupement)

Imaginez une fiche produit avec : [Photo de baskets] [Nom : Nike Air] [Prix : 500 R$]. Si le lecteur se concentre sur chaque élément séparément, l'utilisateur doit « glisser » 3 fois pour comprendre un seul produit. C'est fatiguant.

Solution pratique : Regroupez le conteneur.
- Flutter : enveloppez le widget de carte dans un Semantics(container: true, label: "Tênis Nike Air, preço 500 reais") et masquez les enfants sémantiques (excludeSemantics). Ainsi, l’accent est mis sur l’ensemble de la carte.

3. Polices dynamiques (type dynamique)

L'utilisateur a augmenté la police dans les paramètres du téléphone portable car il souffre de presbytie (vue fatiguée). Votre application respecte-t-elle cela ou casse-t-elle tout ?

Pratique : Ne définissez jamais la taille des polices en pixels fixes (px).
- Android : utilisez sp (pixels indépendants de l'échelle).
- iOS : utilisez les polices dynamiques (UIFont.preferredFont(forTextStyle: .body)).
- React Native : évitez de limiter numberOfLines={1} dans les textes importants. Laissez le texte s'enrouler si la police augmente.

4. Couleurs et contraste (mode sombre)

L’accessibilité, c’est aussi une question de confort visuel.

Pratique : testez votre application en mode sombre et en mode clair. Un texte gris clair qui est beau sur un fond blanc peut disparaître sur un fond noir si vous n'utilisez pas de couleurs sémantiques du système (par exemple SystemGray sur iOS) au lieu de couleurs hexadécimales codées en dur.

5. Touchez les cibles

Le bouton semble grand, mais seule l'icône de 24 pixels au milieu est cliquable.

Pratique : utilisez les outils « Debug Paint » ou « Afficher les limites de la mise en page » dans les options du développeur Android pour voir la taille réelle de la zone cliquable. S'il est inférieur à 48 dp, augmentez le rembourrage interne du composant.

Flux de développement accessible (DoD)

Pour garantir que l'accessibilité se réalise dans la pratique, incluez ces éléments dans votre « Définition de Terminé » pour chaque tâche :

Tous les éléments interactifs ont-ils des étiquettes ?
Ai-je parcouru l'intégralité de la fonctionnalité en utilisant uniquement le clavier/lecteur d'écran ?
Le contraste des couleurs réussit-il le test WCAG AA ?
Si nous augmentons la police système, la mise en page s'adapte-t-elle (défilement) ou coupe-t-elle le texte ?

Accessibilité dans les WebViews (Attention !)

De nombreuses applications sont hybrides et chargent des pages Web en leur sein.

Le danger : L'accessibilité native du téléphone portable (TalkBack/VoiceOver) ne communique pas toujours bien avec le HTML du WebView s'il n'est pas bien fait.
La pratique : Si vous utilisez WebViews, le site Web chargé DOIT être accessible (HTML sémantique, étiquettes ARIA). L'application native ne peut pas "réparer" comme par magie un mauvais code HTML.

Conclusion

Dans la pratique, l’accessibilité relève moins de l’héroïsme que de l’habitude. Cela crée le réflexe musculaire d'ajouter contentDescription à chaque fois que vous ajoutez ImageView. C'est l'habitude de tester avec TalkBack activé pendant 2 minutes avant d'envoyer la Pull Request.

Les petites actions quotidiennes créent un produit robuste. Commencez dès aujourd'hui, sur l'écran suivant, vous codez.