Notas de Lanzamiento de Axe DevTools Mobile, 20 de julio de 2026

La regla de Contraste de Color utiliza el marco Vision de Apple (Reconocimiento Óptico de Caracteres, u OCR) para leer texto dentro de los límites de un elemento. OCR puede identificar incorrectamente pequeños glifos similares a iconos - tales como chevrones de flechas invertidas (<), viñetas, símbolos decorativos - como texto. Cuando eso sucede, la regla de Contraste de Color se ejecuta en un elemento que no contiene texto legible, lo que puede producir un resultado para un botón solo con iconos. Debido a que la salida de OCR no es determinista a través de escaneos, el mismo elemento puede aparecer en los resultados de Contraste de Color en un escaneo y ser reportado como "INAPLICABLE" en el siguiente. Esto es una característica conocida del OCR, no un error en la regla.

Para resolver este problema, puedes usar las ignore APIs para suprimir los resultados de Contraste de Color para los elementos afectados.

// Ignore Color Contrast for a specific element by accessibility identifier
axeDevTools?.configuration.ignore(rulesFor: [
    "backButton": [AxeRuleId.ColorContrast.toString()]
])

Flutter no asigna AppBar.title a la propiedad de título de pantalla nativa - UIViewController.title, causando que la regla de Título de Pantalla falle en todas las pantallas de Flutter independientemente de si hay un título descriptivo presente.

Esta es una limitación conocida de la plataforma Flutter rastreada en flutter/flutter#185894.

Al ejecutar verificaciones de accesibilidad en tamaños de pantalla más pequeños o con tamaños de fuente más pequeños, la regla de Contraste de Color puede reportar falsos positivos para fondos degradados. En tales casos, puede no ser capaz de determinar el color de primer plano y en su lugar comparar los colores de fondo entre sí, resultando en un fallo.

Para resolver este problema, intenta ejecutar verificaciones de accesibilidad en dispositivos más grandes. Alternativamente, puedes optar por ignorar la regla en tus pruebas y verificar manualmente el Contraste de Color para estas vistas.

Las APIs de accesibilidad de Apple pueden reportar incorrectamente contenido web dentro de WKWebView como "isVisible", incluso cuando la vista web está cubierta por capas superpuestas nativas (como vistas modales, alertas u otros elementos de la interfaz de usuario nativa). Esto ocurre porque el sistema de accesibilidad verifica si el contenedor WKWebView en sí mismo es visible, en lugar de si su contenido web está realmente desobstruido y percibible para el usuario.

iOS 26 contiene un error de accesibilidad donde los botones predeterminados de ajuste no anuncian "atenuado" por Tecnología Asistida para indicar que no están habilitados. Como resultado, las reglas de iOS también ven estos botones como habilitados incluso si no lo están. Se ha presentado un reporte de error a Apple, pero hasta que se resuelva, las siguientes reglas pueden reportar resultados en botones de ajuste deshabilitados: AssociatedText, InaccessibleAction, y ColorContrast.

Hasta que Apple solucione este error, la resolución será [ignorar las reglas](ios-ignore-rule). Los botones predeterminados de ajuste tienen los identificadores "Decrementar" e "Incrementar", y se pueden ignorar por identificador si es necesario.

Our Color Contrast rule depends on Machine Learning to detect text, which ensures that the text being scanned is visible to users of your application. In cases where the text contained in a view is the same color as the background, our Machine Learning algorithm is unable to detect if any text is present, so the Color Contrast rule does not run on this view.

Algunas pantallas pueden reportar falsos positivos con LabelInName y LabelAtFront debido a que se encuentra una propiedad associatedText incorrecta (#1622)

Hay un problema que afecta al simulador de iPhone 15 Pro que impide que se ejecute la regla Supports Dynamic Type. Si estás inscrito en la regla Supports Dynamic Type, no podrás probarla usando un simulador de iPhone 15 Pro. Se ha presentado un error a Apple.

Mientras revisábamos una mejora para nuestras reglas, descubrimos que en XCTest, los controles anidados no se devuelven en el árbol de accesibilidad. Se ha presentado un error a Apple. (#1110)

En las aplicaciones de UIKit, una imagen sin una `accessibilityLabel` no es accesible con tecnología de asistencia por defecto.
Las propiedades que usamos para verificar la accesibilidad desde Apple pueden ser inexactas cuando se establece un `accessibilityIdentifier` en la imagen. Debido a este comportamiento inesperado, los resultados de problemas de Nombre de ImageView en aplicaciones de UIKit se informarán como Necesita Revisión. Se ha presentado un informe de error a Apple. (#1633)

Estamos trabajando activamente en soluciones para los siguientes falsos positivos y actualizaremos esta lista a medida que se publiquen las correcciones.

In Scroll View
El texto dentro de elementos que funcionan como banners puede ser marcado con un mensaje de "Necesita Revisión". Para hacer que estos elementos estén disponibles para aquellos que requieren texto más grande, use UILargeContentViewer. (#622)

v2.11.0 Image View Name & Active Control Name
Si una UIImageView tiene un `accessibilityIdentifier` establecido pero no es accesible por VoiceOver, y tiene controles accesibles anidados dentro, ActiveControlName puede reportar un falso positivo en la UIImageView. Eliminar el `accessibilityIdentifier` resuelve el problema. Se ha presentado un informe de error a Apple. (#1633)

Label In Name and Label At Front
Estas dos reglas buscan la etiqueta visible de un control entre los elementos cercanos para ayudar a determinar el estado de la regla. En algunas jerarquías de vista, el texto incorrecto cercano puede ser detectado causando que estas reglas fallen. (#1622)

La regla Etiqueta al Frente verifica que la etiqueta visible de un elemento esté al inicio de su texto anunciado. Puede ocurrir fallo de regla cuando el texto visible de un elemento interactivo contiene una abreviatura (por ejemplo, "GB", "km") o un identificador oculto/truncado, y el anuncio de accesibilidad consiste en las palabras representadas (por ejemplo, "gigabytes", "kilómetros"), incluso aunque este es el patrón recomendado para hacer que el contenido abreviado o truncado sea amigable para los lectores de pantalla.

Si la primera parte de la etiqueta visible de un elemento interactivo coincide con el inicio del anuncio del lector de pantalla y solo la parte abreviada/oculta difiere, el resultado marcado puede ser ignorado con seguridad. Verifique con un lector de pantalla que el anuncio completo se lea como se espera.

Al usar texto decorativo en vistas como "Íconos de Contacto", es posible introducir un problema de accesibilidad. Si está utilizando una vista de texto para mostrar letras en lugar de generar imágenes con las letras deseadas como vectores, y luego declara esa vista de texto como no importante para accesibilidad, no podremos determinar de manera confiable si ha introducido una violación de accesibilidad.

Si edita texto enfocable para ignorar dos o menos caracteres, puede inadvertidamente ignorar muchos botones de una sola palabra en varios idiomas (por ejemplo, "OK", "No", "Sí"). Para evitar estos problemas, debe tomar las letras deseadas de la palabra que desea representar en el ícono y generar las letras como parte de la imagen en lugar de como vistas de texto separadas. `FocusableText` entonces no se ejecutará en esas vistas.

Flutter no asigna AppBar.title a la propiedad de título de pantalla nativa - Activity.setTitle, causando que la regla de Título de Pantalla falle en todas las pantallas Flutter independientemente de si hay un título descriptivo presente.

Esta es una limitación conocida de la plataforma Flutter registrada en flutter/flutter#185894.

En algunos casos, la tecnología de asistencia depende de AccessibilityEvent descripciones del sistema Android para anunciar información al usuario cuando no está disponible ningún otro anuncio. Dado que AccessibilityEvents se desencadenan por acciones del usuario, no podemos acceder a la descripción correcta si esta información no se proporciona.

Para evitar este problema, asegúrese de que todas las vistas relevantes estén marcadas como importantes para accesibilidad. Esto permitirá que TalkBack acceda a la información desde la vista, que nuestra herramienta podrá detectar.

Nuestra regla de Contraste de Color depende del Aprendizaje Automático para detectar texto, lo que asegura que el texto que se escanea sea visible para los usuarios de su aplicación. En los casos donde el texto contenido en una vista es del mismo color que el fondo, nuestro algoritmo de Aprendizaje Automático no puede detectar si hay texto presente, por lo que la regla de Contraste de Color no se ejecuta en esta vista.

Las aplicaciones escritas con XML que utilizan la característica de texto de sugerencia pueden ver falsos positivos con la EditTextName regla. El texto de sugerencia no fue introducido hasta Android 8 (SDK 26). Usar este elemento en su aplicación XML asignará el texto de sugerencia al valor del campo de entrada de texto. Las versiones más recientes de Android están mejor equipadas para hacer esta experiencia accesible.

Para superar este problema, nuestra primera recomendación es ejecutar sus pruebas en versiones más recientes de Android. Sin embargo, si es importante que la aplicación sea accesible en versiones anteriores de Android, podría considerar evitar el uso de la hintText característica, ya que no está oficialmente soportada.

Puede ver resultados para vistas que están ocultas detrás de otras vistas en la pantalla. Estas vistas ocultas no están disponibles para la tecnología de asistencia, pero Axe DevTools Mobile todavía las reporta como problemas.

Estamos trabajando en una solución para este problema complejo. Mientras tanto, si TalkBack no puede alcanzar estas vistas, puede ignorar los problemas correspondientes. No requieren una solución para asegurar la accesibilidad.

La detección de texto de ML Kit es necesaria en muchas de las reglas de Axe DevTools Mobile para asegurar la precisión de los resultados. La biblioteca ML Kit debería importarse automáticamente al referenciar Axe DevTools Mobile en sus pruebas automatizadas de Espresso o UIAutomator. Sin embargo, en algunos casos, la importación automática no ocurre y verá el siguiente error en el logcat:

Axe DevTools Android: Error while running mlKit Text Detection: MlKitContext has not been initialized.

Para superar este problema, debe importar manualmente la biblioteca ML Kit en su proyecto. En el archivo de su aplicación build.gradle agregue lo siguiente bajo dependencias:

debugImplementation 'com.google.mlkit:text-recognition:16.0.1'

La regla de Espaciado de Objetivo Táctil actualmente no se ejecuta en ningún componente deslizante que fue escrito en Jetpack Compose. No se puede tomar ninguna acción en este momento. ¡Sin embargo, una solución viene pronto!

En Android API 30, una de las ubicaciones donde intentamos guardar los resultados localmente tiene un error de permisos. El resultado aún se guardará como un archivo JSON a pesar de que este error se muestre. El error puede ser suprimido comentando el código en el siguiente bloque:

def clearDirectoryTask = task('clearDirectoryTask', type: Exec, group: 'reporting') {
	executable "${android.getAdbExecutable().toString()}"
	args 'shell', 'rm', '-r', '/storage/emulated/0/Documents/AxeTestCases'

En algunas aplicaciones híbridas y multiplataforma, podemos devolver resultados inesperados cuando los elementos en una vista de desplazamiento están parcialmente fuera de la pantalla. Para probar un elemento de accesibilidad, asegúrese de que esté completamente en pantalla antes de realizar la exploración.

Introducida con la API 31 (Android 12) está la capacidad de ocultar las superposiciones no pertenecientes al sistema. Para utilizar la aplicación Axe Analyzer, asegúrate de que esta configuración no esté activada. Si has optado por utilizar esta función por sus mejoras de seguridad, recomendamos dejarla desactivada para las compilaciones de pruebas internas donde puedes usar datos de prueba de manera segura y eliminar las preocupaciones de seguridad de esa manera. Note: this setting does not affect Google's accessibility scanner app as it's considered a system overlay.

Para utilizar la aplicación Axe Accessibility Analyzer, actualiza cualquier llamada al método setHideOverlayWindows(true) a setHideOverlayWindows(false) en las ventanas de actividad afectadas.

Para desbloquear la funcionalidad completa de Axe DevTools para móviles, asegúrate de que las capturas de pantalla estén habilitadas. Recomendamos habilitar las capturas de pantalla en una versión de depuración o prueba de tu aplicación que use datos simulados para evitar preocupaciones de seguridad. Consulta nuestra guía para habilitar capturas de pantalla en aplicaciones Android.

Si minimizas tu compilación, verás un error con un registro de errores que informa que no se pudo encontrar un adaptador al intentar iniciar sesión en la biblioteca Axe DevTools. Desactiva la minificación para tus compilaciones de depuración con Axe DevTools implementado. (#729)

Una compilación con r8 habilitado puede intentar minimizar la biblioteca axeDevTools, lo que resulta en un error similar a:

Caused by: java.lang.NullPointerException: throw with null exception
at g.b.b.a$a.a(Unknown Source:1)
at g.b.b.a$a.a(Unknown Source:0)
at g.b.b.a.a(AccessToken.java:190)
	

Las APIs de Compose están obsoletas, utiliza las APIs independientes de diseño para continuar recibiendo actualizaciones. Si continúas usando las APIs de Compose y encuentras un error como `Se esperaban exactamente '1' nodo pero se encontraron '2' nodos que satisfacen: (isRoot)` o `No se ha inicializado la vista, ¿llamaste a AxeDevToolsCompose.setComposeTestRule()?`, consulta la API Compose setTestTag.

Debido a las limitaciones de la arquitectura de aplicaciones MAUI al renderizar en el ecosistema Android, la regla de Nombre de Texto Editado aparecerá como Necesita revisión en el tablero cuando se sospeche de un fallo para la versión SDK 5.5.0 y superiores. Por favor confirma el comportamiento correcto manualmente para este caso.

Cuando implementas diálogos o modales personalizados que no extienden los controles nativos, puedes obtener resultados para vistas detrás del modal. En este caso, recomendamos no ejecutar nuestra herramienta contra estos modales o diálogos personalizados y en su lugar verificarlos manualmente para asegurarte de que se comportan con la tecnología de asistencia como se desea.

Si falta la captura de pantalla en la página de detalles de análisis, es posible que tu aplicación esté impidiendo que se tomen capturas de pantalla. A menudo esto sucede por razones de seguridad en tu aplicación de producción. Considera eliminar este requisito para tu compilación de prueba para permitir la funcionalidad completa en el tablero móvil de Axe DevTools.

• Android - FLAG_SECURE

Algunos nombres de análisis de Android que se predeterminan al título de la pantalla aparecerán como el nombre completo de la clase, incluyendo el identificador del paquete. En una futura versión, esto será resuelto para que el título de la pantalla se formatee en un nombre más legible. Como solución provisional, puedes establecer el nombre del análisis desde el tablero o los frameworks. (#1643)