L'accessibilité comme plateforme : Personal Voice, Live Speech, Eye Tracking, Music Haptics

Personal Voice (iOS 17), Live Speech (iOS 17), Eye Tracking (iOS 18), Music Haptics (iOS 18), Vocal Shortcuts (iOS 18). L’arc des récentes versions d’accessibilité d’Apple est cohérent : des fonctionnalités qui nécessitaient autrefois des applications tierces, du matériel dédié ou des intégrations spécialisées deviennent des capacités de plateforme gérées par l’OS. Le résultat : moins d’applications à installer pour l’utilisateur et un modèle de participation différent pour le développeur. Au lieu de construire la fonctionnalité, le développeur opte soit pour une surface système (autorisation Personal Voice), soit pour le respect des standards que toute application devrait déjà satisfaire (étiquettes d’accessibilité appropriées et cibles tactiles pour Eye Tracking).

Cet article parcourt la surface développeur de chaque fonctionnalité. Le cadre est « que doit faire mon application pour participer » plutôt que « comment implémenter cette fonctionnalité ». Apple a construit la fonctionnalité ; la question est de savoir si l’application est prête à l’utiliser.

TL;DR

• Personal Voice (iOS 17+) permet à un utilisateur d’enregistrer 15 minutes d’audio pour créer une voix synthétisée sur l’appareil destinée aux applications de CAA et de communication assistée. Les applications s’intègrent via AVSpeechSynthesizer.requestPersonalVoiceAuthorization() et vérifient voiceTraits pour .isPersonalVoice¹.
• Live Speech (iOS 17+) est une fonctionnalité système : l’utilisateur tape du texte et l’appareil le prononce (éventuellement avec sa Personal Voice). Les applications n’intègrent pas Live Speech directement ; la fonctionnalité opère au niveau de l’OS pour les appels, FaceTime et les conversations en personne.
• Eye Tracking (iOS 18+) contrôle l’appareil via le regard et le Dwell Control grâce à la caméra frontale. Les applications participent en suivant les standards d’accessibilité (étiquettes d’accessibilité appropriées, dimensionnement des cibles tactiles, ordre de focus) ; aucune API dédiée n’est requise pour la plupart des applications².
• Music Haptics (iOS 18+) traduit la lecture musicale en vibrations du Taptic Engine synchronisées à l’audio via l’API MAMusicHapticsManager dans MediaAccessibility.framework. Toute application musicale peut s’intégrer en définissant MusicHapticsSupported dans Info.plist, en devenant l’application Now Playing active et en fournissant un ISRC³.
• Vocal Shortcuts (iOS 18+) permettent aux utilisateurs d’attribuer des phrases personnalisées pour déclencher des Siri Shortcuts, y compris des actions AppIntent tierces. La fonctionnalité se conjugue avec l’adoption d’App Intents (couverte dans App Intents Are Apple’s New API to Your App).

Personal Voice : le pattern d’autorisation

Personal Voice est la fonctionnalité d’accessibilité avec la surface développeur la plus directe¹. L’utilisateur opte via Réglages > Accessibilité > Personal Voice, enregistre environ 15 minutes d’audio en lisant des invites randomisées, et l’appareil génère une voix synthétisée localement à l’aide de l’apprentissage automatique sur l’appareil. La voix est privée à l’utilisateur ; elle ne quitte pas l’appareil sauf si l’utilisateur la partage explicitement avec des appareils couplés via iCloud.

Pour qu’une application utilise la Personal Voice de l’utilisateur dans AVSpeechSynthesizer, elle doit :

1. Demander l’autorisation via AVSpeechSynthesizer.requestPersonalVoiceAuthorization(completionHandler:).
2. Attendre que l’utilisateur accorde la permission via l’invite système.
3. En cas d’approbation, interroger AVSpeechSynthesisVoice.speechVoices() et filtrer les voix dont voiceTraits contient .isPersonalVoice.
4. Utiliser l’AVSpeechSynthesisVoice résultante comme n’importe quelle autre voix dans AVSpeechUtterance.

import AVFoundation

AVSpeechSynthesizer.requestPersonalVoiceAuthorization { status in
    guard status == .authorized else { return }

    let personalVoices = AVSpeechSynthesisVoice.speechVoices().filter { voice in
        voice.voiceTraits.contains(.isPersonalVoice)
    }

    if let voice = personalVoices.first {
        let utterance = AVSpeechUtterance(string: "Hello.")
        utterance.voice = voice
        synthesizer.speak(utterance)
    }
}

L’autorisation est sensible. Les recommandations d’Apple précisent que Personal Voice doit principalement servir les applications de communication améliorée et alternative (CAA) et autres contextes d’assistance similaires. Une application de synthèse vocale à usage général demandant l’autorisation Personal Voice sera probablement refusée par les utilisateurs et pourrait faire l’objet d’un examen approfondi par l’App Store.

L’architecture « appareil d’abord » a son importance ici. Les données d’entraînement vocal de l’utilisateur et le modèle vocal résultant ne quittent jamais la zone sécurisée de l’appareil, sauf si l’utilisateur opte explicitement pour le partage iCloud. Les étiquettes nutritionnelles de confidentialité de l’App Store pour les applications utilisant Personal Voice devraient refléter une collecte de données nulle, puisque la synthèse se produit localement et que la sortie audio va vers le haut-parleur, et non vers le réseau.

Live Speech : la fonctionnalité système sans intégration

Live Speech est le pendant grand public de Personal Voice⁴. L’utilisateur tape du texte, l’appareil le prononce, éventuellement à l’aide de sa Personal Voice. Live Speech fonctionne pendant les appels téléphoniques, les appels FaceTime, Mac SharePlay et les conversations en personne via le haut-parleur de l’appareil.

Les applications n’intègrent pas Live Speech directement. La fonctionnalité opère au niveau de l’OS, interceptant le texte saisi depuis l’interface système Live Speech et le routant à travers la pile audio. Du point de vue d’une application, Live Speech est invisible : le flux audio qui passe par l’appel (ou qui est joué depuis le haut-parleur de l’appareil pour un usage en personne) ressemble à l’utilisateur, mais aucun code d’application n’est impliqué.

L’implication pour les développeurs d’applications : si votre application gère la voix (une application d’appel, une application de chat vidéo, un assistant d’accessibilité), le pipeline audio de l’application doit respecter le routage audio système afin que Live Speech puisse émettre par le même canal. Les applications qui combattent la session audio (en revendiquant un contrôle exclusif sans considération pour les sons superposés au niveau système) cassent Live Speech.

Eye Tracking : la fonctionnalité qui suit les standards

Eye Tracking, introduit dans iOS 18, permet aux utilisateurs de contrôler iPhone et iPad via la direction du regard plus le Dwell Control². L’utilisateur calibre la caméra frontale en quelques secondes, puis navigue dans l’interface en regardant les éléments ; maintenir le regard sur un élément pendant le délai de Dwell configuré l’active (tap, balayage ou autres gestes, configurables dans Switch Control).

L’implémentation se fait sur l’appareil. La caméra frontale traite les données du regard via l’apprentissage automatique sur l’appareil ; les données ne quittent pas l’appareil. Aucun matériel supplémentaire n’est requis.

Pour la plupart des applications, prendre en charge Eye Tracking ne nécessite pas de code dédié. La fonctionnalité fonctionne avec toute interface qui suit les conventions d’accessibilité standard :

• Cibles tactiles appropriées. Les Apple Human Interface Guidelines spécifient des cibles tactiles minimales de 44pt par 44pt pour les éléments tactiles. Eye Tracking respecte cela. Les boutons plus petits que le minimum sont plus difficiles à cibler avec précision via le dwell.
• Étiquettes d’accessibilité. Chaque élément interactif doit avoir un accessibilityLabel utile (SwiftUI) ou une propriété accessibilityLabel (UIKit). Eye Tracking affiche l’étiquette comme l’équivalent d’une infobulle lorsque l’utilisateur fixe son regard près de l’élément.
• Ordre de focus logique. La touche Tab sur Mac et le moteur de focus sur tvOS exposent le même ordre de focus qu’Eye Tracking utilise pour passer entre les éléments. Les applications qui utilisent les primitives de mise en page standard de SwiftUI obtiennent cela gratuitement ; les applications qui surchargent le comportement de focus doivent vérifier.
• Patterns modaux compatibles avec le dwell. Une modale qui se ferme automatiquement lors d’un tap à l’extérieur peut frustrer les utilisateurs d’Eye Tracking dont le point de fixation peut brièvement quitter la zone modale. Les applications avec interface modale doivent fournir des boutons de fermeture explicites.

Les applications qui souhaitent désactiver Eye Tracking pour des vues spécifiques (contenu sensible, jeux complexes basés sur des gestes) ne disposent pas d’une API d’opt-out documentée spécifiquement pour Eye Tracking. La fonctionnalité opère sur tout contenu visible et la responsabilité de l’application est de garantir que la surface d’accessibilité standard est correcte.

L’article sur Three Surfaces of an iOS App couvre le pattern plus large : l’interface visible est une surface, App Intents en est une autre, l’accessibilité est la troisième. Eye Tracking participe à la surface UI visible ; bien construire cette surface est ce qui permet à Eye Tracking, Switch Control, VoiceOver et Voice Control de fonctionner simultanément.

Music Haptics : le pont audio-haptique

Music Haptics traduit la lecture musicale en vibrations du Taptic Engine synchronisées à l’audio³. La fonctionnalité est opt-in par utilisateur (Réglages > Accessibilité > Music Haptics) et fonctionne pour toute application musicale qui intègre l’API correctement, pas seulement Apple Music.

La surface développeur réside dans MAMusicHapticsManager de MediaAccessibility.framework (iOS 18+). Une application musicale intègre Music Haptics en trois étapes :

1. Déclarer la prise en charge dans Info.plist. Ajoutez la clé MusicHapticsSupported avec la valeur YES. Le système l’utilise pour savoir si l’application participe au rendu Music Haptics.
2. Devenir l’application Now Playing active. L’application doit publier les métadonnées de lecture via MPNowPlayingInfoCenter.default().nowPlayingInfo et posséder la session audio Now Playing. Le système a besoin d’une source Now Playing active connue pour piloter la synthèse haptique.
3. Fournir un ISRC pour la piste en lecture. La clé MPNowPlayingInfoPropertyInternationalStandardRecordingCode (l’International Standard Recording Code) permet au système de rechercher la piste haptique qui se couple avec l’audio. Apple maintient une bibliothèque d’actifs haptiques indexée par ISRC ; les pistes sans ISRC n’obtiennent pas de retours haptiques, mais le reste de l’intégration Now Playing fonctionne toujours.

import MediaPlayer
import MediaAccessibility

// Info.plist: MusicHapticsSupported = YES (boolean)

let info: [String: Any] = [
    MPMediaItemPropertyTitle: track.title,
    MPMediaItemPropertyArtist: track.artist,
    MPNowPlayingInfoPropertyInternationalStandardRecordingCode: track.isrc,
    // ... other now-playing properties
]
MPNowPlayingInfoCenter.default().nowPlayingInfo = info

L’intégration s’applique à toute application musicale : un client de streaming construit sur AVAudioEngine, une application de DJ avec des décodeurs personnalisés, une application d’apprentissage musical avec lecture d’échantillons. La contrainte est l’ISRC et le rôle Now Playing actif, et non l’API audio sous-jacente. Les applications qui n’ont pas d’ISRC (musique téléversée par l’utilisateur sans métadonnées, musique générative) n’obtiennent simplement pas de retours haptiques ; le reste de l’intégration de lecture n’est pas affecté.

Pour les applications dans des espaces adjacents (jeux de rythme, visualisations musicales, moteurs d’effets sonores), l’audio n’est pas ce pour quoi Music Haptics est conçu. Ces applications recourent directement à CHHapticEngine avec des patterns haptiques rédigés à la main et synchronisés à leur source audio.

Vocal Shortcuts : où l’accessibilité rencontre App Intents

Vocal Shortcuts permettent aux utilisateurs d’attribuer des phrases vocales personnalisées à des Siri Shortcuts, y compris ceux soutenus par des types AppIntent tiers⁵. Un utilisateur peut configurer « Marker » pour déclencher un AddTodoIntent enregistré par une application de tâches ; dire « Marker » où qu’il soit, sans invoquer la phrase de réveil de Siri, déclenche l’intent.

L’intégration utilise le framework App Intents que le cluster a couvert en profondeur, avec un élément structurel facile à manquer : l’application doit déclarer un AppShortcutsProvider qui expose des entrées AppShortcut avec des phrases explicites. Un AppIntent nu existe dans le système mais n’est invocable que via l’éditeur Shortcuts, où l’utilisateur assemble manuellement un Shortcut. Un AppShortcutsProvider enregistre des shortcuts visibles par le système que l’utilisateur peut immédiatement attribuer à un Vocal Shortcut, au Bouton d’action, à Siri ou à Spotlight.

struct TodoShortcuts: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: AddTodoIntent(),
            phrases: [
                "Add a todo in \(.applicationName)",
                "\(.applicationName) marker"
            ],
            shortTitle: "Add Todo",
            systemImageName: "checkmark.circle"
        )
    }
}

Le tableau de phrases est ce que le système expose à Siri et aux Vocal Shortcuts. Avec le provider en place, l’App Intent est immédiatement éligible à l’activation vocale. Sans lui, l’intent fonctionne via une configuration manuelle dans Shortcuts, mais le chemin est plus long et beaucoup d’utilisateurs ne l’atteignent jamais.

Le pattern se conjugue avec App Intents et App Intents vs MCP Tools. Un App Intent qui gagne sa place dans la surface Apple Intelligence de l’utilisateur, associé à un AppShortcutsProvider qui déclare comment l’utilisateur l’invoque, gagne aussi sa place comme cible Vocal Shortcut. L’argument du cluster selon lequel App Intents est le contrat trans-système pour « ce qu’une application peut faire » s’applique ici : les Vocal Shortcuts sont un autre consommateur de ce même contrat.

Le pattern transversal : les standards sont l’intégration

Les fonctionnalités d’accessibilité ci-dessus partagent une propriété structurelle : chacune est construite sur des standards que les applications devraient déjà satisfaire, avec une petite surface d’API opt-in pour les cas où l’application doit explicitement coopérer (autorisation Personal Voice, Music Haptics via MPMusicPlayerController).

L’implication pour les équipes de développement : le travail d’accessibilité n’est pas un flux de travail séparé effectué après la livraison de l’application. Les étiquettes d’accessibilité, les cibles tactiles, l’ordre de focus et l’utilisation standard des API système de l’application sont ce qui fait fonctionner Eye Tracking, route correctement Live Speech, active Music Haptics et expose les bons intents pour Vocal Shortcuts. Les applications qui traitent l’accessibilité comme une case à cocher en fin de cycle livrent des fonctionnalités qui fonctionnent pour VoiceOver mais pas pour Eye Tracking, ou qui routent l’audio de manières que Live Speech ne peut pas suivre.

L’article What I Refuse to Write About du cluster défend le refus comme un mouvement de positionnement. Les refus en matière d’accessibilité en sont l’inverse : non pas « je refuse d’ajouter ceci », mais « je refuse de livrer quelque chose qui échoue aux standards que toute application iOS devrait déjà satisfaire ».

Quand les applications ont besoin de code d’accessibilité personnalisé

Trois cas où le pattern de respect des standards ne couvre pas tout :

Surfaces de dessin personnalisées. Une application de dessin, un graphique, une interface de jeu rendue de manière personnalisée contournent l’arborescence d’accessibilité SwiftUI/UIKit. L’application doit construire sa propre arborescence d’accessibilité à l’aide de UIAccessibilityCustomAction, UIAccessibilityElement et de propriétés d’accessibilité explicites pour chaque élément significatif. Eye Tracking, VoiceOver et Switch Control reposent tous sur le fait que l’arborescence d’accessibilité est peuplée.

Interactions gestuelles en temps réel. Un jeu avec une entrée gestuelle continue (dessiner, glisser pour viser) ne se prête pas naturellement à une entrée basée sur le dwell ou sur des switches. La bonne approche est de fournir des schémas de contrôle alternatifs (entrée par boutons en option) plutôt que de combattre le système d’accessibilité.

Fonctionnalités spécifiques à l’accessibilité. Applications de CAA, applications d’augmentation vocale, applications d’interprétation en langue des signes. Ces applications sont des produits d’accessibilité à part entière et s’intègrent profondément aux frameworks système (Personal Voice, framework Speech, framework Vision pour la détection de la langue des signes). Le travail d’intégration est réel et intentionnel.

Ce que ce pattern signifie pour les applications iOS 26+

Trois enseignements.

1. La participation à l’accessibilité consiste principalement à suivre les standards, pas à construire des fonctionnalités. Apple a déplacé l’accessibilité vers la couche plateforme. Le travail consiste à s’assurer que votre application respecte les standards sur lesquels Eye Tracking, Switch Control, VoiceOver et Voice Control reposent tous : étiquettes appropriées, cibles tactiles, ordre de focus, routage audio système.

2. L’intégration de Personal Voice est sensible. Si votre application a un véritable cas d’usage CAA (communication assistée, augmentation vocale, outillage d’accessibilité), l’autorisation Personal Voice est la bonne intégration. Pour les applications à usage général, demander l’autorisation Personal Voice risque davantage de dérouter les utilisateurs que de les aider.

3. App Intents est une infrastructure d’accessibilité. Un AppIntent propre est automatiquement éligible aux Vocal Shortcuts, obtient une surface UI accessible via Shortcuts et s’intègre aux modes de contrôle vocaux et basés sur des switches du système. L’argument du cluster en faveur de l’adoption d’App Intents s’applique aussi à l’accessibilité.

Le cluster Apple Ecosystem complet : App Intents typés ; serveurs MCP ; la question du routage ; Foundation Models ; la distinction LLM runtime vs outillage ; trois surfaces ; le pattern source unique de vérité ; Two MCP Servers ; hooks pour le développement Apple ; Live Activities ; le contrat runtime watchOS ; internals SwiftUI ; le modèle mental spatial de RealityKit ; discipline de schéma SwiftData ; patterns Liquid Glass ; livraison multi-plateformes ; la matrice plateforme ; framework Vision ; Symbol Effects ; inférence Core ML ; API Writing Tools ; Swift Testing ; Privacy Manifest ; ce que je refuse d’écrire. Le hub se trouve dans la série Apple Ecosystem. Pour un contexte iOS-avec-agents-IA plus large, voir le guide iOS Agent Development.

FAQ

Dois-je écrire du code pour prendre en charge Eye Tracking ?

Pour la plupart des applications, non. Eye Tracking fonctionne automatiquement avec toute interface qui suit les conventions d’accessibilité standard : cibles tactiles appropriées (44pt minimum), étiquettes d’accessibilité utiles, ordre de focus logique et contrôles système standard. Les applications qui dessinent leur propre interface (vues personnalisées, jeux, graphiques) doivent peupler explicitement l’arborescence d’accessibilité à l’aide de UIAccessibilityElement ou des modificateurs d’accessibilité de SwiftUI ; ce travail est aussi ce qui rend l’application fonctionnelle pour VoiceOver et Switch Control.

Puis-je utiliser Personal Voice dans une application de synthèse vocale à usage général ?

Le système le permet via AVSpeechSynthesizer.requestPersonalVoiceAuthorization(), mais les recommandations d’Apple et le processus d’examen de l’App Store mettent l’accent sur Personal Voice pour les contextes d’assistance (CAA, communication améliorée et alternative). Les applications de synthèse vocale à usage général qui demandent l’autorisation Personal Voice font face à deux défis : les utilisateurs sont peu susceptibles d’accorder l’autorisation, et l’examen peut repousser la demande comme une utilisation inappropriée. Si votre cas d’usage est véritablement assistif, l’intégration est juste ; s’il s’agit d’une narration à usage général, les voix système sont le bon outil.

Quelle est la différence entre Live Speech et Personal Voice ?

Personal Voice est la voix synthétisée sur l’appareil qui ressemble à l’utilisateur. Live Speech est la fonctionnalité système qui permet à l’utilisateur de taper et de faire prononcer le texte par l’appareil (en utilisant soit une voix système, soit sa Personal Voice). Elles sont complémentaires : Personal Voice fournit la voix, Live Speech fournit l’interface frappe-vers-parole. Les applications intègrent Personal Voice via l’API Speech Synthesizer ; Live Speech est invisible pour les applications et opère au niveau de l’OS.

Comment ajouter Music Haptics à une application musicale qui utilise AVAudioEngine ?

Vous le pouvez. Music Haptics n’est pas limité à une API de lecture spécifique. L’intégration consiste à : ajouter MusicHapticsSupported = YES à Info.plist, publier les métadonnées de la piste en lecture via MPNowPlayingInfoCenter.default().nowPlayingInfo (afin que le système reconnaisse votre application comme la source Now Playing active) et inclure MPNowPlayingInfoPropertyInternationalStandardRecordingCode avec l’ISRC de la piste. Le système gère la synthèse haptique à partir de là. Les pistes sans ISRC n’obtiennent pas de retours haptiques, mais le reste de l’intégration Now Playing fonctionne normalement.

Quel est le design d’App Intent qui offre la meilleure expérience Vocal Shortcuts ?

Quatre principes. Premièrement, déclarez un AppShortcutsProvider pour l’application et enregistrez des entrées AppShortcut pour les intents que vous voulez accessibles vocalement. Sans le provider, l’intent n’atteint Vocal Shortcuts que via une édition manuelle dans Shortcuts. Deuxièmement, le title et le shortTitle doivent être de courtes phrases verbales (« Add Todo », « Start Timer ») plutôt que des descriptions. Troisièmement, les paramètres doivent être optionnels ou avoir des valeurs par défaut afin que l’utilisateur puisse invoquer l’intent sans spécifier chaque champ. Quatrièmement, la description doit être une phrase claire unique expliquant l’effet de l’intent ; cela apparaît comme contexte lorsque l’utilisateur choisit une phrase à attribuer.

Références