Chapitre 13.4 — Lecteurs d’écran mobiles

⏱️ TL;DR — Sur mobile, les lecteurs d’écran s’utilisent au doigt, pas au clavier : VoiceOver (iOS) et TalkBack (Android) reposent sur des gestes de balayage pour passer d’un élément à l’autre. Les fondations restent identiques au desktop — HTML sémantique, nom/rôle/valeur — mais l’ergonomie de test change, et certains problèmes n’apparaissent qu’au tactile. Bonne nouvelle : un site bien construit pour NVDA/VoiceOver desktop est déjà à 90 % bon sur mobile ; il faut surtout vérifier au tactile.

🎯 Objectifs

Connaître VoiceOver (iOS) et TalkBack (Android) et leur logique de gestes.
Comprendre ce qui change (et ce qui ne change pas) par rapport au desktop.
Savoir tester un parcours au lecteur d’écran mobile.
Anticiper les problèmes spécifiques au tactile.

Le tactile change l’interaction, pas les fondations

Au clavier, on passe d’un élément à l’autre avec Tab (Partie 4). Sur mobile, il n’y a pas de clavier : le lecteur d’écran s’intercale entre le doigt et l’écran. On explore de deux façons :

Balayage (swipe gauche/droite) : passer à l’élément précédent / suivant dans l’ordre de lecture — l’équivalent de Shift+Tab / Tab, mais pour tous les éléments, pas seulement les interactifs.
Exploration au toucher : poser le doigt sur l’écran pour entendre ce qui s’y trouve.
Double tap : activer l’élément sélectionné (l’équivalent d’Entrée).
Le rotor (VoiceOver) / les menus (TalkBack) : naviguer par titres, landmarks, liens, formulaires — comme les raccourcis desktop.

Ces gestes montrent pourquoi la sémantique est cruciale : le lecteur d’écran mobile s’appuie exactement sur le même arbre d’accessibilité (nom/rôle/valeur) que sur desktop. Un <div> cliquable sera tout aussi muet au doigt qu’à la tabulation.

VoiceOver (iOS) et TalkBack (Android)

VoiceOver (iOS/iPadOS, intégré) : réglages → Accessibilité → VoiceOver. Le rotor (rotation de deux doigts) sélectionne le mode de navigation (titres, liens, etc.).
TalkBack (Android, intégré) : Paramètres → Accessibilité → TalkBack. Les menus contextuels et les gestes de balayage vers le haut/bas changent le granularité de lecture.

Les deux couvrent l’essentiel de l’usage mobile réel. Tester au moins un des deux sur ses parcours clés fait une énorme différence.

♿ Côté utilisateur — Une personne aveugle sur smartphone balaie l’écran de gauche à droite pour « lire » l’interface élément par élément, puis double-tape pour activer. Si tes boutons ne sont pas de vrais boutons, si l’ordre de lecture (DOM) est incohérent, ou si une image informative n’a pas de alt, son parcours devient un labyrinthe. Tout ce que tu as appris pour le desktop la sert directement ici.

Ce qu’il faut vérifier en plus sur mobile

La plupart des critères sont communs, mais certains se révèlent surtout au tactile :

La taille et l’espacement des cibles (13.1) : au doigt, une petite cible est un vrai obstacle.
Les gestes : une action réservée à un swipe ou un pincement doit avoir une alternative (13.2) — d’autant que le lecteur d’écran « capture » certains gestes.
L’ordre de lecture en responsive : quand la mise en page se réorganise en colonne, vérifier que l’ordre du DOM reste logique.
Le focus après une action (ouverture de menu, navigation) : mêmes exigences qu’au desktop, à re-tester au doigt.

💡 Réflexe — Ne considère pas le test mobile comme un chantier séparé : construis proprement (sémantique, alt, ordre DOM, cibles suffisantes) et le mobile suit presque gratuitement. Puis valide au tactile sur un vrai téléphone — c’est le seul moyen de repérer ce qui échappe au desktop.

Tester : la procédure minimale

Activer VoiceOver (iPhone) ou TalkBack (Android).
Sans regarder l’écran si possible, balayer de gauche à droite pour parcourir la page.
Vérifier : chaque élément est annoncé avec un nom correct et un rôle juste ; l’ordre est logique ; les images informatives sont décrites ; les boutons/liens sont activables au double tap ; rien d’important n’est sauté.
Dérouler un parcours réel (s’inscrire, ouvrir un cours) entièrement au lecteur d’écran.

🧭 Sur A11yLearn — On teste le parcours mobile d’A11yLearn « ouvrir un cours et lancer la vidéo » sous VoiceOver et TalkBack. On y découvre deux choses invisibles au desktop : le bouton lecture de la vidéo est trop petit au doigt (on l’agrandit), et le menu de leçon capture un swipe (on ajoute des boutons de navigation explicites). Deux correctifs qui n’apparaissaient qu’au tactile.

✏️ Exercices

Exercice 1 — Desktop OK, mobile KO. Un composant passe le test clavier desktop mais pose problème sous TalkBack. Cite deux causes plausibles.

✅ Solution

(1) Une cible trop petite au doigt (invisible comme problème au clavier). (2) Une action reposant sur un geste (swipe/pincement) sans alternative, que le lecteur d’écran mobile intercepte. Autres possibilités : un ordre de lecture qui se casse dans la mise en page colonne, ou un focus non géré après une action. Le point commun : ces problèmes ne se révèlent qu’au tactile, d’où la nécessité de tester sur un vrai appareil.

Exercice 2 — À quoi sert le rotor ? Explique en une phrase l’intérêt du rotor de VoiceOver pour un utilisateur.

✅ Solution

Le rotor permet de choisir le mode de navigation (par titres, liens, landmarks, éléments de formulaire…) pour parcourir rapidement une page sans tout balayer élément par élément — l’équivalent mobile des raccourcis « aller au titre suivant » du desktop. Il repose sur une bonne structure sémantique : sans titres ni landmarks, il n’a rien à proposer.

🧠 Quiz de révision

1. Comment navigue-t-on avec un lecteur d’écran mobile ?

Au doigt : balayage gauche/droite pour l’élément précédent/suivant, exploration au toucher, double tap pour activer, et le rotor (VoiceOver) / les menus (TalkBack) pour naviguer par titres, liens, landmarks. Pas de clavier physique.

2. Les fondations changent-elles par rapport au desktop ?

Non : le lecteur d’écran mobile s’appuie sur le même arbre d’accessibilité (nom/rôle/valeur). Un HTML sémantique correct sert desktop et mobile. Ce qui change, c’est l’ergonomie d’interaction (gestes) et certains points qui ne se révèlent qu’au tactile.

3. Cite les deux lecteurs d’écran mobiles principaux.

VoiceOver sur iOS/iPadOS (intégré) et TalkBack sur Android (intégré). Tester au moins l’un des deux sur ses parcours clés est très utile.

4. Quels problèmes apparaissent surtout au tactile ?

Les cibles trop petites/rapprochées, les gestes sans alternative, un ordre de lecture cassé en mise en page colonne, et le focus mal géré après une action. Ils échappent souvent au test clavier desktop.

5. Quelle est la procédure minimale de test mobile ?

Activer VoiceOver/TalkBack, balayer toute la page pour vérifier noms, rôles, ordre et images décrites, puis dérouler un parcours réel entièrement au lecteur d’écran sur un vrai appareil.

Chapitre suivant : Mouvement & animation — respecter le mouvement réduit et éviter ce qui peut rendre malade ou déclencher une crise.