Todo elemento visible en una pantalla de iOS tiene, o puede tener, una representación de accesibilidad. Apple incluye esa representación a través del protocolo informal UIAccessibility, implementado por UIView y todos los controles del sistema, y a través de UIAccessibilityElement, una clase ligera que se asigna para las partes de la interfaz que se dibujan pero que no son vistas en sí mismas: caracteres en un gráfico dibujado a medida, glifos dentro de una escena de Core Graphics, regiones dentro de un CALayer. VoiceOver, Switch Control, Acceso completo con teclado y Control por voz consumen el mismo protocolo; aprenderlo una vez da acceso a cuatro tecnologías de apoyo.

El protocolo expone cuatro primitivos relevantes en casi cualquier pantalla. La etiqueta de accesibilidad es el nombre breve y legible del elemento: «Enviar», «Foto de perfil de Asha», «Atrás». Los rasgos de accesibilidad son una máscara de bits de indicadores similares a roles — .button, .header, .image, .selected, .adjustable, .staticText, .updatesFrequently — que indican a VoiceOver cómo comportarse con el elemento y qué gestos activar. El valor de accesibilidad es una representación de cadena del estado actual («Activado», «75 %», «Jueves, 22 de mayo»). La sugerencia de accesibilidad es la explicación más extensa y opcional («Pulsa dos veces para abrir el visor de fotos») que VoiceOver pronuncia tras una pausa si el usuario no actúa solo con la etiqueta.

Los cuatro primitivos se combinan. Un interruptor se anuncia como etiqueta + rasgo + valor: «Wi-Fi, botón interruptor, Activado». Un control deslizante se anuncia como etiqueta + rasgo + valor + sugerencia: «Volumen, ajustable, 60 por ciento, desliza hacia arriba o abajo para ajustar». Una barra de un gráfico dibujada a medida se representa como una cadena de UIAccessibilityElement, cada uno con una etiqueta, un valor y un marco dentro de su contenedor. La cadena es la superficie de la API: VoiceOver la recorre linealmente cuando el usuario desliza a la derecha y respeta el orden en que los elementos se publican a través del array accessibilityElements del contenedor.

Android sigue un camino diferente. Donde iOS incorpora la accesibilidad como un protocolo plano en cada vista, Android serializa el árbol de accesibilidad completo como un grafo de objetos AccessibilityNodeInfo, siendo cada uno una instantánea de una vista en el momento en que llega una consulta de TalkBack. El sistema construye las instantáneas de forma perezosa; un View publica su nodo sobreescribiendo onInitializeAccessibilityNodeInfo() (o, en Compose, estableciendo modificadores de semántica), y la plataforma ensambla las relaciones padre-hijo en un árbol que refleja la jerarquía de vistas.

Los primitivos difieren de los de iOS en tres aspectos significativos. Primero, Android expone un rol mediante un campo className de tipo cadena: android.widget.Button, android.widget.CheckBox, android.widget.EditText. TalkBack lee el nombre de la clase y decide cómo anunciarlo («botón», «casilla de verificación», «cuadro de edición»). Compose traduce sus semánticas Role.Button, Role.Checkbox, Role.RadioButton al mismo campo. El rol es más granular que una máscara de bits de rasgo de iOS, pero también más rígido: no existe un rol «totalmente personalizado» a menos que se acepte el anuncio como «vista».

Segundo, Android representa la interactividad como un conjunto de acciones vinculadas al nodo: ACTION_CLICK, ACTION_LONG_CLICK, ACTION_SCROLL_FORWARD, ACTION_SET_TEXT, ACTION_FOCUS, y una larga lista de acciones personalizadas que se pueden registrar con AccessibilityNodeInfo.AccessibilityAction. TalkBack muestra las acciones personalizadas a través del «rotor de acciones»: el usuario desliza hacia arriba con un dedo y escucha cada acción personalizada por su nombre. iOS tiene el mismo concepto (UIAccessibilityCustomAction), pero en Android la lista de acciones es la superficie; en iOS lo es el vocabulario de gestos.

Tercero, Android dispone de importantForAccessibility, un enum por vista (auto, yes, no, noHideDescendants) que controla si el nodo aparece en el árbol en absoluto. noHideDescendants es la herramienta más poderosa en accesibilidad Android y la que más frecuentemente se olvida: elimina todo el subárbol del recorrido de TalkBack, el equivalente de aria-hidden=“true” en la web. iOS no tiene un equivalente exacto; lo más cercano es establecer accessibilityElements en un array vacío en el contenedor, lo que solo elimina los hijos directos del contenedor, no todo el subárbol.

Todo marco de desarrollo móvil multiplataforma debe tomar las dos API anteriores y presentar una superficie única con la forma del marco. Ninguno lo logra por completo. Los tres enfoques dominan el mercado en 2026 — React Native, Flutter y Kotlin Multiplatform con Compose Multiplatform — y cada uno representa un compromiso ligeramente distinto entre abstracción y filtración de detalles nativos.

El patrón es el mismo en los tres casos: un árbol semántico sintético con la forma del marco en un lado, dos árboles de accesibilidad con la forma de la plataforma en el otro, y un traductor intermedio que resuelve bien los casos simples y los complejos con una pérdida notable de fidelidad. Los casos simples — un botón con etiqueta, una imagen con texto alternativo, un encabezado — se traducen sin pérdida. Los casos complejos — un gesto personalizado con dos dedos, un gráfico cuyos elementos deberían ser un grupo enfocable, una live region que debe activarse en iOS sin un ajuste de cortesía vinculado a la vista — filtran el vocabulario de la plataforma subyacente hacia el código multiplataforma, o simplemente no se traducen.

Tanto iOS como Android renderizan contenido web a través de un WebView del sistema: WKWebView en iOS y android.webkit.WebView (o Chrome Custom Tabs) en Android. En ambos casos, el WebView es una caja negra desde la perspectiva de la aplicación host: la aplicación ve una única vista, pero el lector de pantalla ve el árbol de accesibilidad DOM completo en su interior. El puente entre los dos árboles es el punto donde una cantidad sorprendente de accesibilidad móvil falla silenciosamente.

El mecanismo es, en apariencia, sencillo. Cuando el foco del lector de pantalla entra en un WebView, la plataforma lee el árbol de accesibilidad del documento directamente desde el motor del navegador — WebKit en iOS, Blink en Android — y lo recorre como un subárbol del árbol de la aplicación host. Los roles, las etiquetas y los atributos ARIA de la web se traducen al vocabulario de la plataforma en tiempo real. Un elemento button sin rol explícito dentro del WebView se anuncia como botón en ambas plataformas; una región aria-live=“polite” se anuncia correctamente en ambas; un aria-label en un enlace aparece como la etiqueta de accesibilidad del enlace. Durante los tres primeros años de la web móvil, esto simplemente funcionaba.

El fallo aparece en tres puntos. Primero, los gestos personalizados definidos en la aplicación host — un deslizamiento con dos dedos para cerrar, un magic tap para reproducir y pausar — son invisibles para el contenido del WebView; se activan en el objetivo incorrecto o no se activan en absoluto cuando el foco está dentro del documento. Segundo, los UIAccessibilityElement de la aplicación host dibujados sobre el WebView (un botón de acción flotante, una barra de herramientas personalizada) compiten con el árbol del WebView por el orden de recorrido, y el orden de lectura resultante es no determinista entre versiones de iOS. Tercero — y este es el mayor modo de fallo individual en la accesibilidad web móvil — el WebView en iOS no respeta los niveles de cortesía de aria-live de la misma manera que Safari en una pestaña: el mecanismo de anuncios de WKWebView elimina la distinción entre polite y assertive, por lo que toda actualización en vivo se trata como polite independientemente del marcado.

Hemos mapeado 28 primitivos que VoiceOver y TalkBack consumen realmente en la práctica: la unión de la superficie del protocolo UIAccessibility de iOS, la superficie AccessibilityNodeInfo de Android y los props multiplataforma más utilizados de React Native y Flutter. La tabla siguiente captura solo las filas conflictivas: los primitivos cuyo mapeo es incompleto, asimétrico o sorprendente. Las filas con mapeo limpio (etiqueta, rol de botón, rol de imagen, encabezado) se han omitido por extensión.

Tres patrones destacan en la tabla. Primero, la asimetría en torno a las live regions es la mayor fuente de divergencia multiplataforma: Android tiene un ajuste de cortesía por vista, iOS solo tiene un post imperativo global, y todos los marcos anteriores se ven obligados a disimular la diferencia. Segundo, los niveles de encabezado son el único punto en que Flutter mejora genuinamente a ambas plataformas nativas; los primitivos de iOS y Android solo saben «esto es un encabezado», no «esto es un H3 bajo un H2». Tercero, el primitivo «ocultar de la accesibilidad» es más flexible en Android que en iOS: noHideDescendants oculta un subárbol completo en un solo movimiento, mientras que iOS requiere ocultar individualmente los hijos de cada contenedor.

Es tentador creer — y la documentación de los marcos alienta esta creencia — que una API de accesibilidad multiplataforma es una abstracción única y unificada sobre dos API nativas equivalentes. La tabla de correspondencias de la sección 5 refuta esa unificación. Las dos API nativas fueron diseñadas de forma independiente, por dos equipos distintos, en torno a dos modelos mentales diferentes de cómo el lector de pantalla debe recorrer un documento; las diferencias son reales, se filtran a través de todos los marcos, y la filtración aparece en las partes de la experiencia de usuario que más importan: actualizaciones en vivo, gestos personalizados, subárboles ocultos, jerarquías de encabezados.

La buena noticia, tras ese párrafo: lo básico funciona. Un botón con etiqueta, una imagen con texto alternativo, un encabezado al inicio de una sección — todo eso se traduce a través de todos los marcos y se anuncia correctamente en ambas plataformas. Si solo se usan esos primitivos, no es necesario pensar en UIAccessibility ni en AccessibilityNodeInfo; los valores predeterminados del marco son honestos. El problema comienza cuando la interfaz de usuario empieza a hacer algo interesante, que es también cuando la accesibilidad empieza a importar más.

El manual de la sección 6 es la versión más breve del argumento que lleva la experiencia funcional al mayor número de usuarios con discapacidad: pensar primero en primitivos nativos, probar en dispositivos reales en ambas plataformas, enrutar fuera de WebViews cuando se necesita, agrupar nodos hoja deliberadamente y usar los inspectores oficiales. El marco elegido ayuda con el primer 80 por ciento y se aparta del camino para el 20 por ciento restante. Ese 20 por ciento restante es donde vive el usuario de lector de pantalla.