Acessibilidade como plataforma: 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). O arco dos lançamentos recentes de acessibilidade da Apple é consistente: recursos que antes exigiam apps de terceiros, hardware dedicado ou integrações especializadas estão se tornando capacidades de plataforma que o sistema operacional cuida. O resultado é menos apps para o usuário instalar e um modelo de participação diferente para o desenvolvedor: em vez de construir o recurso, o desenvolvedor ou opta por uma superfície do sistema (autorização do Personal Voice) ou segue os padrões que todo app já deveria atender (rótulos de acessibilidade adequados e alvos de toque para o Eye Tracking).

O post percorre a superfície do desenvolvedor para cada recurso. O enquadramento é “o que meu app precisa fazer para participar” em vez de “como eu implemento esse recurso”. A Apple construiu o recurso; a questão é se o app está pronto para usá-lo.

TL;DR

• Personal Voice (iOS 17+) permite que o usuário grave 15 minutos de áudio para criar uma voz sintetizada no dispositivo para apps de AAC e comunicação assistiva. Os apps integram via AVSpeechSynthesizer.requestPersonalVoiceAuthorization() e verificam voiceTraits para .isPersonalVoice¹.
• Live Speech (iOS 17+) é um recurso do sistema: o usuário digita texto e o dispositivo o fala (opcionalmente com sua Personal Voice). Os apps não integram o Live Speech diretamente; o recurso funciona no nível do sistema operacional em chamadas, FaceTime e comunicação presencial.
• Eye Tracking (iOS 18+) controla o dispositivo via olhar + Dwell Control através da câmera frontal. Os apps participam seguindo padrões de acessibilidade (rótulos de acessibilidade adequados, dimensionamento de alvos de toque, ordem de foco); nenhuma API dedicada é necessária para a maioria dos apps².
• Music Haptics (iOS 18+) traduz a reprodução de música em vibrações do Taptic Engine sincronizadas com o áudio via a API MAMusicHapticsManager em MediaAccessibility.framework. Qualquer app de música pode integrar definindo MusicHapticsSupported no Info.plist, tornando-se o app Now Playing ativo e fornecendo um ISRC³.
• Vocal Shortcuts (iOS 18+) permitem que os usuários atribuam frases personalizadas para acionar Atalhos da Siri, incluindo ações AppIntent de terceiros. O recurso se compõe com a adoção de App Intents (abordada em App Intents Are Apple’s New API to Your App).

Personal Voice: o padrão de autorização

Personal Voice é o recurso de acessibilidade com a superfície de desenvolvedor mais direta¹. O usuário opta em Ajustes > Acessibilidade > Personal Voice, grava cerca de 15 minutos de áudio lendo prompts aleatorizados, e o dispositivo gera uma voz sintetizada localmente usando machine learning no dispositivo. A voz é privada para o usuário; ela não sai do dispositivo a menos que o usuário a compartilhe explicitamente com dispositivos pareados via iCloud.

Para um app usar a Personal Voice do usuário em AVSpeechSynthesizer, ele precisa:

1. Solicitar autorização via AVSpeechSynthesizer.requestPersonalVoiceAuthorization(completionHandler:).
2. Aguardar o usuário conceder permissão através do prompt do sistema.
3. Após aprovação, consultar AVSpeechSynthesisVoice.speechVoices() e filtrar por vozes cujo voiceTraits contenha .isPersonalVoice.
4. Usar o AVSpeechSynthesisVoice resultante como qualquer outra voz em 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)
    }
}

A autorização é sensível. A orientação da Apple é que a Personal Voice deve servir principalmente apps de comunicação aumentativa e alternativa (AAC) e contextos assistivos similares. Um app de voice-over de propósito geral solicitando autorização de Personal Voice provavelmente será negado pelos usuários e pode enfrentar escrutínio na revisão da App Store.

A arquitetura on-device-first importa aqui. Os dados de treinamento de voz do usuário e o modelo de voz resultante nunca saem da área do secure enclave do dispositivo, a menos que o usuário opte explicitamente pelo compartilhamento via iCloud. Os rótulos nutricionais de privacidade da App Store para apps que usam Personal Voice devem refletir zero coleta de dados, já que a síntese acontece localmente e a saída de áudio vai para o alto-falante, não para a rede.

Live Speech: o recurso de sistema sem integração

Live Speech é o pareamento voltado ao consumidor para a Personal Voice⁴. O usuário digita texto, o dispositivo o fala, opcionalmente usando sua Personal Voice. O Live Speech funciona durante chamadas telefônicas, chamadas FaceTime, Mac SharePlay e conversas presenciais através do alto-falante do dispositivo.

Os apps não integram o Live Speech diretamente. O recurso opera no nível do sistema operacional, interceptando o texto digitado da UI do Live Speech do sistema e roteando-o através da pilha de áudio. Da perspectiva de um app, o Live Speech é invisível: o stream de áudio que vem pela chamada (ou que toca pelo alto-falante do dispositivo para uso presencial) soa como o usuário, mas nenhum código do app está envolvido.

A implicação para desenvolvedores de apps: se seu app lida com voz (um app de chamadas, um app de videochamada, um auxiliar de acessibilidade), o pipeline de áudio do app precisa respeitar o roteamento de áudio do sistema para que o Live Speech possa sair pelo mesmo canal. Apps que brigam com a sessão de áudio (reivindicando controle exclusivo sem consideração por sons de overlay no nível do sistema) quebram o Live Speech.

Eye Tracking: o recurso que segue padrões

O Eye Tracking, introduzido no iOS 18, permite que os usuários controlem iPhone e iPad através da direção do olhar mais Dwell Control². O usuário calibra a câmera frontal em alguns segundos, então navega pela UI olhando para os elementos; manter o olhar em um elemento pelo timeout configurado do Dwell o ativa (toque, swipe ou outros gestos, configurável no Switch Control).

A implementação é no dispositivo. A câmera frontal processa os dados do olhar através de machine learning no dispositivo; os dados não saem do dispositivo. Nenhum hardware adicional é necessário.

Para a maioria dos apps, suportar o Eye Tracking não exige código dedicado. O recurso funciona com qualquer UI que siga as convenções padrão de acessibilidade:

• Alvos de toque adequados. As Apple Human Interface Guidelines especificam alvos de toque mínimos de 44pt por 44pt para elementos tocáveis. O Eye Tracking honra isso. Botões menores que o mínimo são mais difíceis de mirar com dwell de forma precisa.
• Rótulos de acessibilidade. Todo elemento interativo deve ter um accessibilityLabel útil (SwiftUI) ou propriedade accessibilityLabel (UIKit). O Eye Tracking exibe o rótulo como equivalente a um tooltip quando o usuário faz dwell perto do elemento.
• Ordem de foco lógica. A tecla Tab no Mac e o focus engine no tvOS expõem a mesma ordem de foco que o Eye Tracking usa para pular entre elementos. Apps que usam as primitivas de layout padrão do SwiftUI ganham isso de graça; apps que sobrescrevem o comportamento de foco precisam verificar.
• Padrões modais amigáveis ao dwell. Um modal que se descarta automaticamente em toque externo pode frustrar usuários do Eye Tracking cujo ponto de dwell pode brevemente sair da área do modal. Apps com UI modal devem fornecer botões explícitos de descarte.

Apps que querem optar por sair do Eye Tracking para views específicas (conteúdo sensível, jogos complexos baseados em gestos) não têm uma API documentada de opt-out especificamente para o Eye Tracking. O recurso funciona em qualquer conteúdo visível e a responsabilidade do app é garantir que a superfície de acessibilidade padrão esteja correta.

O post sobre Three Surfaces of an iOS App cobre o padrão mais amplo: a UI visível é uma superfície, App Intents são outra, acessibilidade é a terceira. O Eye Tracking participa da superfície de UI visível; acertar essa superfície é o que habilita Eye Tracking, Switch Control, VoiceOver e Voice Control simultaneamente.

Music Haptics: a ponte de áudio para háptico

Music Haptics traduz a reprodução de música em vibrações do Taptic Engine sincronizadas com o áudio³. O recurso é opt-in por usuário (Ajustes > Acessibilidade > Music Haptics) e funciona para qualquer app de música que integre a API corretamente, não apenas Apple Music.

A superfície do desenvolvedor vive no MAMusicHapticsManager do MediaAccessibility.framework (iOS 18+). Um app de música integra o Music Haptics em três passos:

1. Declarar suporte no Info.plist. Adicione a chave MusicHapticsSupported com valor YES. O sistema usa isso para saber se o app participa da renderização do Music Haptics.
2. Tornar-se o app Now Playing ativo. O app precisa publicar metadados de reprodução através de MPNowPlayingInfoCenter.default().nowPlayingInfo e ser dono da sessão de áudio now-playing. O sistema precisa de uma fonte Now Playing ativa conhecida para conduzir a síntese háptica.
3. Fornecer um ISRC para a faixa em reprodução. A chave MPNowPlayingInfoPropertyInternationalStandardRecordingCode (o International Standard Recording Code) permite que o sistema procure a faixa háptica que se pareia com o áudio. A Apple mantém uma biblioteca de assets hápticos indexada por ISRC; faixas sem ISRC não recebem hápticos, mas o resto da integração now-playing ainda funciona.

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

A integração se aplica a qualquer app de música: um cliente de streaming construído em AVAudioEngine, um app de DJ com decodificadores customizados, um app de aprendizado musical com reprodução de samples. A restrição é o ISRC e o papel ativo de Now Playing, não a API de áudio subjacente. Apps que não têm ISRCs (música enviada pelo usuário sem metadados, música generativa) simplesmente não recebem hápticos; o resto da integração de reprodução não é afetado.

Para apps em espaços adjacentes (jogos de ritmo, visualizações musicais, motores de efeitos sonoros), o áudio não é para o que o Music Haptics foi projetado. Esses apps recorrem ao CHHapticEngine diretamente com padrões hápticos autorados manualmente sincronizados à sua fonte de áudio.

Vocal Shortcuts: onde acessibilidade encontra App Intents

Vocal Shortcuts permitem que os usuários atribuam frases de voz personalizadas a Atalhos da Siri, incluindo aqueles respaldados por tipos AppIntent de terceiros⁵. Um usuário pode configurar “Marker” para acionar um AddTodoIntent registrado por um app de tarefas; dizer “Marker” onde quer que o usuário esteja, sem invocar a frase de ativação da Siri, dispara o intent.

A integração usa o framework App Intents que o cluster cobriu extensivamente, com uma peça estrutural fácil de perder: o app precisa declarar um AppShortcutsProvider que exponha entradas AppShortcut com phrases explícitas. Um AppIntent puro existe no sistema mas só é invocável através do editor de Atalhos, onde o usuário monta manualmente um Atalho. Um AppShortcutsProvider registra atalhos visíveis ao sistema que o usuário pode imediatamente atribuir a um Vocal Shortcut, ao Action Button, à Siri ou ao 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"
        )
    }
}

O array de phrases é o que o sistema expõe à Siri e aos Vocal Shortcuts. Com o provider no lugar, o App Intent é imediatamente elegível para ativação por voz. Sem ele, o intent funciona através da configuração manual de Atalhos, mas o caminho é mais longo e muitos usuários nunca chegam lá.

O padrão se compõe com App Intents e App Intents vs MCP Tools. Um App Intent que conquista seu lugar na superfície de Apple Intelligence do usuário, pareado com um AppShortcutsProvider que declara como o usuário o invoca, também conquista seu lugar como alvo de Vocal Shortcut. O argumento do cluster de que App Intents são o contrato cross-system para “o que um app pode fazer” se aplica aqui: Vocal Shortcuts são outro consumidor desse mesmo contrato.

O padrão transversal: padrões são a integração

Os recursos de acessibilidade acima compartilham uma propriedade estrutural: cada um é construído sobre padrões que apps já deveriam atender, com uma pequena superfície opt-in de API para casos em que o app precisa cooperar explicitamente (autorização de Personal Voice, Music Haptics através de MPMusicPlayerController).

A implicação para times de desenvolvimento: o trabalho de acessibilidade não é uma esteira separada feita depois que o app é lançado. Os rótulos de acessibilidade do app, alvos de toque, ordem de foco e uso padrão das APIs do sistema são o que faz o Eye Tracking funcionar, o Live Speech rotear corretamente, o Music Haptics ativar e os Vocal Shortcuts exporem os intents certos. Apps que tratam a acessibilidade como uma checkbox no fim do ciclo entregam recursos que funcionam para o VoiceOver mas não para o Eye Tracking, ou que roteiam áudio de formas que o Live Speech não consegue seguir.

O post What I Refuse to Write About do cluster argumenta pela recusa como movimento de posicionamento. Recusas de acessibilidade são o inverso: não “me recuso a adicionar isso”, mas “me recuso a entregar algo que falha nos padrões que todo app iOS já deveria atender”.

Quando apps precisam de código de acessibilidade customizado

Três casos onde o padrão de seguir-padrões não cobre tudo:

Superfícies de desenho customizadas. Um app de desenho, um gráfico, uma UI de jogo renderizada de forma customizada burla a árvore de acessibilidade do SwiftUI/UIKit. O app precisa construir sua própria árvore de acessibilidade usando UIAccessibilityCustomAction, UIAccessibilityElement e propriedades de acessibilidade explícitas para cada elemento significativo. Eye Tracking, VoiceOver e Switch Control todos dependem da árvore de acessibilidade estar populada.

Interações gestuais em tempo real. Um jogo com entrada gestual contínua (desenhar, arrastar para mirar) não mapeia naturalmente para entrada baseada em dwell ou em switch. A abordagem certa é fornecer esquemas de controle alternativos (entrada baseada em botões como opção) em vez de brigar com o sistema de acessibilidade.

Recursos específicos de acessibilidade. Apps de AAC, apps de aumento de voz, apps de interpretação de linguagem de sinais. Esses apps são produtos de acessibilidade por direito próprio e integram profundamente com frameworks do sistema (Personal Voice, Speech framework, Vision framework para detecção de linguagem de sinais). O trabalho de integração é real e intencional.

O que esse padrão significa para apps iOS 26+

Três conclusões.

1. Participação em acessibilidade é principalmente seguir padrões, não construir recursos. A Apple vem movendo a acessibilidade para a camada da plataforma. O trabalho é garantir que seu app atenda aos padrões em que Eye Tracking, Switch Control, VoiceOver e Voice Control todos confiam: rótulos adequados, alvos de toque, ordem de foco, roteamento de áudio do sistema.

2. A integração com Personal Voice é sensível. Se seu app tem um caso de uso real de AAC (comunicação assistiva, aumento de voz, ferramentas de acessibilidade), a autorização de Personal Voice é a integração certa. Para apps de propósito geral, solicitar autorização de Personal Voice é mais provável de confundir os usuários do que ajudá-los.

3. App Intents são infraestrutura de acessibilidade. Um AppIntent limpo é automaticamente elegível para Vocal Shortcuts, ganha uma superfície de UI acessível através de Atalhos e integra com os modos de controle dirigidos por voz e por switch do sistema. O argumento do cluster pela adoção de App Intents também se aplica à acessibilidade.

O cluster Apple Ecosystem completo: typed App Intents; servidores MCP; a questão do roteamento; Foundation Models; a distinção LLM entre runtime e tooling; três superfícies; o padrão de fonte única da verdade; Two MCP Servers; hooks para desenvolvimento Apple; Live Activities; o contrato de runtime do watchOS; internals do SwiftUI; o modelo mental espacial do RealityKit; disciplina de schema do SwiftData; padrões Liquid Glass; shipping multi-plataforma; a matriz de plataformas; Vision framework; Symbol Effects; inferência Core ML; API Writing Tools; Swift Testing; Privacy Manifest; sobre o que me recuso a escrever. O hub está na Apple Ecosystem Series. Para contexto mais amplo de iOS com agentes de IA, veja o iOS Agent Development guide.

FAQ

Preciso escrever algum código para suportar Eye Tracking?

Para a maioria dos apps, não. O Eye Tracking funciona automaticamente com qualquer UI que siga as convenções padrão de acessibilidade: alvos de toque adequados (44pt mínimo), rótulos de acessibilidade úteis, ordem de foco lógica e controles padrão do sistema. Apps que desenham sua própria UI (views customizadas, jogos, gráficos) precisam popular a árvore de acessibilidade explicitamente usando UIAccessibilityElement ou os modificadores de acessibilidade do SwiftUI; esse trabalho também é o que faz o app funcionar para VoiceOver e Switch Control.

Posso usar Personal Voice em um app de voice-over de propósito geral?

O sistema permite isso via AVSpeechSynthesizer.requestPersonalVoiceAuthorization(), mas a orientação da Apple e o processo de revisão da App Store enfatizam Personal Voice para contextos assistivos (AAC, comunicação aumentativa e alternativa). Apps de voice-over de propósito geral solicitando autorização de Personal Voice enfrentam dois desafios: usuários têm pouca probabilidade de conceder autorização, e a revisão pode rejeitar a solicitação como uso inapropriado. Se seu caso de uso é genuinamente assistivo, a integração é correta; se é narração de propósito geral, vozes do sistema são a ferramenta certa.

Qual é a diferença entre Live Speech e Personal Voice?

Personal Voice é a voz sintetizada no dispositivo que soa como o usuário. Live Speech é o recurso do sistema que permite ao usuário digitar e ter o dispositivo falando (usando uma voz do sistema ou sua Personal Voice). Eles são complementares: Personal Voice fornece a voz, Live Speech fornece a UI de digitar-para-falar. Os apps integram Personal Voice através da API Speech Synthesizer; o Live Speech é invisível para os apps e opera no nível do sistema operacional.

Como adiciono Music Haptics a um app de música que usa AVAudioEngine?

Você pode. Music Haptics não é restrito a uma API de reprodução específica. A integração é: adicione MusicHapticsSupported = YES ao Info.plist, publique os metadados da faixa em reprodução através de MPNowPlayingInfoCenter.default().nowPlayingInfo (para que o sistema reconheça seu app como a fonte Now Playing ativa) e inclua MPNowPlayingInfoPropertyInternationalStandardRecordingCode com o ISRC da faixa. O sistema cuida da síntese háptica a partir daí. Faixas sem ISRCs não recebem hápticos, mas o resto da integração now-playing funciona normalmente.

Qual é o design de App Intent que dá a melhor experiência de Vocal Shortcuts?

Quatro princípios. Primeiro, declare um AppShortcutsProvider para o app e registre entradas AppShortcut para os intents que você quer acessíveis por voz. Sem o provider, o intent só chega aos Vocal Shortcuts via edição manual de Atalhos. Segundo, o title e shortTitle devem ser frases curtas com verbos (“Add Todo”, “Start Timer”) em vez de descrições. Terceiro, parâmetros devem ser opcionais ou ter padrões para que o usuário possa invocar o intent sem especificar todo campo. Quarto, a description deve ser uma única sentença clara explicando o efeito do intent; isso aparece como contexto quando o usuário escolhe uma frase para atribuir.

Referências