Notas de Lançamento do Axe DevTools Mobile - 18 de Maio de 2026

Ao executar verificações de acessibilidade em tamanhos de tela menores ou com tamanhos de fonte menores, a regra de Contraste de Cor pode relatar falsos positivos para fundos em gradiente. Nesses casos, pode não ser possível determinar a cor do primeiro plano e, em vez disso, comparar as 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 manualmente o Contraste de Cor para essas visualizações.

As APIs de acessibilidade da Apple podem relatar incorretamente o conteúdo web dentro do WKWebView como "isVisible", mesmo quando a visualização web está coberta por sobreposições nativas (como visualizações modais, alertas ou outros elementos de UI nativa). Isso ocorre porque o sistema de acessibilidade verifica se o próprio container 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 padrão do stepper não anunciam "atenuado" pela Tecnologia Assistiva para indicar que 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 à Apple, mas até que isso seja resolvido, as seguintes regras podem relatar resultados em botões de stepper desabilitados: AssociatedText, InaccessibleAction, e ColorContrast.

Até que a Apple corrija esse bug, a resolução será [ignorar as regras](ios-ignore-rule). Os botões padrão do stepper têm os identificadores "Decrement" e "Increment" 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 encontrada (#1622)

Há um problema que afeta o simulador do iPhone 15 Pro que impede a execução da regra Supports Dynamic Type. Se você estiver inscrito na regra Supports Dynamic Type, não será possível testá-la usando um simulador do iPhone 15 Pro. Um erro foi registrado com a Apple.

Enquanto observamos uma melhoria para nossas regras, descobrimos que no XCTest, controles aninhados não são retornados na árvore de acessibilidade. Um bug foi registrado com a Apple. (#1110)

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

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

In Scroll View
Textos dentro de elementos que comportam banners podem ser sinalizados com uma mensagem de "Precisam de Revisão". Para tornar esses elementos acessíveis a aqueles que necessitam de um 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 pelo VoiceOver, e tiver controles focáveis aninhados dentro dele, ActiveControlName pode relatar um falso positivo no UIImageView. Remover o `accessibilityIdentifier` resolve o problema. Um bug foi registrado com a Apple. (#1633)

Label In Name and Label At Front
Essas duas regras procuram por um rótulo visível de um controle próximo a elementos adjacentes 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)

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

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

Nossa regra de Contraste de Cor depende de aprendizagem de máquina para detectar texto, o que garante que o texto sendo 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 aprendizagem de máquina não consegue detectar se algum texto está presente, portanto, a regra de Contraste de Cor não é executada nessa visualização.

Aplicativos escritos em 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. Versões mais recentes do Android estão melhor preparadas para tornar esta experiência acessível.

Para superar este problema, nossa primeira recomendação é executar seus testes em versões mais recentes do Android. No entanto, se é importante que o aplicativo seja acessível em versões anteriores do Android, considere 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 tecnologia assistiva, mas o Axe DevTools Mobile ainda as relata como problemas.

Estamos trabalhando em uma correção para este problema complexo. Enquanto isso, se o TalkBack não puder acessar essas visualizações, você pode desconsiderar 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 o Axe DevTools Mobile em seus testes automatizados Espresso ou UIAutomator. Em alguns casos, no entanto, a importação automática não acontece e você verá o seguinte erro no logcat:

Axe DevTools Android: Error while running mlKit Text Detection: MlKitContext has not been initialized.

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

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

A regra de Espaçamento de Alvo de Toque atualmente não é executada em nenhum componente deslizante escrito em Jetpack Compose. Nenhuma ação pode ser tomada no momento. No entanto, uma correção está chegando em breve!

No Android API 30, um dos locais onde tentamos salvar resultados localmente apresenta um erro de permissões. O resultado ainda será salvo como um arquivo JSON, apesar de esse erro ser exibido. O erro pode ser suprimido comentando o seguinte bloco de código:

def clearDirectoryTask = task('clearDirectoryTask', type: Exec, group: 'reporting') {
	executable "${android.getAdbExecutable().toString()}"
	args 'shell', 'rm', '-r', '/storage/emulated/0/Documents/AxeTestCases'

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

Introduzida com o API 31 (Android 12) está a capacidade de ocultar sobreposições não-sistêmicas. Para utilizar o app 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 builds de teste interno onde você pode usar dados de teste com segurança e, dessa forma, 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 app Axe Accessibility Analyzer, atualize quaisquer chamadas para o método setHideOverlayWindows(true) para setHideOverlayWindows(false) nas janelas de atividade afetadas.

Para desbloquear toda a funcionalidade 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 depuração ou teste do seu app que use dados fictícios para evitar preocupações de segurança. Confira nosso guia para habilitar capturas de tela em aplicativos Android.

Se você minimizar seu build, verá uma falha com um log de erro reportando que um adaptador não pôde ser encontrado ao tentar fazer login na biblioteca Axe DevTools. Desabilite a minimização para seus builds de depuração com o Axe DevTools implementado. (#729)

Um build com r8 habilitado 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)
	

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 `Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)` ou `No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?`, por favor, consulte a API Compose setTestTag.

Devido a limitações da arquitetura do aplicativo MAUI renderizando no ecossistema Android, a regra de Nome de Texto de Edição será exibida como Necessita de Revisão no painel quando uma falha for suspeita para a versão SDK 5.5.0 e superior. Por favor, confirme manualmente o comportamento correto para este caso.

Quando você está 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 as capturas de tela sejam tiradas. Muitas vezes isso acontece por razões de segurança no seu aplicativo de produção. Considere remover este requisito para sua versão de teste para permitir a funcionalidade total no Painel do Axe DevTools Mobile.

• Android - FLAG_SECURE

Alguns nomes de varredura do Android que são definidos como 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 varredura a partir do painel ou dos frameworks. (#1643)