Accesibilidad como plataforma: Voz Personal, Habla en Vivo, Seguimiento Ocular y Hápticos Musicales

Voz Personal (iOS 17), Habla en Vivo (iOS 17), Seguimiento Ocular (iOS 18), Hápticos Musicales (iOS 18), Atajos Vocales (iOS 18). El arco de las recientes versiones de accesibilidad de Apple es coherente: las funciones que antes requerían apps de terceros, hardware dedicado o integraciones especializadas se están convirtiendo en capacidades de plataforma que el sistema operativo gestiona. El resultado es que el usuario tiene que instalar menos apps y el desarrollador adopta un modelo de participación distinto: en lugar de construir la función, el desarrollador acepta una superficie del sistema (autorización de Voz Personal) o sigue los estándares que toda app ya debería cumplir (etiquetas de accesibilidad correctas y áreas de toque adecuadas para Seguimiento Ocular).

El artículo recorre la superficie de desarrollo de cada función. El enfoque es “qué tiene que hacer mi app para participar” en lugar de “cómo implemento esta función”. Apple ha construido la función; la pregunta es si la app está lista para usarla.

TL;DR

• Voz Personal (iOS 17+) permite al usuario grabar 15 minutos de audio para crear una voz sintetizada en el dispositivo, destinada a apps de comunicación aumentativa y asistencial. Las apps se integran mediante AVSpeechSynthesizer.requestPersonalVoiceAuthorization() y verifican voiceTraits buscando .isPersonalVoice¹.
• Habla en Vivo (iOS 17+) es una función del sistema: el usuario escribe texto y el dispositivo lo pronuncia (opcionalmente con su Voz Personal). Las apps no integran Habla en Vivo directamente; la función opera a nivel del sistema operativo en llamadas, FaceTime y comunicación presencial.
• Seguimiento Ocular (iOS 18+) controla el dispositivo mediante la mirada y Control por Permanencia a través de la cámara frontal. Las apps participan siguiendo los estándares de accesibilidad (etiquetas de accesibilidad correctas, dimensionamiento de áreas de toque, orden de foco); para la mayoría de las apps no se requiere ningún API dedicado².
• Hápticos Musicales (iOS 18+) traduce la reproducción de música a vibraciones del Taptic Engine sincronizadas con el audio mediante el API MAMusicHapticsManager en MediaAccessibility.framework. Cualquier app de música puede integrarse configurando MusicHapticsSupported en Info.plist, convirtiéndose en la app activa de Now Playing y proporcionando un ISRC³.
• Atajos Vocales (iOS 18+) permite a los usuarios asignar frases personalizadas para activar Atajos de Siri, incluidas acciones AppIntent de terceros. La función se potencia con la adopción de App Intents (tratada en App Intents son la nueva API de Apple hacia tu app).

Voz Personal: el patrón de autorización

Voz Personal es la función de accesibilidad con la superficie de desarrollo más directa¹. El usuario activa la función en Configuración > Accesibilidad > Voz Personal, graba aproximadamente 15 minutos de audio leyendo indicaciones aleatorias, y el dispositivo genera una voz sintetizada localmente usando aprendizaje automático en el dispositivo. La voz es privada para el usuario; no sale del dispositivo a menos que el usuario la comparta explícitamente con dispositivos emparejados a través de iCloud.

Para que una app use la Voz Personal del usuario en AVSpeechSynthesizer, debe:

1. Solicitar autorización mediante AVSpeechSynthesizer.requestPersonalVoiceAuthorization(completionHandler:).
2. Esperar a que el usuario otorgue permiso a través del aviso del sistema.
3. Tras la aprobación, consultar AVSpeechSynthesisVoice.speechVoices() y filtrar las voces cuyo voiceTraits contenga .isPersonalVoice.
4. Usar el AVSpeechSynthesisVoice resultante como cualquier otra voz en 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)
    }
}

La autorización es delicada. La recomendación de Apple es que Voz Personal se destine principalmente a apps de comunicación aumentativa y alternativa (AAC) y contextos asistenciales similares. Es probable que los usuarios denieguen la autorización a una app de lectura por voz de propósito general, y dicha app puede ser objeto de escrutinio en la revisión de la App Store.

La arquitectura “primero en el dispositivo” es relevante aquí. Los datos de entrenamiento de la voz del usuario y el modelo de voz resultante nunca salen del área de enclave seguro del dispositivo a menos que el usuario opte explícitamente por compartirlos a través de iCloud. Las etiquetas de privacidad de la App Store para apps que usan Voz Personal deberían reflejar cero recopilación de datos, ya que la síntesis ocurre localmente y la salida de audio va al altavoz, no a la red.

Habla en Vivo: la función del sistema sin integración

Habla en Vivo es la contraparte orientada al consumidor de Voz Personal⁴. El usuario escribe texto y el dispositivo lo pronuncia, opcionalmente usando su Voz Personal. Habla en Vivo funciona durante llamadas telefónicas, llamadas FaceTime, SharePlay en Mac y conversaciones presenciales a través del altavoz del dispositivo.

Las apps no integran Habla en Vivo directamente. La función opera a nivel del sistema operativo, interceptando el texto escrito desde la interfaz de Habla en Vivo del sistema y enrutándolo a través de la pila de audio. Desde la perspectiva de una app, Habla en Vivo es invisible: el flujo de audio que entra por la llamada (o que se reproduce desde el altavoz del dispositivo para uso presencial) suena como el usuario, pero no interviene código de la app.

La implicación para los desarrolladores: si tu app maneja voz (una app de llamadas, una app de videochat, un asistente de accesibilidad), la canalización de audio de la app debe respetar el enrutamiento de audio del sistema para que Habla en Vivo pueda emitirse por el mismo canal. Las apps que pelean contra la sesión de audio (reclamando control exclusivo sin considerar los sonidos superpuestos a nivel del sistema) rompen Habla en Vivo.

Seguimiento Ocular: la función que sigue los estándares

Seguimiento Ocular, introducido en iOS 18, permite a los usuarios controlar el iPhone y el iPad mediante la dirección de la mirada más Control por Permanencia². El usuario calibra la cámara frontal en pocos segundos y luego navega por la interfaz mirando los elementos; mantener la mirada en un elemento durante el tiempo de permanencia configurado lo activa (toque, deslizamiento u otros gestos, configurables en Control por Botón).

La implementación se realiza en el dispositivo. La cámara frontal procesa los datos de mirada mediante aprendizaje automático en el dispositivo; los datos no salen del dispositivo. No se requiere hardware adicional.

Para la mayoría de las apps, dar soporte a Seguimiento Ocular no requiere código dedicado. La función funciona con cualquier interfaz que siga las convenciones estándar de accesibilidad:

• Áreas de toque adecuadas. Las Pautas de Interfaz Humana de Apple especifican áreas de toque mínimas de 44pt por 44pt para los elementos tocables. Seguimiento Ocular respeta estas medidas. Los botones más pequeños que el mínimo son más difíciles de fijar con permanencia.
• Etiquetas de accesibilidad. Cada elemento interactivo debe tener un accessibilityLabel útil (SwiftUI) o una propiedad accessibilityLabel (UIKit). Seguimiento Ocular muestra la etiqueta como equivalente a un tooltip cuando el usuario fija la mirada cerca del elemento.
• Orden de foco lógico. La tecla Tab en Mac y el motor de foco en tvOS exponen el mismo orden de foco que Seguimiento Ocular usa para saltar entre elementos. Las apps que usan las primitivas de diseño estándar de SwiftUI obtienen esto sin esfuerzo; las apps que sobrescriben el comportamiento de foco deben verificarlo.
• Patrones modales compatibles con la permanencia. Un modal que se descarta automáticamente al tocar fuera puede frustrar a los usuarios de Seguimiento Ocular cuyo punto de mirada puede salir brevemente del área del modal. Las apps con interfaz modal deben proporcionar botones de cierre explícitos.

Las apps que quieran excluir Seguimiento Ocular para vistas específicas (contenido sensible, juegos complejos basados en gestos) no tienen un API documentado de exclusión específico para Seguimiento Ocular. La función opera sobre cualquier contenido visible, y la responsabilidad de la app es asegurar que la superficie estándar de accesibilidad sea correcta.

El artículo sobre las tres superficies de una app iOS cubre el patrón más amplio: la interfaz visible es una superficie, App Intents es otra y la accesibilidad es la tercera. Seguimiento Ocular participa en la superficie de la interfaz visible; conseguir que esa superficie esté bien hecha es lo que permite que Seguimiento Ocular, Control por Botón, VoiceOver y Control por Voz funcionen simultáneamente.

Hápticos Musicales: el puente de audio a háptica

Hápticos Musicales traduce la reproducción de música a vibraciones del Taptic Engine sincronizadas con el audio³. La función es opcional para cada usuario (Configuración > Accesibilidad > Hápticos Musicales) y funciona con cualquier app de música que integre el API correctamente, no solo con Apple Music.

La superficie de desarrollo vive en MAMusicHapticsManager de MediaAccessibility.framework (iOS 18+). Una app de música integra Hápticos Musicales en tres pasos:

1. Declarar soporte en Info.plist. Añade la clave MusicHapticsSupported con valor YES. El sistema usa esto para saber si la app participa en la generación de Hápticos Musicales.
2. Convertirse en la app activa de Now Playing. La app debe publicar los metadatos de reproducción mediante MPNowPlayingInfoCenter.default().nowPlayingInfo y poseer la sesión de audio de Now Playing. El sistema necesita una fuente activa conocida de Now Playing para impulsar la síntesis háptica.
3. Proporcionar un ISRC para la pista en reproducción. La clave MPNowPlayingInfoPropertyInternationalStandardRecordingCode (Código Internacional Estándar de Grabación) permite al sistema buscar la pista háptica que se empareja con el audio. Apple mantiene una biblioteca de activos hápticos indexada por ISRC; las pistas sin ISRC no obtienen hápticos, pero el resto de la integración de Now Playing sigue funcionando.

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

La integración aplica a cualquier app de música: un cliente de streaming construido sobre AVAudioEngine, una app de DJ con decodificadores personalizados, una app de aprendizaje musical con reproducción de muestras. La restricción es el ISRC y el rol activo de Now Playing, no el API de audio subyacente. Las apps que no tienen ISRC (música subida por el usuario sin metadatos, música generativa) simplemente no obtienen hápticos; el resto de la integración de reproducción no se ve afectada.

Para apps en espacios adyacentes (juegos rítmicos, visualizaciones musicales, motores de efectos de sonido), el audio no es para lo que está diseñado Hápticos Musicales. Esas apps recurren directamente a CHHapticEngine con patrones hápticos creados a mano sincronizados con su fuente de audio.

Atajos Vocales: donde la accesibilidad se encuentra con App Intents

Atajos Vocales permite a los usuarios asignar frases de voz personalizadas a Atajos de Siri, incluidos los respaldados por tipos AppIntent de terceros⁵. Un usuario puede configurar “Marcador” para activar un AddTodoIntent registrado por una app de tareas; decir “Marcador” donde sea que se encuentre el usuario, sin invocar la frase de activación de Siri, dispara la acción.

La integración usa el framework App Intents que el clúster ha cubierto extensamente, con una pieza estructural que es fácil pasar por alto: la app debe declarar un AppShortcutsProvider que exponga entradas AppShortcut con phrases explícitas. Un AppIntent solitario existe en el sistema pero solo se puede invocar a través del editor de Atajos, donde el usuario ensambla manualmente un Atajo. Un AppShortcutsProvider registra atajos visibles para el sistema que el usuario puede asignar inmediatamente a un Atajo Vocal, al Botón Acción, a Siri o a 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"
        )
    }
}

El array de frases es lo que el sistema expone a Siri y a Atajos Vocales. Con el provider en su lugar, el App Intent es inmediatamente apto para activación por voz. Sin él, la acción funciona mediante la configuración manual de Atajos, pero el camino es más largo y muchos usuarios nunca llegan a recorrerlo.

El patrón se potencia con App Intents y App Intents frente a herramientas MCP. Un App Intent que se gana su lugar en la superficie de Apple Intelligence del usuario, emparejado con un AppShortcutsProvider que declara cómo el usuario lo invoca, también se gana su lugar como objetivo de un Atajo Vocal. El argumento del clúster de que App Intents son el contrato entre sistemas para “lo que una app puede hacer” se aplica aquí: Atajos Vocales es otro consumidor de ese mismo contrato.

El patrón transversal: los estándares son la integración

Las funciones de accesibilidad anteriores comparten una propiedad estructural: cada una se construye sobre estándares que las apps ya deberían cumplir, con una pequeña superficie API opcional para los casos en que la app debe cooperar explícitamente (autorización de Voz Personal, Hápticos Musicales mediante MPMusicPlayerController).

La implicación para los equipos de desarrollo: el trabajo de accesibilidad no es un flujo de trabajo separado que se hace después de lanzar la app. Las etiquetas de accesibilidad de la app, las áreas de toque, el orden de foco y el uso estándar del API del sistema son lo que hace que Seguimiento Ocular funcione, que Habla en Vivo se enrute correctamente, que Hápticos Musicales se active y que Atajos Vocales presente las acciones correctas. Las apps que tratan la accesibilidad como una casilla al final del ciclo lanzan funciones que funcionan para VoiceOver pero no para Seguimiento Ocular, o que enrutan el audio de formas que Habla en Vivo no puede seguir.

El artículo del clúster Lo que me niego a escribir defiende la negativa como movimiento de posicionamiento. Las negativas en accesibilidad son lo inverso: no “me niego a añadir esto”, sino “me niego a publicar algo que falle los estándares que toda app de iOS ya debería cumplir”.

Cuándo las apps necesitan código de accesibilidad personalizado

Tres casos en los que el patrón de seguir los estándares no lo cubre todo:

Superficies de dibujo personalizadas. Una app de dibujo, un gráfico o una interfaz de juego renderizada a medida saltan el árbol de accesibilidad de SwiftUI/UIKit. La app debe construir su propio árbol de accesibilidad usando UIAccessibilityCustomAction, UIAccessibilityElement y propiedades de accesibilidad explícitas para cada elemento significativo. Seguimiento Ocular, VoiceOver y Control por Botón dependen todos de que el árbol de accesibilidad esté poblado.

Interacciones gestuales en tiempo real. Un juego con entrada gestual continua (dibujar, arrastrar para apuntar) no se mapea naturalmente a una entrada basada en permanencia o en botón. El enfoque correcto es proporcionar esquemas de control alternativos (entrada basada en botones como opción) en lugar de pelear contra el sistema de accesibilidad.

Funciones específicas de accesibilidad. Apps de AAC, apps de aumento de voz, apps de interpretación de lengua de signos. Estas apps son productos de accesibilidad por derecho propio y se integran profundamente con los frameworks del sistema (Voz Personal, framework Speech, framework Vision para detección de lengua de signos). El trabajo de integración es real e intencional.

Qué significa este patrón para las apps de iOS 26+

Tres conclusiones.

1. La participación en accesibilidad consiste mayoritariamente en seguir estándares, no en construir funciones. Apple ha estado moviendo la accesibilidad a la capa de plataforma. El trabajo consiste en asegurarse de que tu app cumpla los estándares en los que se basan Seguimiento Ocular, Control por Botón, VoiceOver y Control por Voz: etiquetas correctas, áreas de toque, orden de foco, enrutamiento de audio del sistema.

2. La integración de Voz Personal es delicada. Si tu app tiene un caso de uso real de AAC (comunicación asistencial, aumento de voz, herramientas de accesibilidad), la autorización de Voz Personal es la integración correcta. Para apps de propósito general, solicitar la autorización de Voz Personal probablemente confunda más a los usuarios de lo que les ayude.

3. App Intents es infraestructura de accesibilidad. Un AppIntent limpio es automáticamente apto para Atajos Vocales, obtiene una superficie de interfaz accesible a través de Atajos y se integra con los modos de control por voz y por botón del sistema. El argumento del clúster a favor de adoptar App Intents también se aplica a la accesibilidad.

El clúster completo del Ecosistema de Apple: App Intents tipados; servidores MCP; la cuestión del enrutamiento; Foundation Models; la distinción LLM runtime frente a tooling; tres superficies; el patrón de fuente única de verdad; dos servidores MCP; hooks para desarrollo en Apple; Live Activities; el contrato de runtime de watchOS; internals de SwiftUI; el modelo mental espacial de RealityKit; disciplina de esquemas en SwiftData; patrones de Liquid Glass; publicación multiplataforma; la matriz de plataformas; framework Vision; Symbol Effects; inferencia con Core ML; API de Writing Tools; Swift Testing; Privacy Manifest; lo que me niego a escribir. El hub está en la serie del Ecosistema de Apple. Para un contexto más amplio sobre iOS con agentes de IA, consulta la guía de desarrollo de agentes en iOS.

Preguntas frecuentes

¿Necesito escribir código para soportar Seguimiento Ocular?

Para la mayoría de las apps, no. Seguimiento Ocular funciona automáticamente con cualquier interfaz que siga las convenciones estándar de accesibilidad: áreas de toque correctas (44pt mínimo), etiquetas de accesibilidad útiles, orden de foco lógico y controles estándar del sistema. Las apps que dibujan su propia interfaz (vistas personalizadas, juegos, gráficos) deben poblar el árbol de accesibilidad explícitamente usando UIAccessibilityElement o los modificadores de accesibilidad de SwiftUI; ese trabajo también es lo que hace que la app funcione con VoiceOver y Control por Botón.

¿Puedo usar Voz Personal en una app de lectura por voz de propósito general?

El sistema lo permite mediante AVSpeechSynthesizer.requestPersonalVoiceAuthorization(), pero la recomendación de Apple y el proceso de revisión de la App Store enfatizan Voz Personal para contextos asistenciales (AAC, comunicación aumentativa y alternativa). Las apps de lectura por voz de propósito general que solicitan autorización de Voz Personal enfrentan dos retos: es poco probable que los usuarios concedan la autorización, y la revisión puede rechazar la solicitud por considerarla un uso inapropiado. Si tu caso de uso es genuinamente asistencial, la integración es la adecuada; si es narración de propósito general, las voces del sistema son la herramienta correcta.

¿Cuál es la diferencia entre Habla en Vivo y Voz Personal?

Voz Personal es la voz sintetizada en el dispositivo que suena como el usuario. Habla en Vivo es la función del sistema que permite al usuario escribir y que el dispositivo lo pronuncie (usando una voz del sistema o su Voz Personal). Son complementarias: Voz Personal proporciona la voz, Habla en Vivo proporciona la interfaz de texto a habla. Las apps integran Voz Personal mediante el API Speech Synthesizer; Habla en Vivo es invisible para las apps y opera a nivel del sistema operativo.

¿Cómo añado Hápticos Musicales a una app de música que usa AVAudioEngine?

Puedes hacerlo. Hápticos Musicales no está limitado a un API de reproducción específico. La integración consiste en: añadir MusicHapticsSupported = YES al Info.plist, publicar los metadatos de la pista en reproducción mediante MPNowPlayingInfoCenter.default().nowPlayingInfo (para que el sistema reconozca tu app como la fuente activa de Now Playing) e incluir MPNowPlayingInfoPropertyInternationalStandardRecordingCode con el ISRC de la pista. El sistema se encarga de la síntesis háptica a partir de ahí. Las pistas sin ISRC no obtienen hápticos, pero el resto de la integración de Now Playing funciona normalmente.

¿Cuál es el diseño de App Intent que ofrece la mejor experiencia de Atajos Vocales?

Cuatro principios. Primero, declara un AppShortcutsProvider para la app y registra entradas AppShortcut para las acciones que quieres que sean accesibles por voz. Sin el provider, la acción solo llega a Atajos Vocales mediante la edición manual de Atajos. Segundo, el title y el shortTitle deben ser frases verbales cortas (“Añadir tarea”, “Iniciar temporizador”) en lugar de descripciones. Tercero, los parámetros deben ser opcionales o tener valores por defecto para que el usuario pueda invocar la acción sin especificar cada campo. Cuarto, la description debe ser una sola oración clara que explique el efecto de la acción; esto aparece como contexto cuando el usuario elige una frase para asignar.

Referencias