Accessibilité — notions de base, VoiceOver et TalkBack pour les utilisateurs aveugles

Qu'est-ce que l'Accessibilité (a11y) dans les applications mobiles ?

Accessibility (abrégé a11y — 11 lettres entre « a » et « y ») — la pratique de développement d'applications utilisables par les personnes ayant des déficiences visuelles, auditives, motrices et cognitives. Dans le développement mobile, l'accessibilité couvre quatre scénarios principaux : les utilisateurs aveugles (lecteurs d'écran), les utilisateurs malvoyants (redimensionnement, contraste), les utilisateurs sourds et malentendants (sous-titres, alternatives visuelles au son) et les utilisateurs à mobilité réduite (commande vocale, Switch Control, grandes zones tactiles).

Exigences légales — dans de nombreux pays, l'accessibilité est légalement obligatoire. États-Unis : Section 508 et ADA. UE : European Accessibility Act (2025). Royaume-Uni : Equality Act 2010. Sans support d'accessibilité, une application peut faire l'objet de poursuites judiciaires — aux États-Unis en 2023, plus de 4 000 poursuites ont été déposées concernant des produits numériques inaccessibles. Apple et Google vérifient l'accessibilité lors de la modération des applications : les App Store Review Guidelines (4.2) et Google Play Store exigent un support minimal d'accessibilité.

Argument commercial — l'accessibilité élargit votre audience. Selon Return on Disability (2021), les personnes handicapées contrôlent 13 billions de dollars de revenus disponibles par an. Les applications accessibles sont également mieux classées dans les recherches (HTML sémantique, textes alternatifs), ont une meilleure évaluation utilisateur et moins d'avis sur les problèmes d'UX. Chez IT Sectr, nous incluons l'accessibilité dans la définition de fait de tous les projets — c'est une norme de qualité, pas une amélioration optionnelle.

Accessibilité sur iOS : VoiceOver et UIAccessibility

VoiceOver — le lecteur d'écran d'Apple intégré à iOS, iPadOS et macOS. L'utilisateur fait glisser son doigt sur l'écran, VoiceOver lit le nom de l'élément sous son doigt. Une double activation active l'élément. VoiceOver prend en charge plus de 40 gestes : balayage à trois doigts (défilement), double tapotement à deux doigts (arrêt), geste en Z (retour). Les développeurs contrôlent ce que VoiceOver lit et comment via le protocole UIAccessibility et les propriétés accessibilityLabel, accessibilityTraits et accessibilityHint.

class CustomButton: UIButton {

    override var isAccessibilityElement: Bool {
        get { return true }
        set {}
    }

    // remplacer accessibilityLabel
    override var accessibilityLabel: String? {
        get { return "Bouton d'envoi du formulaire" }
        set {}
    }

    // remplacer accessibilityHint
    override var accessibilityHint: String? {
        get { return "Double-tapez pour envoyer les données" }
        set {}
    }

    // remplacer accessibilityTraits
    override var accessibilityTraits: UIAccessibilityTraits {
        get { return .button }
        set {}
    }
}

// Dynamic Type — mise à l'échelle du texte
titleLabel.font = UIFontMetrics.default.scaledFont(
    for: UIFont.systemFont(ofSize: 16)
)
titleLabel.adjustsFontForContentSizeCategory = true

Typographie dynamique — Dynamic Type sur iOS permet à l'utilisateur de choisir la taille du texte (de XS à XXXL). Les développeurs utilisent UIFontMetrics.scaledFont pour la mise à l'échelle automatique. Le texte doit s'afficher correctement à toutes les tailles : les lignes ne doivent pas être coupées, les boutons doivent grandir proportionnellement au texte. UITableView met automatiquement à jour la hauteur des cellules lorsque la taille du texte change. Ignorer Dynamic Type rend votre application inaccessible aux utilisateurs malvoyants.

Accessibilité dans SwiftUI

SwiftUI fournit des modificateurs d'accessibilité : .accessibilityLabel(), .accessibilityHint(), .accessibilityAddTraits(), .accessibilitySortPriority(). Par défaut, tous les éléments standard de SwiftUI (Text, Button, Image) sont déjà des éléments d'accessibilité avec des étiquettes automatiques. Pour les vues personnalisées, utilisez .accessibilityElement(children: .combine) pour combiner les éléments enfants en un seul. SwiftUI prend automatiquement en charge Dynamic Type et VoiceOver.

VStack {
    Image(systemName: "trash")
        .accessibilityLabel(Text("Supprimer l'élément"))
    Text("Corbeille")
        .font(.body)
}
.accessibilityElement(children: .combine)
.accessibilityAddTraits(.isButton)
.accessibilityHint(Text("Supprime définitivement l'élément sélectionné"))

Accessibilité sur Android : TalkBack et contentDescription

TalkBack — le lecteur d'écran de Google, préinstallé sur la plupart des appareils Android (disponible sur Google Play pour toutes les versions Android 5+). TalkBack utilise les mêmes gestes que VoiceOver : balayer pour naviguer, double tapotement pour activer. Les développeurs définissent les descriptions des éléments via l'attribut android:contentDescription en XML ou via setContentDescription() dans le code. Pour ImageView, contentDescription est obligatoire — sans lui, TalkBack dit « non étiqueté » ou lit le nom du fichier.

// XML : contentDescription pour ImageView
<ImageView
    android:id="@+id/iconDelete"
    android:src="@drawable/ic_delete"
    android:contentDescription="@string/delete_button_desc"
    android:focusable="true"
    android:clickable="true" />

// Kotlin : affectation programmatique
iconDelete.contentDescription = getString(R.string.delete_button_desc)

// Accessibility Delegate (personnalisé)
iconDelete.accessibilityDelegate = object : View.AccessibilityDelegate() {
    override fun onInitializeAccessibilityNodeInfo(
        host: View, info: AccessibilityNodeInfo
    ) {
        super.onInitializeAccessibilityNodeInfo(host, info)
        info.text = "Bouton supprimer"
        info.contentDescription = "Supprimer l'élément sélectionné"
        info.className = Button::class.java.name
    }
}

// Live Regions pour les mises à jour dynamiques
textView.accessibilityLiveRegion = View.ACCESSIBILITY_LIVE_REGION_POLITE

Live Regions — le mécanisme d'Android pour notifier TalkBack des changements de contenu sans focus. L'attribut android:accessibilityLiveRegion accepte trois valeurs : none (aucune notification), polite (annoncer après l'actuel), assertive (annoncer immédiatement). Utilisez polite pour les mises à jour d'état de chargement, assertive pour les erreurs critiques. Une utilisation excessive d'assertive créera du chaos pour l'utilisateur — TalkBack interrompra constamment l'action en cours.

Accessibility Scanner

Accessibility Scanner — une application gratuite de Google pour tester l'accessibilité des applications Android sans accès au code source. Le scanner vérifie : le contraste du texte, la taille des zones tactiles (minimum 48×48dp selon les Directives d'accessibilité Android), contentDescription pour ImageView et la hiérarchie correcte des éléments. Pour les tests automatisés, utilisez AccessibilityChecks d'Espresso — ils s'intègrent dans le CI/CD et vérifient l'accessibilité à chaque build.

WCAG 2.1 : contraste, taille et zones tactiles

WCAG 2.1 (Web Content Accessibility Guidelines) — la norme internationale d'accessibilité développée par le W3C. La version 2.1 (2018) inclut 13 critères supplémentaires pour les applications mobiles. Niveaux de conformité : A (minimum), AA (obligatoire pour la plupart des organisations), AAA (maximum). Apple et Google recommandent le niveau AA comme minimum pour publier des applications. WCAG 2.2 est sorti en 2023 avec des améliorations pour le focus et la saisie.

Critères clés pour le développement mobile : contraste du texte d'au moins 4.5:1 (AA) ou 7:1 (AAA), taille des zones tactiles d'au moins 44×44pt (iOS) ou 48×48dp (Android), prise en charge des orientations paysage et portrait sans perte de fonctionnalité, possibilité de désactiver les animations (prefers-reduced-motion), sous-titres pour le multimédia et compatibilité avec la commande vocale (Voice Control sur iOS, Voice Access sur Android).

Outils de vérification du contraste — Colour Contrast Analyser (TPGI), WebAIM Contrast Checker, Stark (Figma), Accessibility Inspector (Xcode). Chez IT Sectr, nous vérifions le contraste à l'étape de conception (Figma + Stark) et à nouveau à l'étape de développement (Accessibility Inspector / Accessibility Scanner). L'exigence minimale est de 4.5:1 pour tout texte inférieur à 18pt (14pt gras). Les logos et éléments décoratifs n'ont pas besoin de contraste.

Tests d'accessibilité : outils et liste de vérification

Tests iOS — Accessibility Inspector dans Xcode (Xcode → Open Developer Tool → Accessibility Inspector) vérifie l'étiquette, les traits et l'indice pour chaque élément. VoiceOver peut être activé dans les Réglages ou via le Raccourci d'accessibilité (triple clic sur le bouton). Pour les tests automatisés, utilisez XCUITest avec XCTAssertTrue(app.staticTexts["étiquette"].isAccessibilityElement). Apple recommande de tester tous les écrans de l'application avec VoiceOver activé.

Tests Android — Accessibility Scanner (Play Store) vérifie le contraste, la taille des zones tactiles et contentDescription. Pour l'automatisation : Espresso AccessibilityChecks (import : androidTestImplementation 'androidx.test.espresso:espresso-accessibility:3.5.1'). Google recommande la liste de vérification suivante : chaque ImageView a une contentDescription, les zones tactiles mesurent au moins 48×48dp, le texte s'adapte à 200 % sans coupure et tous les éléments sont accessibles par balayage TalkBack.

Liste de vérification IT Sectr — avant la sortie, nous vérifions : (1) VoiceOver/TalkBack lit correctement tous les éléments, (2) le texte s'adapte à la taille maximale sans perte de fonctionnalité, (3) tous les ImageViews ont une contentDescription, (4) le contraste du texte est ≥4.5:1 dans tous les thèmes, (5) les zones tactiles sont ≥44pt/48dp, (6) aucun menu contextuel accessible uniquement par appui long, (7) prise en charge de Reduce Motion / Remove Animations dans les réglages système. Cette liste de vérification fait partie de la définition de fait de chaque sprint.