Notas de la versión de Axe DevTools Mobile de agosto de 2026

This page is not available in the language you requested. You have been redirected to the English version of the page.
Link to this page copied to clipboard

Agosto de 2026

Not for use with personal data

Versiones de componentes

Appium

iOS

  • Controlador iOS Appium 2 (axe-appium2-xcuitest-driver v2.6.0)
    • (Derivado de XCUITest v9.10.4)
  • Controlador iOS Appium 3 (axe-appium3-xcuitest-driver v1.5.0)
    • (Derivado de XCUITest v12.1.3)

Cómo actualizar: Controlador iOS Appium

Android

  • Controlador Android Appium 2 (axe-appium2-uiautomator2-driver v2.6.0)
    • (Derivado de UiAutomator2 v4.2.8)
  • Controlador Android Appium 3 (axe-appium3-uiautomator2-driver v1.5.0)
    • (Derivado de UiAutomator2 v8.2.2)

Cómo actualizar: Controlador Android Appium

¿Qué hay de nuevo?

Controladores Appium

¿Está utilizando Auto Scan con alguno de nuestros controladores Appium? Ahora puede pausar la sesión activa de Auto Scan antes de una pantalla que no debe incluirse en los resultados del escaneo. Puede reanudar la sesión de escaneo después de pasar por pantallas sensibles. Encuentre detalles y ejemplos de implementación para Auto Scan con Appium.

Problemas conocidos

Si está experimentando alguno de los problemas a continuación, comuníquese con nosotros en helpdesk@deque.com o support.deque.com. Podremos notificarle una vez que se haya resuelto o de una solución alternativa identificada si no hay una listada.

important
  • Las pruebas automatizadas de Axe DevTools Mobile se ejecutan en aplicaciones nativas de iOS, Android nativo y React Native. Comuníquese con su representante de Deque para obtener soluciones de prueba de accesibilidad en su pila tecnológica.
  • Aunque puede obtener algunos resultados de vistas web o PDFs renderizados, le recomendamos encarecidamente realizar pruebas utilizando Axe DevTools para Web o Axe Monitor para las pruebas de accesibilidad más completas para la web.

iOS

Resultados incompletos para la regla Soporte de Tipo Dinámico en pantallas con signos de porcentaje en el texto

En iOS 26 y posteriores, si una pantalla contiene texto con un signo de porcentaje (por ejemplo, una etiqueta de texto que dice "50% de descuento"), la regla Soporte de Tipo Dinámico puede informarse como Incompleta en lugar de un aprobado o un fallo. Esta regla se basa en 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 sus pruebas en ejecución, nuestra regla omite la verificación para esa pantalla e informa como incompleta para cada elemento que contenga 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 su escaneo aún se completará. Para verificar el soporte de Tipo Dinámico para estas pantallas, aumente el tamaño del texto en su dispositivo en **Configuración** > **Accesibilidad** > **Pantalla y tamaño de texto** > **Texto grande**, y confirme que el texto en la pantalla se escala adecuadamente. Este problema ha sido reportado a Apple. (#2985)

El Contraste de Color puede ejecutarse en elementos solo de íconos debido a OCR

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. El OCR ocasionalmente puede identificar erróneamente pequeños glifos tipo icono, como chevrones de flechas hacia atrás (<), viñetas, símbolos decorativos, como texto. Cuando eso ocurre, la regla de Contraste de Color se ejecuta en un elemento que no contiene texto legible, lo que puede producir un resultado en un botón solo de icono. Debido a que la salida del 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 del OCR, no un error en la regla.

Para solucionar este problema, puede utilizar 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()]
])

// Or ignore Color Contrast globally
axeDevTools?.configuration.ignore(rule: AxeRuleId.ColorContrast.toString())

Aprenda más sobre ignorar reglas.

Falso positivo de Título de Pantalla en aplicaciones Flutter

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

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

Falsos positivos para la regla de Contraste de Color con fondos de gradiente en pantallas pequeñas

Al realizar 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 de gradiente. En tales casos, puede no ser capaz de determinar el color de primer plano y comparar los colores de fondo entre sí, resultando en un fallo.

Para solucionar este problema, intente ejecutar las verificaciones de accesibilidad en dispositivos más grandes. Alternativamente, puede optar por ignorar la regla en sus pruebas y verificar manualmente el Contraste de Color para estas vistas.

Inexactitud isVisible propiedad de XCTest

Es posible que las API de accesibilidad de Apple informen incorrectamente sobre 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 la interfaz de usuario nativa). Esto ocurre porque el sistema de accesibilidad verifica si el contenedor de WKWebView en sí es visible, en lugar de si su contenido web está realmente libre de obstáculos y es perceptible para el usuario.

Error de accesibilidad en iOS 26 con controles de incremento

iOS 26 contiene un error de accesibilidad donde los botones de incremento predeterminados no anuncian "atenuado" mediante 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 informar resultados en botones de incremento deshabilitados: AssociatedText, InaccessibleAction, y ColorContrast.

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

Color Contrast rule does not run when text and background colors are the same

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.

Falso positivo: LabelInName y LabelAtFront en SwiftUI y aplicaciones multiplataforma

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

Reglas contra controles anidados

Al revisar 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)

La regla del Nombre de ImageView necesita revisar resultados para aplicaciones UIKit

En las aplicaciones UIKit, una imagen sin un `accessibilityLabel` no es accesible con tecnología de asistencia por defecto.
Las propiedades que utilizamos para verificar la capacidad de enfoque 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 informarán como Necesitan Revisión. Se ha presentado un informe de error a Apple. (#1633)

Falso positivo: En Scroll View, Label In Name, Label at Front, y v2.11.0 Image View Name & ActiveControlName

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/pie de páginas fijos, botones de acción flotantes y vistas de pestañas personalizadas puede ser marcado 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, use UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Si un UIImageView tiene un accessibilityIdentifier establecido pero no es accesible por VoiceOver, y tiene controles enfocados anidados dentro de él, Active Control Name puede reportar 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 vistas, se puede detectar texto cercano incorrecto, causando que estas reglas fallen. (#1622)

Android

Falsos positivos de Label at Front con texto visible oscurecido

La regla Label at Front verifica que la etiqueta visible de un elemento esté al comienzo del texto anunciado. Un fallo en la regla puede resultar cuando el texto visible de un elemento interactivo contiene una abreviatura (por ejemplo, "GB", "km") o un identificador oscurecido/truncado, y el anuncio de accesibilidad consiste en las palabras representadas (por ejemplo, "gigabytes", "kilómetros"), incluso 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 comienzo del anuncio del lector de pantalla y solo la parte abreviada/oscurecida difiere, el resultado marcado se puede ignorar de manera segura. Verifique con un lector de pantalla que el anuncio completo se lea como está previsto.

Posibles preocupaciones de accesibilidad para texto enfocables

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 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 enfocables 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 generarlas como parte de la imagen en lugar de como vistas de texto separadas. `FocusableText` entonces no se ejecutará en esas vistas.

Falso positivo de Título de Pantalla en aplicaciones Flutter

Flutter no asigna AppBar.title a la propiedad de título de pantalla nativo - Activity.setTitle, 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.

Detección de texto anunciado falso positivo

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 se activan 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 la accesibilidad. Esto permitirá que Talkback acceda a la información de la vista, que nuestra herramienta podrá detectar.

La regla de Contraste de Color no se ejecuta cuando los colores del texto y del fondo son iguales

Nuestra regla de Contraste de Color depende del Aprendizaje Automático para detectar texto, lo que garantiza que el texto que se escanea sea visible para los usuarios de su aplicación. En los casos en que el texto contenido en una vista sea 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.

EditTextName en Android 7 (SDK 24-25)

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 esta experiencia accesible.

Para superar este problema, nuestra primera recomendación es ejecutar tus 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ías considerar evitar el uso de la hintText característica, ya que no está oficialmente soportada.

Vistas ocultas de Android devolviendo resultados

Es posible que veas 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 acceder a estas vistas, puedes ignorar los problemas correspondientes. No requieren una solución para garantizar la accesibilidad.

Error al ejecutar la detección de texto de ML Kit

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


Axe DevTools Android: Error al ejecutar la detección de texto de mlKit: MlKitContext no ha sido inicializado.

Para superar este problema, debes importar la biblioteca ML Kit en tu proyecto manualmente. En el build.gradle archivo de tu aplicación, añade lo siguiente bajo dependencias:

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

Encuentra un ejemplo completo de la biblioteca ML Kit siendo importada en la sección de Introducción del SDK Móvil de Android, bajo Implementación

Espaciado de objetivos táctiles y Jetpack Compose

La regla de Espaciado de Objetivos Táctiles actualmente no se ejecuta en ningún componente deslizante que haya sido escrito en Jetpack Compose. No se puede tomar ninguna medida en este momento. ¡Sin embargo, pronto llegará una solución!

Error al guardar los resultados localmente en API 30

En Android API 30, una de las ubicaciones en las que intentamos guardar los resultados localmente tiene un error de permisos. El resultado aún se guardará como un archivo JSON a pesar de que se muestre este error. 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'

//    finalizedBy {
//        fetchAndroidFolderAxeReportsTask
//    }
}

Por favor, ten en cuenta que este código solo debe comentarse para API 30, ya que causará problemas al guardar localmente para otros niveles de API.

Detección de desplazamiento en aplicaciones híbridas y multiplataforma

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

App Analyzer: El botón de acción flotante desaparece

Introducida con la API 31 (Android 12) está la capacidad de ocultar superposiciones no sistemáticas. 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 prueba internas donde puedes utilizar datos de prueba con seguridad y eliminar 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 actividades afectadas.

Captura de pantalla faltante (Cuadro Negro) en el Dashboard

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

Fallo al minifiedEnabled establecer como verdadero

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

Las compilaciones con r8 habilitado lanzan un error

Una compilación con r8 habilitado puede intentar minimizar la biblioteca axeDevTools, resultando 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)

Para resolver este error, añade la siguiente línea a tu archivo ProGuard para mantener las clases de axeDevTools:

keep class com.deque.** { *; }
Mensajes de error al usar APIs de Compose

Las APIs de Compose están obsoletas, por favor usa las APIs agnósticas de disposición para continuar recibiendo actualizaciones. Si continúas usando las APIs de Compose y encuentras un error similar a `Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)` o `No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?`, por favor consulta API Compose setTestTag.

MAUI: Regla de Nombre de Texto de Edición

Debido a las limitaciones de la arquitectura de la aplicación 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 cuando se sospeche un error para la versión del SDK 5.5.0 en adelante. Por favor, confirma el comportamiento correcto manualmente para este caso.

Android Nativo: Diálogos / Modales Personalizados

Cuando implementes diálogos o modales personalizados que no extienden los controles nativos, es posible que obtengas 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 funcionen con la tecnología asistencial según lo deseado.

Panel Web

Captura de pantalla faltante

Si la captura de pantalla falta en la página de detalles del escaneo, tu aplicación podría estar impidiendo que se tomen capturas de pantalla. A menudo esto se debe a razones de seguridad en tu aplicación de producción. Considera eliminar este requisito para tu versión de prueba para permitir la funcionalidad completa en el Panel de Axe DevTools Mobile.

Algunos nombres de escaneo de Android no están formateados

Algunos nombres de escaneo 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 se resolverá para que el título de la pantalla se formatee en un nombre más legible. Como solución temporal, puedes establecer el nombre del escaneo desde el panel o frameworks. (#1643)