UI accessibilité mobile : 5 bonnes pratiques peu connues
1. Supporter l’orientation paysage : une nécessité largement sous-estimée
La majorité des applications mobiles sont conçues exclusivement pour une utilisation en mode portrait. Ce choix est souvent dicté par des habitudes de design centrées sur la consommation rapide (réseaux sociaux, messageries, navigation verticale). Pourtant, cette orientation unique peut gravement limiter l’accessibilité pour certains utilisateurs.
Pourquoi le mode paysage pour l’accessibilité mobile ?
Utilisateurs en fauteuil roulant : ceux qui utilisent des tablettes ou smartphones fixés à l’aide de supports (sur accoudoir ou harnais) les placent souvent en mode paysage par contrainte d’espace ou de stabilité. Une app incompatible est alors inutilisable.
Personnes atteintes de tremblements : tenir un appareil en mode portrait peut être plus difficile à stabiliser que le poser en paysage.
Utilisateurs de claviers ou dispositifs d’assistance : en particulier les claviers Bluetooth ou commandes vocales, plus confortables à utiliser lorsque l’écran est en format large.
Malvoyants ou dyspraxiques : en mode paysage, les éléments peuvent être agrandis horizontalement, limitant les scrolls verticaux longs, ce qui réduit la fatigue visuelle ou motrice.
Bonnes pratiques pour bien supporter le mode paysage
✅ Tester chaque écran dans les deux orientations. Une compatibilité partielle (ex. : seul l’écran d’accueil fonctionne) est frustrante.
✅ Adapter le layout : Ne pas simplement « étirer » les éléments, mais repenser la disposition : passage d’un layout en colonne à un layout en grille, regroupement logique d’actions ou d’infos.
✅ Optimiser la lisibilité : Éviter que le texte soit trop étalé en largeur. Limiter la longueur des lignes (50–75 caractères par ligne max) en paysage pour conserver une bonne lisibilité.
✅ Garder les gestes fonctionnels : Vérifiez que les interactions tactiles (swipes, taps) sont toujours intuitives en paysage, notamment si l’app utilise des zones interactives proches des bords.
✅ Informer l’utilisateur : Certaines apps ne préviennent pas l’utilisateur qu’elles ne sont pas compatibles paysage. Il est préférable d’ajouter une alerte élégante, ou mieux, d’assurer la compatibilité.
Ce que dit Apple / Google ?
Apple encourage la prise en charge du paysage, notamment pour les apps iPad, et impose certaines exigences pour les apps à usage éducatif, professionnel ou médical.
Android offre des outils natifs pour détecter les changements d’orientation (onConfigurationChanged) et propose des guidelines pour layout adaptatif dans son Material Design.
L’application Proloquo2Go, destinée aux personnes non verbales, est 100 % utilisable en paysage. Elle permet à l’utilisateur de naviguer par balayage, avec de grandes cibles tactiles et une interface redessinée selon l’orientation. Ce niveau d’accessibilité est cité comme modèle à suivre.
Le support du mode paysage n’est pas un luxe : c’est une exigence de design inclusif. Trop souvent négligée, cette fonctionnalité peut changer radicalement l’expérience d’un utilisateur à besoins spécifiques, et par extension, améliorer le confort de tous.
2. Le Barrier Pointing : tirer parti des bords de l’écran pour améliorer la précision
Le Barrier Pointing consiste à placer des éléments interactifs (boutons, commandes, raccourcis) près des bords physiques de l’écran, où le doigt ou le curseur vient naturellement se heurter à une limite tangible.
Plutôt que d’avoir à viser un petit élément au centre de l’écran, l’utilisateur peut « s’appuyer » sur le bord pour guider son doigt ou son dispositif d’aide (pointeur, stylet, trackball, etc.) avec plus de stabilité.
Pourquoi c’est important en accessibilité mobile ?
✅ Réduction des erreurs de visée : Les personnes atteintes de tremblements (ex. : maladie de Parkinson), de troubles de la coordination (dyspraxie) ou utilisant un stylet monté sur la tête bénéficient de cette stabilité physique.
✅ Améliore l’autonomie : Cela rend possible des actions fréquentes (fermer une fenêtre, valider un champ, accéder au menu) sans nécessiter de contrôle moteur fin.
✅ Favorise le design universel : Même sans handicap, tout utilisateur bénéficie d’une interface plus robuste dans les conditions d’usage réelles : mouvements dans les transports, mains mouillées, etc.
Exemples concrets d’utilisation du Barrier Pointing
Bouton retour placé en bas à gauche sur Android (ou geste « swipe-in » depuis le bord gauche).
Menu de navigation caché (drawer) déclenchable par un geste depuis le bord de l’écran.
Barres d’outils flottantes plaquées sur les côtés (comme dans certaines apps de dessin ou d’édition photo).
Contrôles média (pause/play) sur les côtés pour éviter la recherche visuelle ou motrice fastidieuse.
Bonnes pratiques d’implémentation
Zone généreuse : Les zones de tap doivent mesurer au moins 48 x 48 dp (recommandation WCAG et Google). En bord d’écran, vous pouvez aller au-delà (jusqu’à 70 dp) pour offrir un véritable point d’arrêt.
Effet « tampon » évité : Attention à ne pas ajouter de padding ou de marge qui empêche d’atteindre le bord. Certains OS laissent une zone « morte » par défaut à cause de gestes système (ex : swipe iOS), qu’il faut compenser intelligemment.
Retours visuels : Un feedback clair au toucher est important : highlight, vibration ou animation pour confirmer l’interaction.
Ne surchargez pas les bords : mieux vaut y placer les actions clés et fréquentes, pas tous les contrôles.
Accessibilité par design passif
Le Barrier Pointing est un exemple de « design passif accessible » : l’utilisateur bénéficie d’un gain d’ergonomie sans avoir à activer une option spécifique. C’est ce type d’amélioration que les systèmes d’exploitation intègrent de plus en plus, mais que les designers doivent systématiser dans leurs apps.
Placer des cibles tactiles ou interactives au bord de l’écran permet d’utiliser les limites physiques de l’appareil comme repères moteurs, améliorant considérablement la précision et la vitesse d’exécution des personnes à mobilité réduite — mais aussi l’expérience globale pour tous.
3. Décrire l’état des composants en temps réel
Dans les interfaces mobiles accessibles, il est interessant de rendre l’état actuel des composants UI immédiatement compréhensible – pas uniquement au moment du focus initial, mais chaque fois que l’état évolue. Cela concerne notamment les boutons, interrupteurs, champs de formulaire, menus déroulants, onglets ou encore éléments sélectionnés.
Beaucoup d’utilisateurs n’ont pas de retour visuel fiable (utilisateurs de lecteurs d’écran, de claviers braille ou d’assistance vocale). Pour eux, l’état d’un élément doit être exprimé de manière explicite et dynamique, autrement ils peuvent :
Ignorer qu’une action a fonctionné (ex. : basculer un toggle).
Ne pas savoir si un composant est sélectionné ou non.
Croire qu’un élément est interactif alors qu’il est désactivé.
Exemples fréquents
Commutateurs (toggles) : Doivent indiquer « activé » ou « désactivé » et émettre une notification vocale au changement (ex. : “Wi-Fi activé”).
Onglets ou listes : Le changement de sélection doit être annoncé, par exemple « onglet 2 sur 4, sélectionné : Avis clients ».
Boutons inactifs : S’ils sont grisés, ils doivent être marqués comme disabledet accompagnés d’une aide explicite : “bouton désactivé – veuillez remplir tous les champs”.
Champs d’erreur ou validation : Le retour doit être immédiat, vocalisable, et indiquer précisément ce qui est incorrect ou réussi.
Bonnes pratiques techniques
Utilisez les bons attributs ARIA :
aria-selected="true/false"
aria-checked, aria-pressed, aria-disabled, aria-expanded, etc.
Mais attention : ces attributs sont passifs sans événements associés. Il faut mettre à jour dynamiquement l’attribut à chaque changement d’état.
Émettre un retour via aria-live : Les aria-live regions permettent de notifier automatiquement les lecteurs d’écran d’un changement. Exemple :
<div aria-live="polite">Le Wi-Fi est activé</div>
Favoriser des libellés explicites plutôt que des icônes seules : Une icône de « cœur » remplie ne suffit pas : dites aussi « Ajouté aux favoris ».
Compatibilité mobile : Testez sur TalkBack (Android) et VoiceOver (iOS). Ce que l’utilisateur entend doit être aussi précis que ce qu’un utilisateur voit.
Astuce UX : inclure un retour sonore ou haptique
En complément du feedback vocal, un petit retour haptique (vibration subtile) ou sonore (clic, transition) peut renforcer la perception du changement d’état, même chez les utilisateurs voyants. Cela améliore aussi l’accessibilité cognitive.
Décrire l’état courant d’un composant — et le mettre à jour en temps réel — est essentiel pour l’accessibilité mobile, en particulier pour les personnes aveugles, malvoyantes ou neurodivergentes. C’est ce qui permet de naviguer dans une interface avec confiance, fluidité et précision.
4. Générer automatiquement le texte alternatif des icônes avec des outils intelligents
De nombreuses interfaces mobiles modernes utilisent des icônes seules (sans label textuel) pour des actions clés : favoris, menu, partages, etc. Or, ces icônes sont souvent mal, voire jamais, annotées pour les lecteurs d’écran, ce qui rend l’app inutilisable pour les utilisateurs non voyants.
Un bouton « ❤️ » sans label ne dit rien à VoiceOver. Est-ce un like ? un favori ? une réaction ?
Problème : la rédaction du alt ou aria-label est souvent négligée
Dans les flux de production agiles ou mobiles, l’ajout de texte alternatif passe parfois à la trappe, ou bien est rédigé trop tard, sans cohérence globale, voire sans lien avec le contexte d’usage.
Résultat : des icônes importantes sont muettes pour les technologies d’assistance, ou pire, décrites génériquement (“image”, “icône”), ce qui dégrade fortement l’expérience utilisateur en situation de handicap.
La solution : l’annotation automatique intelligente (ex. ALTICON)
Des outils récents, comme ALTICON (projet du MIT et d’Adobe), proposent une approche innovante :
Utilisation d’intelligence artificielle (machine learning) pour déduire le sens d’une icône en analysant :
La forme (ex. flèche, cœur, panier…)
Le contexte visuel (position, couleurs, interactions autour)
Le code de la fonctionnalité associée (onclick, state…)
Génération automatique d’un texte alternatif pertinent et unique, insérable directement dans le composant via aria-label, alt ou title.
Intégration en phase de développement (Figma plugin, IDE ou CI/CD pipeline), pour éviter les oublis avant mise en production.
Exemples d’annotation générée
Une icône de cloche entourée d’un badge rouge dans une barre de menu devient → aria-label="notifications (2 nouvelles)"
Une icône « ♻️ » dans une app de consommation devient → aria-label="historique des commandes recyclables"
Une icône « + » en haut d’une galerie d’images devient → aria-label="ajouter une nouvelle photo"
Ces suggestions sont sémantiquement riches, bien plus que de simples “ajouter” ou “ouvrir”.
Avantages clés
✅ Gain de temps pour les équipes dev/design
✅ Accessibilité automatisée dès la conception
✅ Réduction du taux d’erreur d’implémentation
✅ Expérience utilisateur renforcée pour les lecteurs d’écran
Bonnes pratiques associées
Toujours revoir manuellement les labels générés automatiquement pour vérifier la clarté et la pertinence métier.
Lorsque possible, préférer une icône + texte visible, mais si cela n’est pas faisable, le texte alternatif devient indispensable.
Tester l’accessibilité via TalkBack (Android) et VoiceOver (iOS) dès la phase de maquettage.
Grâce à des outils comme ALTICON ou à des scripts de vérification IA maison, il est désormais possible de rendre chaque icône mobile accessible dès la phase de développement, sans attendre la QA finale. C’est un levier stratégique pour une UI mobile inclusive, et une des pratiques avancées encore trop peu utilisées dans l’industrie.
5. Exploiter les capacités de dictée vocale comme méthode de navigation
Si la plupart des apps prennent en charge la saisie vocale dans les champs de texte, très peu vont plus loin en intégrant la commande vocale comme outil de navigation ou d’interaction directe dans l’interface.
Pourtant, les utilisateurs souffrant de troubles moteurs sévères, de paralysie, ou de fatigue chronique peuvent difficilement interagir avec les écrans tactiles – même élargis ou adaptés.
Or, Android Voice Access ou iOS Voice Control permettent d’interagir vocalement avec chaque élément d’une app, à condition que ceux-ci soient bien nommés, hiérarchisés et accessibles.
Ce que vous pouvez faire pour tirer parti de la dictée / commande vocale
Structurer sémantiquement tous les composants interactifs
Boutons, champs, liens, sliders…
Tous doivent avoir une étiquette explicite (aria-label, accessibilityLabel, etc.)
Ajouter des « hint labels » spécifiques à la commande vocale
Par exemple sur iOS, vous pouvez ajouter un attribut accessibilityHint pour préciser l’action attendue.
Exemple : "Bouton Envoyer" – « double-cliquez pour envoyer le message »
Adapter les interactions complexes en commandes vocales natives
Un carrousel ou un toggle peuvent être difficiles à utiliser à la voix.
Offrir une version alternative par commande textuelle : « suivant », « voir plus », « ouvrir le menu ».
Déclencher des actions directement via un champ vocal
Exemple : au lieu d’un bouton “Rechercher”, autoriser une commande comme : “Rechercher articles sur le béton armé” → déclenche automatiquement la recherche.
Cas concret
Dans une app de réservation de train :
L’utilisateur peut dire : “Départ Paris demain matin” → et l’app pré-remplit automatiquement les bons champs de recherche.
Ou encore : “Afficher mes billets” → ce qui agit comme un raccourci vocal vers la bonne section.
C’est un gain d’autonomie énorme pour les personnes qui utilisent la voix comme principal mode d’interaction.
Avantages
✅ Plus grande inclusion des utilisateurs à mobilité réduite ✅ Navigation plus rapide pour tous (même sans handicap) ✅ Préparation à l’usage croissant des assistants vocaux (Siri, Google Assistant, Alexa…) ✅ Complément parfait à l’accessibilité tactile et visuelle
L’accessibilité vocale ne se limite pas à remplir un champ par dictée. Elle permet une interface alternative complète, où chaque élément peut être atteint, activé, ou décrit vocalement — à condition d’avoir été bien conçu.
