Notas de la versión de Axe DevTools Mobile - 23 de octubre de 2026

Al escanear una pantalla con jerarquías de vista grandes o complejas, el axeScan comando puede tardar más de 60 segundos en completarse. El proxy WebDriverAgent (WDA) de Appium aplica un tiempo de espera predeterminado de 60 segundos a los comandos desconocidos, y axeScan cae en esa categoría. Si el escaneo no ha terminado en ese tiempo, WDA cancelará la solicitud y la prueba lanzará un error de tiempo de espera.

Para sobrescribir el tiempo de espera por comando para los comandos controlados por WDA como axeScan, recomendamos las siguientes configuraciones en tus capacidades de Appium:

• appium:commandTimeouts: 240000 (4 minutos)
• appium:wdaConnectionTimeout: 30000 (5 minutos)

Note: appium:newCommandTimeout is a different setting. It controls how long Appium waits between commands from the test script. That is not the cause of this issue. The relevant setting is appium:commandTimeouts

Si estás en Xcode 27 y ejecutas una aplicación Mobile Analyzer Desktop anterior a la 2.0.0, la aplicación no puede abrir el simulador de iOS. Falla cuando intenta iniciar /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app No puedes iniciar un escaneo basado en simulador hasta que esto se resuelva.

Para ejecutar escaneos usando un simulador en Xcode 27, actualiza el Analizador de Escritorio a la versión 2.0.0+. Con esta actualización, ten en cuenta que los resultados de accesibilidad ahora se encuentran en Axe Developer Hub.

El SDK de Axe DevTools utiliza el marco de trabajo Vision de Apple para leer el texto de la pantalla para varias reglas de accesibilidad (por ejemplo, Contraste de Color, Vistas Colisionantes, cualquier regla que dependa del texto detectado por Vision).

Vision no siempre devuelve el mismo texto detectado entre ejecuciones de la misma pantalla. Cuando Vision no capta el texto en un control, las reglas que dependen de ese texto no se ejecutarán para ese elemento en ese escaneo. Los resultados pueden parecer inconsistentes entre dos escaneos de la misma pantalla: un problema que falla en un escaneo puede estar ausente en el siguiente.

Cuando una regla basada en Vision informa un fallo, el fallo en sí es preciso. La inconsistencia está en si la regla se ejecuta o no. Para superar este problema, intenta lo siguiente:

• Vuelve a ejecutar el escaneo. Si una regla basada en Vision se omitió para un control, otro escaneo de la misma pantalla a menudo lo detecta.
• Trata cualquier fallo de regla basada en Vision como válido: si el Contraste de Color marca un control, el problema de contraste es real y debe ser abordado.
• Para la verificación manual, utiliza la referencia de Deque University para el criterio de éxito WCAG relevante. (Los enlaces se pueden encontrar al final de las páginas de cada regla.)

En iOS 26 y posteriores, si una pantalla contiene texto con un signo de porcentaje en él (por ejemplo, una etiqueta de texto que dice "50% De Descuento"), la regla de Soporte de Tipo Dinámico puede reportarse como Incompleta en lugar de aprobada o fallida. Esta regla depende de una auditoría de accesibilidad proporcionada por Apple, y esa auditoría detiene la ejecución de la prueba cuando encuentra signos de porcentaje. Para mantener tus pruebas en curso, nuestra regla omite la verificación para esa pantalla y reporta incompleto para cada elemento que contiene un signo de porcentaje. Todas las demás reglas se ejecutan normalmente en la pantalla, y otras pantallas no se ven afectadas.

No se requiere ninguna acción, ya que tu escaneo todavía se completará. Para comprobar el soporte de Tipo Dinámico para estas pantallas, aumenta el tamaño del texto en tu dispositivo bajo **Configuración** > **Accesibilidad** > **Pantalla y Tamaño de Texto** > **Texto Grande**, y confirma que el texto en la pantalla escala adecuadamente. Este problema ha sido reportado a Apple. (#2985)

La regla de Contraste de Color utiliza el marco de trabajo Vision de Apple (Reconocimiento Óptico de Caracteres, u OCR) para leer texto dentro de los límites de un elemento. OCR puede ocasionalmente identificar erróneamente glifos pequeños tipo ícono - como cheurones de flecha hacia atrás (<), 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 sólo de ícono. Debido a que la salida de OCR no es determinista en los escaneos, el mismo elemento puede aparecer en los resultados de Contraste de Color en un escaneo y ser reportado como "NO APLICABLE" en el siguiente. Esta es una característica conocida de OCR, no un error en la regla.

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

Flutter no asigna AppBar.title a la propiedad nativa del título de pantalla - UIViewController.title, causando que la regla de Título de Pantalla falle en todas las pantallas Flutter independientemente de si un título descriptivo está 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 los fondos de degradado. En tales casos, puede ser incapaz de determinar el color de primer plano y en su lugar comparar los colores de fondo entre sí, resultando en un fallo.

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

Las APIs de accesibilidad de Apple pueden reportar incorrectamente el contenido web dentro de WKWebView como "isVisible", incluso cuando la vista web está cubierta por superposiciones nativas (como vistas modales, alertas u otros elementos de UI nativos). 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 es perceptible para el usuario.

iOS 26 contiene un error de accesibilidad donde los botones de selectores predeterminados no anuncian "atenuado" por la Tecnología de Asistencia 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 informe de error a Apple, pero hasta que esto se resuelva, las siguientes reglas pueden reportar resultados en botones de selector deshabilitados: AssociatedText, InaccessibleAction, y ColorContrast.

Hasta que Apple solucione este error, la resolución será [ignorar las reglas](ios-ignore-rule). Los botones de selectores predeterminados 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 una incorrecta associatedText propiedad encontrada (#1622)

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

En las aplicaciones UIKit, una imagen sin un `accessibilityLabel` no es focalizable con tecnología asistiva por defecto.
Las propiedades que usamos para verificar la focalización de Apple pueden ser inexactas cuando se establece un `accessibilityIdentifier` en la imagen. Debido a este comportamiento inesperado, los resultados para los problemas de Nombre de ImageView en aplicaciones UIKit se reportará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 se comportan como banners, encabezados/piés de página pegajosos, botones de acción flotantes y vistas de pestañas personalizadas pueden ser marcados con un mensaje de "Necesita Revisión" o "Fallido". Para hacer que estos elementos estén disponibles para aquellos que requieren texto más grande, utiliza UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Si un UIImageView tiene un accessibilityIdentifier establecido pero no es accesible para VoiceOver, y tiene controles accesibles anidados dentro, es posible que el Nombre del Control Activo reporte un falso positivo en el 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 cercano incorrecto puede ser detectado causando que estas reglas fallen. (#1622)

El Botón de Acción Flotante (FAB) del Analizador de Accesibilidad para Android no es compatible con la navegación por deslizamiento de Talkback en versiones anteriores a la 16.2. Con el lanzamiento de la versión 16.2, Talkback solucionó un error en su código para permitir el enfoque por deslizamiento en los FAB superpuestos.

Tenga en cuenta que este es puramente un error de Talkback, que no permitía a los FAB renderizados en superposiciones de Accesibilidad ganar o perder el foco mediante deslizamiento. La reciente actualización de nuestra aplicación Analizador de Accesibilidad permite escanear más tipos de aplicaciones; por lo que puede que ahora esté viendo este problema.

Este problema puede resolverse actualizando Talkback a la versión 16.2 o posterior.

La regla Label at Front verifica que la etiqueta visible de un elemento aparezca al inicio de su texto anunciado. Puede ocurrir un fallo en la 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 consta de las palabras representadas (por ejemplo, "gigabytes", "kilómetros"), aunque este sea 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 ignorarse con seguridad. Verifique con un lector de pantalla que el anuncio completo se lea como se pretende.

Al usar texto decorativo en vistas como "Iconos 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 que esa vista de texto no es importante para la 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 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 icono y generarlas como parte de la imagen en lugar de como vistas de texto separadas. `FocusableText` no se ejecutará entonces en esas vistas.

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

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

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

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

Nuestra regla de Contraste de Color depende del Aprendizaje Automático para detectar texto, lo que asegura que el texto que se está escaneando sea visible para los usuarios de tu 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 función de texto de sugerencia pueden ver falsos positivos con la EditTextName regla. El texto de sugerencia no se introdujo 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 que esta experiencia sea 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, puede considerar evitar el uso de la hintText función, ya que no está oficialmente soportada.

Es posible que vea 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 asistencial, pero Axe DevTools Mobile aún las reporta como problemas.

Estamos trabajando en una solución para este complejo problema. Mientras tanto, si TalkBack no puede alcanzar estas vistas, puede ignorar los problemas correspondientes. No requieren una solución para garantizar 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:

La regla de Espaciado de Objetivo al Tocar actualmente no se ejecuta en ningún componente de deslizador que se haya escrito en Jetpack Compose. No se puede tomar ninguna acción en este momento. ¡Sin embargo, una solución está por llegar!

En Android API 30, uno de los lugares 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 suprimirse comentando el código en el siguiente bloque:

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 por accesibilidad, asegúrese de que esté completamente en pantalla antes de realizar el escaneo.

Introducido con la API 31 (Android 12) está la habilidad de ocultar superposiciones no del sistema. Para utilizar la app Axe Analyzer, asegúrese de que esta configuración no esté activada. Si ha optado por utilizar esta función para sus mejoras de seguridad, recomendamos mantenerla desactivada para las versiones de prueba internas donde pueda utilizar datos de prueba de manera segura y así eliminar preocupaciones de seguridad. Note: this setting does not affect Google's accessibility scanner app as it's considered a system overlay.

Para utilizar la app Axe Accessibility Analyzer, actualice 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 Mobile, asegúrese de que las capturas de pantalla estén habilitadas. Recomendamos habilitar las capturas de pantalla en una versión de prueba o debugg de su app que use datos simulados para evitar problemas de seguridad. Consulte nuestra guía para habilitar capturas de pantalla en aplicaciones de Android.

Si minimiza su compilación, verá un fallo con un registro de error informando que no se pudo encontrar un adaptador al intentar iniciar sesión en la biblioteca Axe DevTools. Desactive la minimización para sus compilaciones de depuración con Axe DevTools implementado. (#729)

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

Las APIs de Compose están obsoletas, por favor use las APIs agnósticas de diseño para continuar recibiendo actualizaciones. Si continúa usando las APIs de Compose y encuentra un error similar a `Se esperaba exactamente '1' nodo pero se encontraron '2' nodos que cumplen: (isRoot)` o `No se ha inicializado View, ¿llamó a AxeDevToolsCompose.setComposeTestRule()?`, por favor consulte la API Compose setTestTag.

Debido a las limitaciones de la arquitectura de aplicaciones MAUI al renderizar en el ecosistema de Android, la regla de Nombre de Texto de Edición aparecerá como Necesita Revisión en el panel de control cuando se sospeche de un fallo para la versión SDK 5.5.0 en adelante. Por favor confirme el comportamiento correcto manualmente para este caso.

Cuando esté implementando diálogos o modales personalizados que no extienden los controles nativos, puede 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 asegurar que se comporten con tecnología de asistencia como se desea.

Si la captura de pantalla falta en la página de detalles de escaneo, su aplicación podría estar impidiendo que se tomen capturas de pantalla. A menudo esto es por razones de seguridad en su aplicación de producción. Considere eliminar este requisito para su compilación de prueba para permitir la funcionalidad completa en el Panel de Control Móvil de Axe DevTools.

• Android - FLAG_SECURE

Algunos nombres de escaneo en Android que se establecen por defecto al título de la pantalla aparecerán como el nombre completo de la clase, incluido el identificador del paquete. En una versión futura, se resolverá esto para que el título de la pantalla esté formateado en un nombre más legible. Como solución temporal, puede establecer el nombre del escaneo desde el panel de control o los marcos. (#1643)