Screen Reader : qu'est-ce que c'est, types de lecteurs d'écran et principe de fonctionnement

Qu'est-ce qu'un Screen Reader ?

Le Screen Reader (lecteur d'écran) est une technologie d'assistance (Assistive Technology, AT) qui interprète l'interface utilisateur graphique et la présente sous forme non visuelle : par synthèse vocale ou un afficheur Braille tactile. Les lecteurs d'écran sont le principal moyen d'accès aux ordinateurs et appareils mobiles pour les personnes ayant une perte de vision totale ou partielle.

Les premiers lecteurs d'écran sont apparus à la fin des années 1980 pour MS-DOS (par exemple, Vocal-Eyes) et plus tard pour Windows (JAWS, NVDA). Sur les plateformes mobiles, les lecteurs d'écran ont été intégrés au niveau système : Apple a intégré VoiceOver dans l'iPhone 3GS en 2009, Google a intégré TalkBack dans Android 1.6 la même année. En 2025, pratiquement tous les smartphones modernes disposent d'un lecteur d'écran intégré ne nécessitant aucune installation de logiciel supplémentaire.

Un lecteur d'écran ne se contente pas de lire le texte à l'écran — il analyse la hiérarchie de l'interface, détermine les types d'éléments (bouton, lien, en-tête, champ de saisie), leurs états (activé/désactivé, sélectionné/non sélectionné) et les relations (parent-enfant, groupe). Ces informations sont transmises à l'utilisateur par des invites vocales ou des sensations tactiles d'un afficheur Braille qui met à jour les cellules en temps réel en fonction de la position du focus.

Comment fonctionne un Screen Reader ?

Un lecteur d'écran travaille en étroite collaboration avec le système d'exploitation, en accédant à sa représentation interne de l'interface — l'arbre d'accessibilité (Accessibility Tree). Ce mécanisme est le même sur iOS et Android, bien que les noms d'API diffèrent.

Synthèse vocale (TTS)

Le principal canal de sortie d'un lecteur d'écran est un synthétiseur vocal (Text-To-Speech, TTS). Lorsque le focus d'accessibilité se pose sur un élément, le lecteur d'écran extrait son contenu textuel (ou la description fournie par le développeur) et l'envoie au moteur TTS. Les moteurs TTS modernes, tels que Apple Speech Synthesis et Google Text-to-Speech, utilisent des réseaux neuronaux pour générer une parole naturelle avec une intonation, des pauses et un accent corrects selon la ponctuation et le type de contenu.

L'utilisateur peut régler la vitesse de la parole (généralement 60 à 80 % du maximum pour une perception confortable), la hauteur tonale et le volume. Certains lecteurs d'écran prennent en charge plusieurs voix et basculent entre elles selon le type de contenu — par exemple, une voix plus lente pour lire le texte et une voix plus rapide pour la navigation dans l'interface. Les afficheurs Braille se connectent via Bluetooth et affichent jusqu'à 40 à 80 caractères à la fois, mettant à jour la ligne à chaque changement de focus.

Gestion du focus et navigation

Un lecteur d'écran utilise le concept de Focus d'Accessibilité (Accessibility Focus), qui diffère du focus de saisie standard. L'utilisateur déplace le focus d'accessibilité à l'aide de gestes (toucher, balayage), et le lecteur d'écran annonce l'élément sous le focus. L'ordre de navigation par défaut suit l'ordre visuel : de gauche à droite, de haut en bas. Le développeur peut remplacer cet ordre pour les mises en page complexes.

Le lecteur d'écran prend également en charge différents modes de navigation que l'utilisateur change via le rotor (VoiceOver) ou le menu (TalkBack) : par en-têtes, liens, caractères, mots, formulaires. En mode en-têtes, le lecteur d'écran se déplace uniquement entre H1–H6 — ceci est essentiel pour une navigation efficace dans les longues pages et documents. Le mode caractères aide lors de la saisie de codes de confirmation ou de mots de passe complexes, en prononçant chaque caractère individuellement.

Principaux lecteurs d'écran pour plateformes mobiles

Deux lecteurs d'écran dominent les plateformes mobiles : VoiceOver sur iOS et TalkBack sur Android. Ils ont des API, des gestes et des capacités différents, mais le principe commun est la lecture de l'arbre d'accessibilité et le contrôle gestuel.

VoiceOver (iOS)

VoiceOver est le lecteur d'écran d'Apple, intégré dans iOS, iPadOS et macOS. Il utilise l'API UIAccessibility pour obtenir des informations sur les éléments et prend en charge le rotor pour changer les modes de navigation. VoiceOver est intégré à iCloud (les paramètres se synchronisent entre les appareils), Apple Pay (confirmation de paiement via Touch ID ou Face ID) et le texte dynamique (la police s'adapte aux réglages de l'utilisateur).

Les gestes de VoiceOver diffèrent de ceux de TalkBack : il utilise la rotation à deux doigts (rotor), le triple tap pour Screen Curtain et le double tap à deux doigts pour annuler une action. VoiceOver prend en charge les rotors personnalisés que le développeur ajoute via UIAccessibilityCustomRotor — par exemple, pour une navigation rapide dans les sections de l'application en contournant l'ordre standard.

TalkBack (Android)

TalkBack est le lecteur d'écran de Google, faisant partie d'Android Accessibility Suite. Il utilise AccessibilityService et AccessibilityNodeInfo pour accéder à l'interface. TalkBack prend en charge un menu global via un balayage en forme de L, des actions personnalisées pour les éléments et LiveRegion pour les mises à jour dynamiques. À partir d'Android 14, TalkBack a bénéficié d'une prise en charge des gestes à une main et d'une meilleure intégration avec Google Assistant.

TalkBack dispose d'un système gestuel plus flexible que VoiceOver : l'utilisateur peut attribuer pratiquement n'importe quel geste à n'importe quelle action. TalkBack prend également en charge la saisie Braille à l'écran (BrailleBack) — l'utilisateur saisit du texte avec des caractères Braille directement sur l'écran tactile dans une disposition spéciale de 3×2 par doigt, ce qui accélère considérablement la saisie de texte par rapport au clavier à l'écran.

Outre VoiceOver et TalkBack, il existe des lecteurs d'écran mobiles moins courants : Select to Speak (Android, vocalise la zone sélectionnée), Samsung Voice Assistant (remplace TalkBack sur les appareils Samsung avec One UI) et des solutions tierces pour des niches spécifiques — par exemple, pour les utilisateurs de smartphones chinois sans services Google.

Comment un Screen Reader interagit avec l'application

Un lecteur d'écran n'a pas d'accès direct aux composants d'interface de l'application. Il fonctionne plutôt via une couche — l'API d'accessibilité du système d'exploitation. Le système d'exploitation construit un arbre d'accessibilité (Accessibility Tree) que le lecteur d'écran parcourt et analyse.

Arbre d'accessibilité sur iOS et Android

Sur iOS, l'arbre d'accessibilité est construit à partir d'objets UIAccessibilityElement correspondant à chaque Vue à l'écran. Chaque élément contient un label (texte principal), des traits (type d'élément : bouton, en-tête, lien), un hint (info-bulle), une value (valeur actuelle pour les curseurs et indicateurs) et un frame (zone tactile). Le système crée automatiquement des éléments pour les composants d'interface standard, mais le développeur peut les ajouter et les personnaliser.

Sur Android, l'arbre d'accessibilité est construit à partir d'objets AccessibilityNodeInfo. Chaque nœud contient : text (texte ou contentDescription), className (type d'élément), contentDescription (description), stateDescription (état), isEnabled, isChecked, isClickable et d'autres indicateurs. Android prend également en charge AccessibilityAction — une liste d'actions que le lecteur d'écran peut effectuer au nom de l'utilisateur : clic, appui long, défilement, définir le focus, définir le texte.

Événements d'accessibilité

Lorsqu'un changement se produit dans l'interface (un nouvel élément apparaît, le texte change, un élément devient visible ou invisible), le système d'exploitation envoie un AccessibilityEvent. Le lecteur d'écran s'abonne à ces événements et y réagit : par exemple, lorsqu'une boîte de dialogue apparaît, le lecteur d'écran déplace automatiquement le focus sur son titre et annonce le contenu.

// Écoute des événements d'accessibilité sur Android
class CustomAccessibilityService : AccessibilityService() {
    override fun onAccessibilityEvent(event: AccessibilityEvent?) {
        event ?: return
        when (event.eventType) {
            TYPE_VIEW_CLICKED ->
                handleClick(event)
            TYPE_WINDOW_STATE_CHANGED ->
                handleWindowChange(event)
            TYPE_VIEW_TEXT_CHANGED ->
                handleTextChange(event)
        }
    }
}

Sur iOS, des événements similaires sont traités via UIAccessibility.Notification : layoutChanged (la mise en page a changé), screenChanged (écran complètement nouveau), announcement (annonce personnalisée), pageScrolled (défilement de page). Le développeur envoie ces événements via UIAccessibility.post pour que le lecteur d'écran réponde correctement aux changements. Par exemple, lors de l'ouverture d'une fenêtre modale, il faut envoyer screenChanged avec le nouveau titre — sinon VoiceOver reste sur l'élément précédent sous la fenêtre.

Développement d'applications pour Screen Reader

Créer une application accessible ne consiste pas à ajouter contentDescription à chaque élément — il s'agit de concevoir l'expérience utilisateur pour une interaction non visuelle. Les règles de base sont les mêmes pour les deux plateformes, bien que l'implémentation varie.

Règles d'accessibilité de base

Tous les éléments interactifs doivent avoir une description significative : un bouton « Envoyer » doit être décrit comme « Envoyer le message », pas seulement « Bouton ». Les éléments décoratifs (séparateurs, images d'arrière-plan, icônes non fonctionnelles) doivent être masqués du lecteur d'écran. L'ordre de navigation doit suivre le flux logique de l'écran, pas la disposition visuelle. Le contraste du texte doit être d'au moins 4.5:1 pour le texte normal et 3:1 pour le texte grand (WCAG AA).

// iOS : configuration correcte pour un élément complexe
let customControl = UIControl()
customControl.isAccessibilityElement = true
customControl.accessibilityLabel = "Volume sonore"
customControl.accessibilityValue = "75 pour cent"
customControl.accessibilityTraits = [
    .adjustable,
    .button
]
customControl.accessibilityHint =
    "Augmente ou diminue le volume"

// Mise à jour lors du changement de valeur
func didChangeVolume(newValue: Float) {
    customControl.accessibilityValue =
        "\(Int(newValue)) pour cent"
    UIAccessibility.post(
        notification: .layoutChanged,
        argument: customControl
    )
}

Sur iOS, le flag isAccessibilityElement active la prise en charge de VoiceOver pour les éléments personnalisés. La combinaison de traits (.adjustable + .button) indique à VoiceOver que l'élément peut être ajusté en balayant vers le haut/bas et activé par double tap. Après avoir modifié la valeur, une notification layoutChanged doit être envoyée — sinon VoiceOver continue d'annoncer l'ancienne valeur.

Recommandations spécifiques à chaque plateforme

Pour iOS : utilisez accessibilityElements pour remplacer l'ordre de lecture, accessibilityCustomActions pour des actions supplémentaires dans le menu contextuel et shouldGroupAccessibilityChildren pour regrouper les éléments en groupes logiques. Pour SwiftUI, utilisez les modificateurs .accessibilityLabel(), .accessibilityAddTraits() et .accessibilityRespondsToUserInteraction(). Évitez de définir isAccessibilityElement = false sur les conteneurs contenant des éléments enfants interactifs — cela les masquera de VoiceOver.

Pour Android : utilisez accessibilityTraversalBefore et accessibilityTraversalAfter pour l'ordre de navigation, AccessibilityDelegate pour les éléments personnalisés et LiveRegion (polite/assertive) pour les mises à jour dynamiques. Dans Compose, utilisez le modificateur .semantics {} avec contentDescription, stateDescription et customActions. Évitez de définir focusable = true sur les éléments non interactifs — cela crée de faux points de focus pour TalkBack et déroute l'utilisateur.

Outils de test

Les tests avec un lecteur d'écran doivent être effectués sur un appareil physique. Un émulateur/simulateur fournit une compréhension de base, mais les gestes et la vitesse de réponse diffèrent. Utilisez l'Accessibility Inspector (Xcode) pour iOS et Accessibility Scanner (Android) pour la détection automatique des problèmes.

Scénarios de test clés : inscription (remplissage d'un formulaire, validation, soumission), recherche et navigation dans le catalogue, paiement, récupération de mot de passe. Chaque scénario doit pouvoir être réalisé sans contrôle visuel — uniquement via les invites vocales du lecteur d'écran. Si un utilisateur de lecteur d'écran ne peut pas terminer un scénario dans le même temps qu'un utilisateur normal (±50 %), l'application nécessite des améliorations d'accessibilité.