Llamarlo «WebView» oculta a quién falla. Las personas que dependen de tecnologías de asistencia —VoiceOver, TalkBack, control por pulsadores, texto grande, alto contraste— son precisamente a quienes una pantalla WebView deja atrás en silencio. La página se renderiza. Los botones son pulsables para usuarios videntes. Pero el árbol de accesibilidad que navega un usuario ciego es incompleto, y ese fallo es invisible para cualquiera que no use un lector de pantalla.
El mismo marcado, un resultado distinto
Una página web en Safari para móviles y la misma página en una WKWebView comparten el mismo DOM y el mismo WebKit, pero los anuncios no son iguales. Como documentaron ingenieros de accesibilidad en 2026, iOS WKWebView no respeta la cortesía de aria-live como lo hace Safari: una región urgente que interrumpe el habla actual en una pestaña de Safari se degrada a un mensaje cortés diferido dentro de una WKWebView. El usuario oye «Conexión perdida — reintentando» solo después de haber tecleado ya en el formulario roto. La única solución fiable multiplataforma es sacar los anuncios del DOM y enviarlos a la app anfitriona mediante un puente de JavaScript, y de allí devolverlos por UIAccessibility.post en iOS o announceForAccessibility() en Android. Un usuario de lector de pantalla dentro de una WebView no puede confiar en que la página le hable.
Configuraciones que la página ignora
La app nativa anfitriona lleva años respetando los ajustes de accesibilidad del sistema: escalado de fuente Dynamic Type, negrita, mayor contraste, reducción de movimiento, modo oscuro. El contenido web dentro de una WebView no hereda ninguno automáticamente. prefers-color-scheme solo se respeta si la página lo escucha; el tema oscuro de la app y la página clara de la WebView conviven una al lado de la otra. El escalado de fuente que el sistema aplica a las etiquetas nativas no llega al texto web. Cuando el anfitrión dibuja su propia barra o botón flotante sobre la WebView, el orden de lectura se vuelve no determinista entre versiones de iOS. Una guía de apps híbridas lo dice claro: aunque el texto alt sea perfecto, un usuario puede ser incapaz de pulsar un botón, oír un cambio de estado o desplazar la página.
El foco se cuela por la grieta
La gestión del foco del lector de pantalla se rompe en el límite nativo. Dentro de una WebView, document.activeElement suele devolver body o null, sobre todo tras aparecer el teclado, así que el código de seguimiento de foco falla. Mover el foco manualmente con element.focus() puede disparar el desplazamiento forzado de iOS WKWebView, que esconde el campo detrás del teclado. El resultado es un formulario que un usuario ciego no puede completar, en una pantalla que el equipo nunca probó con VoiceOver porque la QA visual pasó.
Una brecha legal, no solo de UX
Antes era un riesgo reputacional. Ahora es regulatorio. La Ley de Accesibilidad de la UE (Directiva (UE) 2019/882) es aplicable en los 27 estados miembros desde el 28 de junio de 2025 y se alinea con EN 301 549, que incorpora WCAG 2.1 Nivel AA como base para apps móviles. Cubre apps de comercio electrónico, banca, transporte y ticketing, y los reguladores pueden retirar de la distribución las apps no conformes. En junio de 2026, un tribunal francés ordenó a Carrefour hacer accesibles su web y su app móvil en seis meses o pagar 500 € por día: la primera sentencia bajo una ley de transposición de la EAA que cubre explícitamente la app. En EE. UU., la línea de casos Domino's v. Robles ya estableció que las apps deben ser accesibles bajo la ADA. Para una app de tráfico cuyas cientos de pantallas de comerciantes son HTML de terceros, cada una de esas páginas está en el ámbito de aplicación.
La solución del runtime
Un runtime propio del anfitrión no envía el HTML del comerciante y espera que los servicios de accesibilidad de la plataforma se las arreglen. Tiende el puente del árbol de accesibilidad: expone un puente autorizado para que los anuncios urgentes lleguen al stack de asistencia del sistema con fiabilidad en cada motor, mapea el escalado de fuente y el modo oscuro de la app anfitriona al contexto web para que la página los respete, y fuerza un único orden de foco y lectura determinista en el límite nativo/WebView. La accesibilidad se vuelve una propiedad que el runtime garantiza, probada con ejecuciones reales de VoiceOver y TalkBack, en lugar de un golpe de dados por página de comerciante.
| Dimensión | WebView | Runtime propio del anfitrión |
|---|---|---|
| Anuncios en regiones live | Urgente degradado a cortés en WKWebView | El puente lo entrega con fiabilidad al stack a11y |
| Ajustes del sistema | Escalado / modo oscuro / contraste ignorados | Mapeados al contexto web |
| Foco y orden de lectura | Perdidos en el límite nativo; no determinista | Orden único determinista impuesto |
| Cumplimiento | Cada página por su cuenta; exposición EAA/ADA | Auditado y probado por programa |
| Quién lo prueba | Pasa QA visual; SR no probado | VoiceOver + TalkBack en CI |
El hilo conductor de esta serie es el control. Una WebView deja subir la página de un comerciante a tu app, pero entrega su accesibilidad —y ahora su cumplimiento legal— al azar. Un runtime te la hace tuya. Para un catálogo de páginas ajenas, esa titularidad es la diferencia entre una app inclusiva y una demanda.
Fuentes
- Ley de Accesibilidad de la UE — aplicable desde 28/06/2025; alineada con EN 301 549 / WCAG 2.1 AA — cubre apps móviles; los reguladores pueden retirarlas; sentencia Carrefour (500 €/día) de junio 2026 cubre explícitamente la app.
- EN 301 549 y WCAG 2.1 AA como referencia de accesibilidad de la UE — estándar armonizado que incorpora WCAG 2.1 AA para web y móvil.
- API de accesibilidad nativa móvil: WKWebView descarta anuncios aria-live urgentes — mismo DOM, distinta canalización de anuncios; la única solución fiable es un puente JS a la app anfitriona.
- Accesibilidad HTML en apps híbridas: foco y aria-live fallan dentro de WebView — document.activeElement poco fiable; el foco manual puede esconder el campo; orden de lectura roto.
- ADA y accesibilidad web/app (precedente Domino's v. Robles) — precedente en EE. UU. de que las apps deben ser accesibles.
