Notas de Lançamento do Axe DevTools Mobile de 10 de dezembro de 2025

Ao executar verificações de acessibilidade em dispositivos com tamanhos de tela menores ou com tamanhos de fonte menores, a regra de Contraste de Cor pode relatar falsos positivos para fundos em degradê. Nessas situações, pode não conseguir determinar a cor do primeiro plano e, em vez disso, comparar cores de fundo entre si, resultando em uma falha.

Para contornar esse problema, tente executar verificações de acessibilidade em dispositivos maiores. Alternativamente, você pode optar por ignorar a regra em seus testes e verificar o Contraste de Cor manualmente para essas visualizações.

As APIs de acessibilidade da Apple podem relatar incorretamente o conteúdo da web dentro do WKWebView como "isVisible", mesmo quando a visualização da web está coberta por sobreposições nativas (como janelas modais, alertas ou outros elementos UI nativos). Isso ocorre porque o sistema de acessibilidade verifica se o próprio contêiner do WKWebView está visível, em vez de verificar se seu conteúdo web está realmente desobstruído e perceptível para o usuário.

O iOS 26 contém um bug de acessibilidade onde os botões de incremento padrão não anunciam "escurecido" por meio da Tecnologia Assistiva para indicar que não estão ativados. Como resultado, as regras do iOS também veem esses botões como ativados, mesmo quando não estão. Um relatório de bug foi arquivado junto à Apple, mas até que isso seja resolvido, as seguintes regras podem relatar resultados em botões de incremento desativados: AssociatedText, InaccessibleAction, e ColorContrast.

Até que a Apple resolva esse problema, a solução será [ignorar as regras](ios-ignore-rule). Os botões de incremento padrão têm os identificadores "Diminuir" e "Aumentar" e podem ser ignorados por identificador, se necessário.

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.

Algumas telas podem relatar falsos positivos com LabelInName e LabelAtFront devido a uma propriedade associatedText incorreta sendo encontrada (#1622)

Há um problema que afeta o simulador do iPhone 15 Pro que impede que a regra Suporta Tipo Dinâmico seja executada. Se você estiver inscrito na regra Suporta Tipo Dinâmico, não poderá testá-la usando um simulador iPhone 15 Pro. Um bug foi registrado com a Apple.

Ao analisar uma melhoria para nossas regras, descobrimos que no XCTest, controles aninhados não são retornados na árvore de acessibilidade. Um bug foi arquivado junto à Apple. (#1110)

Em aplicativos UIKit, uma imagem sem um accessibilityLabel não é focável por padrão com tecnologia assistiva.
As propriedades que usamos para verificar a capacidade de foco da Apple podem ser imprecisas quando um accessibilityIdentifier é definido na imagem. Devido a esse comportamento inesperado, os resultados dos problemas de Nome do ImageView em aplicativos UIKit serão relatados como Precisam de Revisão. Um relatório de bug foi arquivado com a Apple. (#1633)

Estamos trabalhando ativamente em correções para os seguintes falsos positivos e atualizaremos esta lista à medida que as correções forem lançadas.

In Scroll View
Pode relatar problemas para texto dentro de elementos que se comportam como banners. Para tornar esses elementos disponíveis para aqueles que necessitam de texto maior, use UILargeContentViewer. (#622)

v2.11.0 Image View Name & Active Control Name
Se um UIImageView tiver um accessibilityIdentifier definido, mas não for focável por VoiceOver, e tiver controles focáveis aninhados, ActiveControlName pode relatar um falso positivo no UIImageView. Remover o accessibilityIdentifier resolve o problema. Um bug foi arquivado junto à Apple. (#1633)

Label In Name and Label At Front
Essas duas regras procuram o rótulo visível de um controle entre elementos próximos para ajudar a determinar o status da regra. Em algumas hierarquias de visualização, o texto próximo incorreto pode ser detectado, causando falhas nessas regras. (#1622)

Nossa regra de Contraste de Cor depende do aprendizado de máquina para detectar texto, o que garante que o texto escaneado seja visível para os usuários do seu aplicativo. Em casos onde o texto contido em uma visualização é da mesma cor que o fundo, nosso algoritmo de aprendizado de máquina é incapaz de detectar se algum texto está presente, então a regra de Contraste de Cor não roda nessa visualização.

Aplicativos escritos em XML que utilizam o recurso de texto sugestivo podem ver falsos positivos com a regra EditTextName . O texto sugestivo não foi introduzido até o Android 8 (SDK 26). Usar esse elemento em seu aplicativo XML atribuirá o texto sugestivo ao valor do campo de entrada de texto. As versões mais recentes do Android estão melhor equipadas para tornar essa experiência acessível.

Para superar esse problema, nossa primeira recomendação é executar seus testes em versões mais recentes do Android. Se for importante que o aplicativo seja acessível em versões anteriores do Android, no entanto, você pode considerar evitar o uso do recurso hintText , uma vez que não é oficialmente suportado.

Você pode ver resultados para visualizações que estão ocultas atrás de outras visualizações na tela. Essas visualizações ocultas não estão disponíveis para tecnologia assistiva, mas o axe DevTools Mobile ainda as reporta como problemas.

Estamos trabalhando em uma correção para esse problema complexo. Enquanto isso, se o TalkBack não puder alcançar essas visualizações, você pode desconsiderar os problemas correspondentes. Eles não exigem uma correção para garantir acessibilidade.

A deteção de texto do ML Kit é necessária em muitas das regras do axe DevTools Mobile para garantir a precisão dos resultados. A biblioteca ML Kit deve ser importada automaticamente ao referenciar o axe DevTools Mobile nos seus testes automatizados de Espresso ou UIAutomator. No entanto, em alguns casos, a importação automática não acontece e você verá o seguinte erro no logcat:

Para resolver este problema, você deve importar a biblioteca ML Kit em seu projeto manualmente. No build.gradle arquivo da sua aplicação, adicione o seguinte sob dependências:

No momento, a regra de Espaçamento de Alvo de Toque não está sendo aplicada em nenhum componente de controle deslizante escrito em Jetpack Compose. Nenhuma ação pode ser tomada neste momento. Contudo, uma correção está a caminho!

No Android API 30, um dos locais em que tentamos salvar resultados localmente apresenta um erro de permissão. O resultado ainda será salvo como um arquivo JSON, apesar deste erro ser exibido. O erro pode ser suprimido comentando o código no bloco seguinte:
def clearDirectoryTask = task('clearDirectoryTask', type: Exec, group: 'reporting') {
executable "${android.getAdbExecutable().toString()}"
args 'shell', 'rm', '-r', '/storage/emulated/0/Documents/AxeTestCases'
// finalizedBy {
// fetchAndroidFolderAxeReportsTask
// }
}

Observe que este código deve ser comentado apenas para o API 30, pois causará problemas ao salvar localmente para outros níveis de API.

Em alguns aplicativos híbridos e de plataforma cruzada, podemos retornar resultados inesperados quando itens em uma visualização de rolagem estão parcialmente fora da tela. Para testar um elemento quanto à acessibilidade, certifique-se de que ele esteja totalmente na tela antes de realizar a verificação.

Introduzida com o API 31 (Android 12) está a capacidade de ocultar sobreposições não pertencentes ao sistema. Para utilizar o aplicativo axe Analyzer, certifique-se de que esta configuração não esteja ativada. Se você optou por utilizar este recurso por suas melhorias de segurança, recomendamos deixá-lo desativado para as compilações de testes internas, onde você pode usar dados de teste com segurança e eliminar preocupações de segurança dessa forma. Note: this setting does not affect Google's accessibility scanner app as it's considered a system overlay.

Para utilizar o aplicativo axe Accessibility Analyzer, atualize quaisquer chamadas para o método setHideOverlayWindows(true) para setHideOverlayWindows(false) nas janelas de atividades afetadas.

Para desbloquear a funcionalidade completa do axe DevTools para Mobile, certifique-se de que as capturas de tela estão habilitadas. Recomendamos habilitar capturas de tela em uma versão de teste ou depuração do seu aplicativo que usa dados simulados para evitar preocupações de segurança. Confira nosso guia para habilitar capturas de tela em aplicativos Android.

Se minimizar sua compilação, você verá uma falha com um log de erro relatando que um adaptador não pôde ser encontrado ao tentar fazer login na biblioteca axe DevTools. Desative a minimização para suas compilações de depuração com o axe DevTools implementado. (#729)

Uma compilação com r8 ativado pode tentar minimizar a biblioteca axeDevTools, resultando em um erro semelhante 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 erro, adicione a seguinte linha ao seu arquivo ProGuard para manter as classes axeDevTools:
keep class com.deque.** { *; }

As APIs do Compose estão obsoletas, por favor use as APIs agnósticas de layout para continuar recebendo atualizações. Se você continuar a usar as APIs do Compose e encontrar um erro como `Esperado exatamente '1' nó, mas encontrado '2' nós que satisfazem: (isRoot)` ou `Nenhuma View inicializada, você chamou AxeDevToolsCompose.setComposeTestRule()?`, por favor consulte a API Compose setTestTag.

Se você encontrar esta mensagem, alguns resultados das regras podem não retornar conforme o esperado quando essa regra está utilizando inteligência artificial. Regras afetadas incluem Contraste de Cor, Texto Focável e Nome de Elemento Aninhado. (#841)

Devido a limitações da arquitetura de aplicativos MAUI na renderização no ecossistema Android, a regra Nome do Texto Editável aparecerá como Necessita Revisão no painel quando uma falha for suspeitada para a versão do SDK 5.5.0 e superior. Por favor, confirme o comportamento correto manualmente para este caso.

Quando você está implementando diálogos ou modais personalizados que não estendem os controles nativos, você pode obter resultados para visualizações por trás do modal. Neste caso, recomendamos não executar nossa ferramenta contra esses modais ou diálogos personalizados e, em vez disso, verificá-los manualmente para garantir que se comportam como desejado com a tecnologia assistiva.

Se a captura de tela estiver ausente na página de detalhes da varredura, seu aplicativo pode estar impedindo que capturas de tela sejam tiradas. Muitas vezes, isso é por razões de segurança no seu aplicativo de produção. Considere remover esse requisito da sua versão de teste para permitir a funcionalidade completa no Painel de Controle do axe DevTools Mobile.

• Android - FLAG_SECURE

Alguns nomes de varreduras Android que são padronizados para o título da tela aparecerão como o nome completo da classe, incluindo o identificador do pacote. Em uma versão futura, isso será resolvido para que o título da tela seja formatado em um nome mais legível. Como uma solução provisória, você pode definir o nome da varredura a partir do painel ou das estruturas. (#1643)