Na web aberta, speechSynthesis lê texto em voz alta e webkitSpeechRecognition converte voz em texto. Dentro de um WebView ambos silenciam —mas o perigo é que um deles finge funcionar.

Android: speechSynthesis simplesmente não existe

O Android WebView nunca implementou o lado de texto em voz da Web Speech API. speechSynthesis não é fornecido, getVoices() retorna uma lista vazia e o evento voiceschanged nunca dispara. Está bem documentado: provedores como a ResponsiveVoice observam que o TTS nativo "não é suportado no Android WebView" e a página deve recorrer a uma API de síntese no servidor. Para um app híbrido com Cordova ou Capacitor, a mesma lacuna aparece por padrão. A página que chama speechSynthesis.speak() obtém silêncio, não um erro do qual possa se recuperar.

iOS: a API está exposta, mas morta

O iOS é o caso mais insidioso. No WKWebView, webkitSpeechRecognition está presente em window —então uma verificação como if (window.webkitSpeechRecognition) passa— mas nunca funciona de fato. O rastreador de bugs do WebKit registra exatamente isso: o aviso de permissão nunca aparece e a chamada retorna um erro service-not-allowed porque o app host não declarou a descrição de uso do reconhecimento de voz. A página acredita que a entrada por voz está disponível, chama-a e não obtém nada. O texto em voz no WKWebView é igualmente pouco confiável. A detecção de características, na qual os desenvolvedores confiam para ramificar corretamente, mente ativamente aqui.

O que quebra quando a voz morre

  • A leitura acessível desaparece. Operadores com deficiência visual que dependem da página ler cotações, extratos ou alertas em voz alta ficam em silêncio.
  • A confirmação de ordem por voz pode nunca falar. Uma corretora que anuncia "ordem enviada" via TTS pode falhar silenciosamente em dizê-lo: uma lacuna perigosa quando o usuário assume que a confirmação ocorreu.
  • A busca e a ditado por voz param. A entrada mãos livres em um carro ou em um chão de fábrica nunca abre o reconhecedor.
  • Silencioso e falsamente "suportado". Especialmente no iOS, a API parece presente, então a página lança uma UI de voz que nunca funciona.

A correção no runtime

Um runtime próprio do host faz a ponte com a camada de voz. A página chama runtime.speak(text, opts) para ler em voz alta e runtime.startDictation() para entrada por voz, e o host as resolve com motores nativos: Android TextToSpeech e SpeechRecognizer, iOS AVSpeechSynthesizer e SFSpeechRecognizer (com as descrições de uso exigidas declaradas no app). A capacidade é consultada honestamente, as vozes são nativas e instaladas, e o resultado é verificável. Uma integração, todos os motores, áudio real no fim.

DimensãoWebViewRuntime próprio do host
speechSynthesis (TTS)Ausente no Android WebView; pouco confiável no WKWebViewTextToSpeech / AVSpeechSynthesizer nativos
webkitSpeechRecognitionExposto mas morto no WKWebView (service-not-allowed)SFSpeechRecognizer / SpeechRecognizer nativos
Detecção de característicasMente (API presente, sem aviso)Consulta honesta de capacidade
Voz para acessibilidadeLacuna silenciosaLeitura confiável
Confirmação de ordem por vozPode nunca falarNativa, verificável
ConsistenciaArmadilha por motorUniforme

Um app nativo fala e ouve em todos os dispositivos. Um WebView padrão fala em quase nenhum e, no iOS, mente sobre o resto. Um runtime dá à página uma chamada speak e uma chamada dictation —e áudio real no fim de cada uma.

Fontes