Notas de la versión de Axe DevTools Mobile del 5 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

5 de agosto de 2026

Not for use with personal data

iOS

  • iOS SDK (axeDevToolsXCUI v4.1.0)
  • Aplicación de Escritorio iOS Analyzer (axe-devtools-mobile-desktop-app v1.3.0)

Cómo actualizar: iOS SDK, Aplicación de Escritorio iOS Analyzer

Android

  • Android SDK (axe-devtools-android v9.1.0)
  • Plugin de Gradle Android (axe-devtools-android-plugin v1.2.0)
  • Analizador Android (Axe Accessibility Analyzer v3.2.0)

Cómo actualizar Plugin de Gradle Android, Analizador Android

¿Qué hay de nuevo?

Saltar pantallas al ejecutar Auto Scan

¿Usas Auto Scan con nuestros SDKs? Ahora puedes omitir pantallas que no deberían incluirse en los resultados del escaneo envolviendo secciones con AxeAutoScan.skipScan. La sesión de escaneo se reanuda automáticamente cuando el bloque termina. Encuentra detalles de implementación de Auto Scan en las siguientes páginas:

Cobertura aumentada de WCAG

Deque mantiene su compromiso de ofrecer y optimizar reglas que detecten con precisión problemas reales de accesibilidad. Con esta versión, estamos ampliando nuestra cobertura de WCAG 2.0 promocionando dos reglas que anteriormente estaban marcadas como experimentales.

iOS

La regla Soporte para Dynamic Type ha pasado a ser una regla completa. Esta regla se corresponde con WCAG 2.0, 1.4.4 Redimensionar Texto (AA) y ahora se ejecuta por defecto, mientras que antes era optativa. Dynamic Type es una función de iOS que permite a los usuarios establecer un tamaño de fuente preferido a nivel del dispositivo. Esta regla verifica que las aplicaciones respeten esa preferencia usando fuentes escalables. Ten en cuenta que esta regla se ejecuta en la API de Auditoría de Accesibilidad de XCUI de Apple, que requiere iOS 17.0+. La regla Soporte para Dynamic Type se ejecuta solo durante pruebas dirigidas. ¡El soporte para Auto Scan llegará pronto!
Más información sobre esta regla de accesibilidad: Soporte para Dynamic Type.

Android

La regla Acción Inaccesible para Android ha pasado a ser una regla completa, ampliando nuestra cobertura de WCAG 2.0, 2.1.1 Teclado (A). Esta regla verifica que la acción asociada con un elemento interactivo puede ser tanto enfocada y desencadenada por tecnologías de asistencia como TalkBack o Switch Access.
Más información sobre esta regla de accesibilidad: Acción Inaccesible.

Correcciones

iOS

  • Mejoras en la precisión de la regla de Texto Recortado

Android

  • Mejoras en la precisión de las siguientes reglas: Texto Enfocable, Nombre de Texto de Edición, Acción Inaccesible, y Elemento Enfocable Anidado

Deprecaciones y Eliminaciones

iOS

La propiedad optInToSupportsDynamicType está obsoleta. La regla Soporte para Dynamic Type ahora se ejecuta por defecto. Si anteriormente optaste por usar esta regla, por favor elimina la propiedad de tu código.

Android

Las reglas de Control Activo Anidado y Nombre de Elemento Anidado han sido desactivadas, y ya no verás estos problemas señalados en tus resultados. Ambas reglas serán eliminadas - al menos temporalmente - en una fecha posterior.

Problemas Conocidos

Si estás experimentando alguno de los problemas mencionados a continuación, por favor contáctanos en helpdesk@deque.com o support.deque.com. Podremos notificarte una vez que se resuelva o de un posible solucionario identificado si no se encuentra listado.

important
  • Las pruebas automatizadas de Axe DevTools Mobile se ejecutan en aplicaciones nativas iOS, nativas Android y React Native. Por favor, contacta a tu representante de Deque para obtener soluciones de pruebas de accesibilidad en tu stack tecnológico.
  • Aunque puedes obtener algunos resultados de vistas web o PDF renderizados, recomendamos altamente realizar pruebas con Axe DevTools para Web o Axe Monitor para obtener las pruebas de accesibilidad más completas para la web.

iOS

Resultados incompletos para la regla Soporte para Dynamic Type 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 para Dynamic Type puede reportarse como Incompleta en lugar de un aprobado o fallo. Esta regla depende de una auditoría de accesibilidad proporcionada por Apple, y dicha auditoría detiene la ejecución de pruebas cuando encuentra signos de porcentaje. Para mantener tus pruebas en ejecución, nuestra regla omite la verificación de 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 las demás pantallas no se ven afectadas.

No se requiere ninguna acción, ya que tu escaneo aún se completará. Para verificar el soporte de Dynamic Type en estas pantallas, aumenta el tamaño del texto en tu dispositivo en **Configuración** > **Accesibilidad** > **Pantalla y Tamaño de Texto** > **Texto Grande**, y confirma 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 con íconos debido al OCR

La regla de Contraste de Color utiliza el marco de Vision de Apple (Reconocimiento Óptico de Caracteres, o OCR) para leer texto dentro de los límites de un elemento. El OCR puede, ocasionalmente, identificar erróneamente pequeños glifos similares a íconos, como cheurones de flecha hacia atrás (<), viñetas o 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 compuesto solo por un ícono. Debido a que la salida del OCR no es determinista entre 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, puedes usar las ignore API 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())

Obtén más información sobre ignorar reglas.

Falso positivo del Título de Pantalla en aplicaciones Flutter

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.

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

Al ejecutar comprobaciones 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 que no sea capaz de determinar el color de primer plano y, en su lugar, comparar colores de fondo entre sí, resultando en un fallo.

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

Inexactitud del isVisible propiedad de XCTest

Las API de accesibilidad de Apple pueden reportar incorrectamente 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 WKWebView en sí es visible, en lugar de si su contenido web es realmente visible y perceptible para el usuario.

Error de accesibilidad de iOS 26 con los steppers

iOS 26 contiene un error de accesibilidad en el que los botones stepper predeterminados no anuncian "atenuado" por la Tecnología Asistiva 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 stepper deshabilitados: AssociatedText, InaccessibleAction, y ColorContrast.

Hasta que Apple solucione este error, la resolución será [ignorar las reglas](ios-ignore-rule). Los botones stepper predeterminados tienen los identificadores "Decrementar" e "Incrementar", y pueden ser ignorados 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 associatedText incorrecta (#1622)

Reglas contra Controles Anidados

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

Regla de Nombre de ImageView necesita revisión de resultados para aplicaciones UIKit

En aplicaciones UIKit, una imagen sin `accessibilityLabel` no es enfocada por tecnología asistiva por defecto.
Las propiedades que utilizamos para comprobar 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 problemas de Nombre de ImageView en aplicaciones UIKit se reportarán como Necesitan Revisión. Se ha presentado un informe de error a Apple. (#1633)

Falso positivo: En Vista de Desplazamiento, Label In Name, Label at Front, y Nombre de Vista de Imagen & Nombre de Control Activo v2.11.0

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

In Scroll View
El texto dentro de elementos que se comportan como banners, encabezados/pies pegajosos, botones de acción flotante y vistas de pestañas personalizadas pueden ser marcados con un mensaje de "Necesita Revisión" o "Fallo". Para hacer estos elementos accesibles a 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 enfocada por VoiceOver, y tiene controles enfocables anidados dentro de ella, Nombre de Control Activo puede reportar un falso positivo sobre 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 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)

Android

Falsos positivos de Label at Front con texto visible oscurecido

La regla Label at Front verifica que la etiqueta visible de un elemento aparezca al inicio de su texto anunciado. Un fallo de 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 cuando este es el patrón recomendado para hacer que el contenido abreviado o truncado sea fácil de comprender para 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 puede ser ignorado con seguridad. Verifica con un lector de pantalla que el anuncio completo se lea como se pretende.

Preocupaciones potenciales de accesibilidad para Texto Enfocable

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

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

Falsos positivos en el título de pantalla en aplicaciones Flutter

Flutter no mapea AppBar.title a la propiedad nativa de título de pantalla - Activity.setTitle, lo que causa que la regla del 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 en la detección de texto anunciado

En algunos casos, la tecnología asistiva se basa en AccessibilityEvent descripciones del sistema Android para anunciar información al usuario cuando no hay otro anuncio disponible. Dado que AccessibilityEventson activados por las 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á que Talkback acceda a la información desde la vista, la cual nuestro herramienta puede detectar.

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

Nuestra regla de Contraste de Color depende del Aprendizaje Automático para detectar texto, lo que garantiza que el texto escaneado sea visible para los usuarios de su aplicación. En casos donde el texto contenido en una vista sea del mismo color que el fondo, nuestro algoritmo de Aprendizaje Automático no puede detectar si hay algún 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 funcionalidad de texto sugerido pueden ver falsos positivos con la EditTextName regla. El texto sugerido no fue introducido hasta Android 8 (SDK 26). Usar este elemento en su aplicación XML asignará el texto sugerido 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. Si es importante que la aplicación sea accesible en versiones anteriores de Android, sin embargo, podría considerar evitar el uso de la hintText funcionalidad, ya que no está oficialmente soportada.

Vistas ocultas de Android devolviendo resultados

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 asistiva, pero Axe DevTools Mobile todavía las informa como problemas.

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

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

La detección de texto de ML Kit es requerida 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 al ejecutar la detección de texto mlKit: MlKitContext no ha sido inicializado.

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

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

Encuentre un ejemplo completo de la importación de la biblioteca ML Kit en la sección Comenzando con el SDK Móvil de Android, bajo Implementación

Espacio del objetivo táctil y Jetpack Compose

La regla de Espacio del Objetivo Táctil actualmente no se ejecuta en ningún componente deslizable que haya sido escrito en Jetpack Compose. No se puede tomar ninguna acción en este momento. ¡Sin embargo, pronto habrá una solución!

Error al guardar resultados localmente en API 30

En Android API 30, una de las ubicaciones donde intentamos guardar 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'

//    finalizedBy {
//        fetchAndroidFolderAxeReportsTask
//    }
}

Tenga en cuenta que este código solo debe ser comentado en API 30 ya que causará problemas al guardar localmente para otros niveles de API.

Detección de desplazamiento en Apps Híbridas y Apps Multiplataforma

En algunas aplicaciones híbridas y multiplataforma, podemos devolver resultados inesperados cuando 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 el escaneo.

App del Analizador: El botón de acción flotante desaparece

Introducido con la API 31 (Android 12) está la capacidad de ocultar superposiciones no del sistema. Para utilizar la aplicación Axe Analyzer, asegúrese de que esta configuración no esté activada. Si optó por utilizar esta función por sus mejoras de seguridad, recomendamos dejarla desactivada para compilaciones de pruebas internas donde puede utilizar datos de prueba de manera segura 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, actualice cualquier llamada al método setHideOverlayWindows(true) a setHideOverlayWindows(false) en las ventanas de actividades afectadas.

Falta de captura de pantalla (Caja Negra) en el Tablero

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

Error cuando minifiedEnabled está configurado como verdadero

Si minimiza su compilación, verá un error con un registro que informa 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)

Las compilaciones con r8 habilitado generan un error

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)

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

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

Las API de Compose están obsoletas, por favor use las API agnósticas de diseño para seguir recibiendo actualizaciones. Si continúa usando las API de Compose y encuentra 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 consulte la API Compose setTestTag.

MAUI: Regla de nombre de texto editable

Debido a limitaciones de la arquitectura de la aplicación MAUI al renderizar en el ecosistema de Android, la regla de nombre de texto editable aparecerá como Necesita revisión en el tablero cuando se sospeche un error para la versión del SDK 5.5.0 en adelante. Por favor, confirme manualmente el comportamiento correcto en este caso.

Android Nativo: Diálogos/Modales personalizados

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 verificar manualmente para asegurarse de que funcionan con tecnología de asistencia según sea deseado.

Panel de Control Web

Captura de pantalla faltante

Si falta la captura de pantalla en la página de detalles del escaneo, su aplicación puede 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 pruebas para permitir la funcionalidad completa en el Panel de Control Móvil de Axe DevTools.

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, incluido el identificador del paquete. En una versión futura, esto se resolverá para que el título de la pantalla se formatee en un nombre más legible. Como solución temporal, puede establecer el nombre del escaneo desde el panel de control o los frameworks. (#1643)