Notas de la versión de Axe DevTools Mobile 8 de septiembre de 2026

Este estado está obsoleto y será eliminado en octubre de 2026. En ese momento, las reglas ignoradas se omitirán en la iteración y ya no devolverán un resultado.

Tenga en cuenta que AxeDevTools itself no está obsoleto. Los siguientes métodos serán reemplazados o eliminados por completo en la versión de octubre de 2026.

• ignoreByViewIdResourceName(viewIdResourceName: String, ruleList: List) (Será reemplazado por ignoreRulesOnElementWithId(id: String, vararg rules: AxeRuleName))
• ignoreRules(rulesToIgnore: List)
• resetIgnoredRules()
• tagScansAs(tag: TagSet)
• deleteResult(axeDevToolsResultKey: AxeDevToolsResultKey)
• getResult(axeDevToolsResultKey: AxeDevToolsResultKey)

• getResult()
• postResult()
• deleteResult()
• tag()
• setScanName()
• getUserInfo()
• getResultSync()
• postResultSync()
• deleteResultSync()
• tagSync()
• setScanNameSync()
• getSessionId()
• BASE_FRONTEND_URL
• DB_DEFAULT_URL
• DB_QA_URL
• DB_DEV_URL

El concepto de reglas experimentales será eliminado por completo en la versión de octubre. Lo mismo aplica a las etiquetas: desaparecerán con el retiro del Panel de Control Móvil.

Estas reglas eran experimentales y no se están promoviendo. Han sido eliminadas de nuestra iteración de reglas.

• AxeDevToolsResultKey
• AxeDevToolsResultSummaryResponse
• ConnectionConfig - Esto será reemplazado por dbUrl constructor de argumento único
• class TagsSet()
• Las reglas experimentales están siendo promovidas o eliminadas

El SDK de Axe DevTools utiliza el marco Vision de Apple para leer texto de la pantalla para varias reglas de accesibilidad (por ejemplo, Contraste de Color, Vistas en Colisión, 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 omite el texto en un control, las reglas que dependen de ese texto no se ejecutarán para ese elemento en ese análisis. Los hallazgos pueden aparecer inconsistentes entre dos análisis de la misma pantalla: un problema que falla en un análisis puede estar ausente en el siguiente.

Cuando una regla basada en Vision reporta una falla, la falla en sí misma es precisa. La inconsistencia está en si la regla se ejecuta o no. Para superar este problema, intente lo siguiente:

• Vuelva a ejecutar el análisis. Si una regla basada en Vision fue omitida para un control, otro análisis de la misma pantalla a menudo la detecta.
• Trate cualquier falla de regla basada en Vision como válida - si Contraste de Color marca un control, el problema de contraste es real y debe ser abordado.
• Para una verificación manual, use la referencia de Deque University para el criterio de éxito WCAG relevante. (Los enlaces se pueden encontrar en la parte inferior de cada página de reglas.)

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

La regla de Contraste de Color utiliza el marco Vision de Apple (Reconocimiento Óptico de Caracteres, u OCR) para leer el texto dentro de los límites de un elemento. OCR puede ocasionalmente identificar erróneamente glifos pequeños parecidos a iconos - como las quillas de flecha 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 para un botón solo de íconos. Debido a que la salida de OCR no es determinista entre análisis, el mismo elemento puede aparecer en los resultados de Contraste de Color en un análisis 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, puede usar las ignore API para suprimir los resultados de Contraste de Color para los elementos afectados.

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

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

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

Para solucionar este problema, intente ejecutar 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.

Las API de accesibilidad de Apple pueden informar 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 UI nativos). Esto ocurre porque el sistema de accesibilidad verifica si el contenedor de WKWebView es visible, en lugar de si su contenido web es realmente visible y perceptible para el usuario.

iOS 26 contiene un error de accesibilidad donde los botones de incrementador predeterminados no anuncian "atenudado" 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 incrementador deshabilitados: AssociatedText, InaccessibleAction, y ColorContrast.

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

Mientras se buscaba 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)

En aplicaciones de UIKit, una imagen sin un `accessibilityLabel` no es focalizable con tecnología de asistencia por defecto.
Las propiedades que usamos para verificar la focalización desde 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 de 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 lanzan las soluciones.

In Scroll View
El texto dentro de elementos que actúan como banners, encabezados/pies adhesivos, 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 estos elementos disponibles para aquellos que requieren texto más grande, utilice UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Si un UIImageView tiene un accessibilityIdentifier establecido pero no es focalizable por VoiceOver, y tiene controles focalizables anidados dentro de él, Active Control Name puede reportar un falso positivo en el UIImageView. Eliminar el accessibilityIdentifier soluciona 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, el texto cercano incorrecto puede ser detectado provocando que estas reglas fallen. (#1622)

La regla Label al Frente verifica que la etiqueta visible de un elemento aparezca al inicio de su texto anunciado. Puede producirse un fallo de regla 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"), aunque este es el patrón recomendado para hacer que el contenido abreviado o truncado sea amigable 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 de forma segura. 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 la 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 el texto focalizable para ignorar dos o menos caracteres, puede que por inadvertencia ignore 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 icono 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 nativa de título de pantalla - Activity.setTitle, causando que la regla de Título de Pantalla falle en todas las pantallas Flutter independientemente de si está presente un título descriptivo.

Esta es una limitación de la plataforma Flutter conocida y 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 hay otro anuncio disponible. Dado que AccessibilityEventse 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 la accesibilidad. Esto permitirá que Talkback acceda a la información desde la vista, que nuestra herramienta puede detectar.

Nuestra regla de Contraste de Color depende del Aprendizaje Automático para detectar texto, lo que garantiza que el texto analizado 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.

Las aplicaciones escritas en XML que utilizan la característica de texto de ayuda pueden ver falsos positivos con la EditTextName regla. El texto de ayuda no se introdujo hasta Android 8 (SDK 26). Usar este elemento en su aplicación XML asignará el texto de ayuda 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, 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 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 descartar 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 de ML Kit debería importarse automáticamente al referenciar 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:

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

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

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

Introducida con API 31 (Android 12) está la capacidad de ocultar superposiciones no del 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 versiones de prueba internas donde puedas utilizar los datos de prueba de forma 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óvil, asegúrate de que las capturas de pantalla estén habilitadas. Recomendamos habilitar las capturas de pantalla en una versión de prueba o de depuración de tu aplicación que utilice datos simulados para evitar problemas de seguridad. Consulta nuestra guía para habilitar capturas de pantalla en aplicaciones Android.

Si minimizas tu compilación, verás un bloqueo 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)

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 utiliza las APIs agnósticas de diseño para continuar recibiendo actualizaciones. Si continúas usando las APIs de Compose y encuentras un error del tipo `Se esperaban exactamente '1' nodo pero se encontraron '2' nodos que satisfacen: (isRoot)` o `No se inicializó la Vista, ¿has llamado a AxeDevToolsCompose.setComposeTestRule()?`, por favor consulta el API de setTestTag de Compose.

Debido a limitaciones de la arquitectura de la aplicación MAUI en el ecosistema Android, la regla de Nombre de Texto de Edición se mostrará como Necesita Revisión en el tablero cuando se sospeche un fallo para la versión del SDK 5.5.0 o superior. Por favor, confirma el comportamiento correcto manualmente en este caso.

Cuando estés implementando diálogos o modales personalizados que no extienden los controles nativos, podrías 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 comportan con la tecnología assistiva según lo deseado.

Si la captura de pantalla falta en la página de detalles del escaneo, es posible que tu aplicación esté impidiendo la toma de capturas de pantalla. A menudo, esto es 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 de Axe DevTools Mobile.

• Android - FLAG_SECURE

Algunos nombres de escaneo de Android que dependen del título de pantalla aparecerán como el nombre completo de la clase, incluyendo 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 alternativa, puedes establecer el nombre del escaneo desde el tablero o los marcos. (#1643)