Notas de Lançamento do Axe DevTools Mobile de 4 de fevereiro de 2026

Ao executar verificações de acessibilidade em tamanhos de tela menores ou com tamanhos de fonte reduzidos, a regra de Contraste de Cor pode relatar falsos positivos para fundos em degradê. Nesses casos, pode ser incapaz de determinar a cor de primeiro plano e, em vez disso, comparar cores de fundo entre si, resultando em 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 visualizações modais, alertas ou outros elementos de interface do usuário nativos). Isso ocorre porque o sistema de acessibilidade verifica se o contêiner do WKWebView em si 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 erro de acessibilidade onde os botões padrão do stepper não anunciam „desativado“ pela Tecnologia Assistiva para indicar que eles não estão habilitados. Como resultado, as regras do iOS também veem esses botões como habilitados, mesmo que não estejam. Um relatório de erro foi enviado para a Apple, mas até que isso seja resolvido, as seguintes regras podem relatar resultados em botões stepper desativados: AssociatedText, InaccessibleAction, e ColorContrast.

Até que a Apple corrija esse erro, a solução será [ignorar as regras](ios-ignore-rule). Os botões padrão do stepper têm os identificadores „Decrementar“ e „Incrementar“, 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 afetando o simulador do iPhone 15 Pro que impede a execução da regra de Suporte a Tipos Dinâmicos. Se você estiver inscrito na regra de Suporte a Tipos Dinâmicos, não poderá testá-la usando um simulador do iPhone 15 Pro. Um relatório de erro foi enviado para a Apple.

Ao buscar uma melhoria para nossas regras, descobrimos que no XCTest, controles aninhados não são retornados na árvore de acessibilidade. Um relatório de erro foi enviado para a Apple. (#1110)

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

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

In Scroll View
Pode relatar problemas para texto dentro de elementos que se comportam como banner. 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 uma UIImageView tem um accessibilityIdentifier definido mas não é focalizável pelo VoiceOver, e tem controles focalizáveis aninhados dentro dela, o ActiveControlName pode relatar um falso positivo na UIImageView. Remover o accessibilityIdentifier resolve o problema. Um relatório de erro foi enviado para a 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 incorreto próximo pode ser detectado, fazendo com que essas regras falhem. (#1622)

Em alguns casos, a tecnologia assistiva confia em AccessibilityEvent descrições do sistema Android para anunciar informações ao usuário quando nenhum outro anúncio está disponível. Desde AccessibilityEvents are triggered by user actions, we are unable to access the correct description if this information is not provided.

Para evitar esse problema, certifique-se de que todas as visualizações relevantes sejam marcadas como importantes para acessibilidade. Isso permitirá que o TalkBack acesse as informações da visualização, que nossa ferramenta poderá detectar.

Nossa regra de Contraste de Cor depende de Aprendizado de Máquina para detectar texto, o que garante que o texto sendo verificado seja visível para os usuários da sua aplicação. Em casos onde o texto contido em uma visualização é da mesma cor que o fundo, nosso algoritmo de Aprendizado de Máquina não consegue detectar se há algum texto presente, então a regra de Contraste de Cor não é executada nessa visualização.

Aplicativos escritos com XML que utilizam o recurso de texto de dica podem ver falsos positivos com a EditTextName regra. O texto de dica não foi introduzido até o Android 8 (SDK 26). Usar este elemento no seu aplicativo XML atribuirá o texto de dica ao valor do campo de entrada de texto. As versões mais recentes do Android estão melhores 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, pode considerar evitar o uso do hintText recurso, pois ele 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 a tecnologia assistiva, mas o axe DevTools Mobile ainda os relata como problemas.

Estamos trabalhando em uma correção para este problema complexo. Enquanto isso, se o TalkBack não conseguir acessar essas visualizações, você pode ignorar os problemas correspondentes. Eles não requerem uma correção para garantir acessibilidade.

A detecçã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 axe DevTools Mobile em seus testes automatizados do Espresso ou UIAutomator. Em alguns casos, no entanto, a importação automática não ocorre e você verá o seguinte erro no logcat:

Para superar esse problema, você deve importar a biblioteca ML Kit para seu projeto manualmente. No build.gradle do seu aplicativo, adicione o seguinte sob dependências:

A regra de Espaçamento de Alvo de Toque atualmente não está sendo aplicada em nenhum componente de controle deslizante que foi escrito em Jetpack Compose. Nenhuma ação pode ser tomada neste momento. No entanto, uma correção estará disponível em breve!

No Android API 30, um dos locais em que tentamos salvar os resultados localmente apresenta um erro de permissões. O resultado ainda será salvo como um arquivo JSON, apesar desse erro ser exibido. O erro pode ser suprimido comentando o código no bloco a seguir:
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 esse 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 multiplataforma, podemos retornar resultados inesperados quando itens em uma visualização de rolagem estão parcialmente fora da tela. Para testar um elemento para acessibilidade, certifique-se de que ele esteja totalmente na tela antes de realizar a verificação.

Introduzida com a API 31 (Android 12) está a capacidade de ocultar sobreposições não-sistema. Para utilizar o aplicativo analisador axe, certifique-se de que esta configuração não esteja ativada. Se você optou por utilizar esse recurso para aumentar a segurança, recomendamos deixá-lo desativado para compilações de teste internas onde você pode utilizar dados de teste com segurança e assim eliminar preocupações de segurança. 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 das atividades afetadas.

Para desbloquear a funcionalidade completa do axe DevTools para Móvel, certifique-se de que as capturas de tela estejam habilitadas. Recomendamos habilitar as capturas de tela em uma versão de depuração ou teste do seu aplicativo que use dados fictícios para evitar problemas de segurança. Confira nosso guia para habilitar capturas de tela em aplicativos Android.

Se minificar sua compilação, poderá ocorrer 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 minificação para suas compilações de depuração com o axe DevTools implementado. (#729)

Uma compilação com r8 habilitado pode tentar minificar 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 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 Compose e encontrar um erro semelhante a `Esperado exatamente '1' nó, mas foram encontrados '2' nós que satisfazem: (isRoot)` ou `Nenhuma View inicializada, você chamou AxeDevToolsCompose.setComposeTestRule()?`, consulte API Compose setTestTag.

Se você encontrar esta mensagem, alguns resultados de regras podem não ser retornados conforme esperado quando essa regra estiver utilizando inteligência artificial. As 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 de Nome de Texto de Edição aparecerá como Precisa de Revisão no painel quando uma falha for suspeitada para a versão 5.5.0 do SDK e superior. Por favor, confirme o comportamento correto manualmente para este caso.

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

Se a captura de tela estiver ausente da página de detalhes da verificação, seu aplicativo pode estar impedindo que capturas de tela sejam tiradas. Muitas vezes, isso é por motivos de segurança no seu aplicativo de produção. Considere remover essa exigência para sua compilação de teste para permitir a funcionalidade completa no painel móvel do axe DevTools.

• Android - FLAG_SECURE

Alguns nomes de verificação Android que são definidos por padrão 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 solução alternativa, você pode definir o nome da verificação a partir do painel ou dos frameworks. (#1643)