Accesibilidad en iOS 27: Apple le ha metido IA, pero eso no te hace cumplir la EAA

Cada vez que Apple presenta novedades de accesibilidad, en las reuniones de producto reaparece la misma frase: "Apple ya hace la app accesible, ¿no?". Y este año suena más convincente que nunca, porque las funciones nuevas llevan IA y parecen magia.

Es falsa. Y puede costarte caro.

Apple te da herramientas de sistema muy buenas para que tus usuarios funcionen mejor. La conformidad de tu app con la EAA, en cambio, sigue dependiendo por completo de lo que tú construyas. Un auditor no evalúa si iOS trae VoiceOver —lo trae— sino si tu app es operable con esas tecnologías. Y eso no se activa en Ajustes: se construye, control a control, en tu código.

He trabajado en accesibilidad crítica —en Juegos ONCE, donde VoiceOver no es un extra sino el modo principal de uso para una parte enorme de la base de usuarios— y también audito accesibilidad de apps antes de que lleguen a producción. Desde esas dos sillas te separo lo que es regalo de Apple de lo que te va a tocar a ti.

Lo que ha presentado Apple (y sí, es bueno)

Las novedades de accesibilidad de iOS 27 se apoyan fuerte en Apple Intelligence, y casi todo se ejecuta on-device, lo cual es una buena noticia también de cara al GDPR:

• VoiceOver con descripciones de imágenes enriquecidas. Puedes deslizar hacia arriba sobre una imagen con una acción personalizada de VoiceOver y obtener una descripción sin salir de la app, e incluso hacer preguntas de seguimiento sobre lo que hay en ella. Para fotos, recibos o documentos es un salto real.
• Live Recognition: desde el botón de acción, preguntar al sistema qué aparece en el visor de la cámara.
• Voice Control en lenguaje natural. En lugar de nombres rígidos de controles, puedes describir con lenguaje natural cualquier cosa que haya en pantalla. Para usuarios con movilidad reducida es un cambio de categoría.
• Accessibility Reader más personalizable (introducido en iOS 26): una herramienta de sistema que se lanza desde cualquier app para consumir contenido de texto largo con el estilo que cada uno prefiera, integrada con el contenido hablado.
• Subtítulos generados on-device en vídeos personales: el modelo de transcripción y traducción vive en el dispositivo y los subtítulos aparecen automáticamente durante la reproducción, sin que tengas que implementar nada.

Hay una que conviene marcar con rigor: la función de interpretación por vídeo en FaceTime se anunció en WWDC, pero en el momento de escribir esto no está disponible en las betas de iOS 27 ni tiene APIs públicas —sin detalles de entitlements ni de restricciones—. Si alguien te la vende como algo que ya puedes integrar hoy, desconfía.

Todo esto está muy bien. Y no te acerca ni un milímetro a la conformidad con la EAA. Vamos con el porqué.

La distinción que casi nadie explica bien

La EAA está en vigor desde junio de 2025. En España la transponen la Ley 11/2023 y el Real Decreto 193/2023, con un régimen sancionador que va desde los 301 € hasta el millón de euros, y con un periodo de continuidad de servicio hasta el 28 de junio de 2030 (el Real Decreto 193/2023 fija además el 1 de enero de 2030 para las apps ya existentes del sector privado). El estándar técnico de referencia es la EN 301 549.

Lo importante: la EN 301 549 no evalúa el sistema operativo. Evalúa tu producto. Que iOS tenga un lector de pantalla excelente no dice nada sobre si un usuario de VoiceOver puede completar un alta, firmar un contrato o pagar un recibo en tu app.

Y aquí está el matiz que se pierde con el ruido de la IA: las funciones nuevas de Apple mejoran cómo el sistema interpreta tu interfaz, pero no reparan una interfaz que está mal expuesta. Si un control custom no publica su rol, su valor y sus acciones, ninguna IA on-device lo va a adivinar de forma fiable. La descripción de imágenes de VoiceOver te ayuda con una foto; no convierte tu formulario de transferencia en algo operable.

La conformidad EAA es responsabilidad del desarrollador. Punto. Apple pone la plataforma; tú pones la app conforme.

Dónde están los fallos graves (y por qué son tuyos)

Después de auditar unas cuantas apps, te puedo decir dónde aparecen casi siempre los problemas serios: casi nunca en los controles nativos, casi siempre en la UI custom. Un Button, un Toggle o un Slider de SwiftUI ya vienen bien expuestos de fábrica. El desastre llega cuando alguien construye un control propio y lo marca como "accesible" poniéndole un accessibilityLabel… y nada más.

La sesión de WWDC sobre controles custom lo resume en cuatro principios que deberían ser tu checklist mental: propósito, valor, acciones y feedback. Un label solo cubre el primero. Mira el caso típico —un dispensador de café que se ajusta arrastrando:

// ❌ Lo que suele haber: "accesible" con solo un label.
struct CoffeeDispenser: View {
    @State private var ounces = 6

    var body: some View {
        CupShape(fill: ounces)
            .gesture(dragToAdjust)
            .accessibilityLabel("Dispensador de café")
        // VoiceOver anuncia el nombre y se acabó.
        // No dice el valor, no ofrece forma de cambiarlo, no da feedback.
    }
}

Para VoiceOver esto es un callejón sin salida: sabe qué es, pero el usuario no puede saber cuánto café hay ni cambiarlo. Así se arregla —añadiendo valor, una acción ajustable y feedback:

// ✅ Propósito + valor + acción + feedback.
struct CoffeeDispenser: View {
    @State private var ounces = 6

    var body: some View {
        CupShape(fill: ounces)
            .gesture(dragToAdjust)
            .accessibilityElement()
            .accessibilityLabel("Dispensador de café")
            .accessibilityValue("\(ounces) onzas")
            .accessibilityAdjustableAction { direction in
                switch direction {
                case .increment: ounces = min(ounces + 1, 12)
                case .decrement: ounces = max(ounces - 1, 0)
                @unknown default: break
                }
            }
    }
}

Ahora un usuario de VoiceOver selecciona el control, desliza arriba o abajo y escucha "7 onzas… 8 onzas". El mismo patrón —exponer rol, valor y acciones— es lo que también hace que Voice Control y Switch Control funcionen, porque comparten la misma capa de accesibilidad por debajo. Arreglas una cosa y arreglas tres.

Para controles con más de un eje (un pad de ecualizador, por ejemplo, donde .adjustable se queda corto), la herramienta es accessibilityAction con acciones personalizadas ("subir", "bajar", "izquierda", "derecha"). Y para controles muy gestuales que no encajan en el modelo de swipes de VoiceOver, iOS 27 te deja marcar una zona de direct touch que pasa los toques directamente al control. La regla de oro: siempre que puedas, ofrece también una vía por acciones, porque no todo el mundo puede ejecutar gestos precisos.

El otro gran olvidado: Dynamic Type

Si me preguntas por dónde empezar cuando una app grande no ha tocado la accesibilidad, mi respuesta —y la del equipo de accesibilidad de Apple— es la misma: Dynamic Type. Es lo que más usuarios afecta y lo que antes delata una UI frágil.

El pecado clásico son los valores clavados: tamaños de fuente fijos (size: 12 en vez del estilo semántico .caption) y anchos rígidos que truncan el texto en cuanto crece. La solución es siempre la misma —estilos semánticos y constraints flexibles— y, cuando el tamaño accesible rompe el diseño de raíz, no forzarlo: cambiar el layout. SwiftUI lo permite con AnyLayout, que alterna entre disposición horizontal y vertical según el tamaño de tipografía sin duplicar la vista. Es exactamente lo que hace el propio Centro de Control de iOS: con texto grande, los controles crecen y se recolocan. Ese es el estándar que un auditor —y tus usuarios— van a esperar de tu app.

Una novedad concreta de este ciclo: Dynamic Type llega a tvOS 27. Si tienes app de televisión, este mismo trabajo ahora aplica ahí.

Qué significa esto en la práctica para tu equipo

Si tienes una app en producción que nunca ha pasado por esto, el camino realista no es "reescribir con accesibilidad": es auditar → priorizar → arreglar de forma incremental. Una auditoría con VoiceOver y texto grande sobre los flujos críticos (alta, login, pago, firma) te da un backlog concreto. Se prioriza por criticidad para el usuario, no solo por volumen: un fallo que bloquea el pago pesa más que veinte labels mejorables en pantallas secundarias. Y los arreglos entran en sprints normales, junto a features, sin parar el desarrollo. Es trabajo acotado y medible —no el agujero negro que muchos equipos temen— y con el horizonte de 2030, cuanto antes empiece, más barato sale.

Cómo verificarlo de verdad (y una API nueva que ayuda)

Marcar cosas como accesibles no sirve de nada si no lo pruebas con las tecnologías reales. Tres cosas prácticas:

Empieza por VoiceOver. Es lo que más rendimiento te da por hora invertida: como muchas tecnologías asistivas comparten la misma capa por debajo, una buena experiencia con VoiceOver arrastra buena parte de Voice Control y Switch Control. No es excusa para no probar las demás, pero es el mejor punto de partida. Truco de campo: mete VoiceOver en el atajo de accesibilidad (triple clic) para activarlo y desactivarlo sin perderte en Ajustes.

Automatiza para no regresar. Los tests de UI (XCUITest) se apoyan en la jerarquía de accesibilidad: si tu app no es accesible, tus tests se rompen. Eso convierte la suite de UI en una red contra regresiones de accesibilidad casi gratis. Este año, además, hay una nueva API de XCTest para pilotar VoiceOver desde el Mac contra el simulador o un dispositivo, así que puedes validar que VoiceOver llega a los elementos y anuncia lo correcto de forma automatizada. (Está en las primeras betas; trátalo como lo que es, algo muy nuevo.)

Apóyate en el Accessibility Inspector para auditar elementos y detectar labels vacíos, y —si puedes— consigue feedback de usuarios reales de tecnologías asistivas. Nadie te va a encontrar los agujeros como quien vive dentro de VoiceOver todos los días.

Un apunte para quien trabaje con Xcode 27: hay nuevas skills de IA en el asistente de código orientadas específicamente a accesibilidad. Puedes pedirle "haz esta vista accesible para VoiceOver" o "qué le falta a este fichero para Dynamic Type" y te sugiere y edita el código. Útil como acelerador —pero, como con todo lo que genera un LLM, la validación sigue siendo tuya. Que compile no significa que el flujo sea operable.

Las Accessibility Nutrition Labels siguen siendo voluntarias

Este año hay ruido con las Accessibility Nutrition Labels, y conviene aclararlo porque circula desinformación: son la forma de que un usuario sepa, antes de descargar, qué features de accesibilidad soporta tu app (VoiceOver, Dynamic Type, contraste, etc.). En iOS 27 se amplían, e incluso puedes declarar soporte de texto grande para tvOS.

Pero son voluntarias y no tienen fecha obligatoria. No forman parte del mecanismo legal de la EAA. Si te encuentras un artículo que te pone un deadline para las Nutrition Labels, desconfía: se lo está inventando.

Dicho esto, a mí me parecen útiles por dos motivos que no son el legal. Uno: vienen con criterios y guías de Apple, así que te dan un baremo concreto contra el que testear. Dos: son una palanca de negociación interna estupenda —he visto equipos usar "queremos poder poner esta etiqueta" para conseguir por fin presupuesto y prioridad para el trabajo de accesibilidad que llevaban años posponiendo—. La etiqueta no te hace conforme con la EAA, pero el trabajo que haces para merecerla, sí te acerca.

En resumen

Las funciones de accesibilidad con IA de iOS 27 son un regalo para tus usuarios, no un atajo de conformidad. El auditor no prueba iOS: prueba tu app. Y tu app solo es operable si tú expones cada control con su propósito, su valor, sus acciones y su feedback, si tu texto escala con Dynamic Type y si lo verificas con las tecnologías reales.

La otra lección, la que repite todo el equipo de accesibilidad de Apple: la accesibilidad se construye desde el principio, no se pega al final. Tratarla como categoría de primera —al nivel de seguridad o privacidad— en la fase de planificación cuesta muchísimo menos que taparla a última hora con parches. Y de cara a 2030, es la diferencia entre una app que envejece conforme y una que acumula deuda de accesibilidad hasta que llega una sanción o, peor, un usuario que no puede usarla.

Preguntas frecuentes

¿Activar VoiceOver o las funciones de accesibilidad de iOS 27 hacen que mi app cumpla la EAA?

No. La EN 301 549 evalúa tu app, no el sistema operativo. Que iOS traiga un lector de pantalla excelente no dice nada sobre si un usuario de VoiceOver puede completar un alta, firmar un contrato o pagar un recibo dentro de tu app. La conformidad la construyes tú, control a control.

¿Desde cuándo es obligatoria la EAA en España y qué sanciones conlleva?

Está en vigor desde el 28 de junio de 2025, transpuesta por la Ley 11/2023 y el Real Decreto 193/2023. El régimen sancionador prevé multas desde 301 € hasta 1.000.000 € según la gravedad. Para las apps ya existentes del sector privado, el RD 193/2023 fija el 1 de enero de 2030, con un periodo de continuidad de servicio hasta el 28 de junio de 2030.

¿Las Accessibility Nutrition Labels son obligatorias?

No. Son voluntarias, no tienen fecha límite y no forman parte del mecanismo legal de la EAA. Si un artículo te pone un deadline para ellas, se lo está inventando. Son útiles como baremo de testeo y como palanca de negociación interna, no como prueba de conformidad.

¿Por dónde conviene empezar a hacer accesible una app iOS grande?

Por Dynamic Type y VoiceOver: es lo que más usuarios afecta y lo que antes delata una UI frágil. Un buen soporte de VoiceOver arrastra además buena parte de Voice Control y Switch Control, porque comparten la misma capa de accesibilidad por debajo.

Fuentes (sesiones WWDC 2026)

• Refine accessibility for custom controls
• Enhance the accessibility of your reading app
• Prepare your tvOS apps for Dynamic Type
• Discover generated subtitles and subtitle styles

---

¿Necesitas hacer tu app iOS accesible para cumplir con la EAA? En AtalayaSoft hemos implementado accesibilidad en apps con millones de usuarios, incluyendo entornos donde VoiceOver es el modo de uso principal.

Hablemos →