Notas de Lançamento do Axe DevTools Mobile de 8 de abril 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 gradientes. Nesses casos, pode não conseguir determinar a cor de 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 web dentro do WKWebView como "isVisible", mesmo quando a visualização web é coberta por sobreposições nativas (como visualizações modais, alertas ou outros elementos da IU nativa). Isso ocorre porque o sistema de acessibilidade verifica se o próprio contêiner WKWebView está visível, em vez de 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 stepper padrão 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 bug foi enviado para a Apple, mas até que isso seja resolvido, as seguintes regras podem relatar resultados em botões stepper desabilitados: AssociatedText, InaccessibleAction, e ColorContrast.

Até que a Apple corrija esse bug, a soluçã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 à propriedade associatedText incorreta encontrada (#1622)

Há um problema que afeta o simulador do iPhone 15 Pro e impede a execução da regra Suporta Tipo Dinâmico. Se você estiver inscrito na regra Suporta Tipo Dinâmico, não poderá testá-la usando um simulador do iPhone 15 Pro. Um bug foi reportado à Apple.

Durante a busca por uma melhoria nas nossas regras, descobrimos que no XCTest, controles aninhados não são retornados na árvore de acessibilidade. Um bug foi reportado à 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` está definido na imagem. Devido a esse comportamento inesperado, os resultados para problemas de Nome de ImageView em aplicativos UIKit serão relatados como Necessitando de Revisão. Um relatório de bug foi enviado à 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
Texto dentro de elementos que se comportam como banners pode ser sinalizado com uma mensagem "Necessita de Revisão". Para tornar esses elementos acessíveis a quem precisa 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 pelo VoiceOver, e tiver controles focáveis aninhados, ActiveControlName pode relatar um falso positivo no UIImageView. Remover o `accessibilityIdentifier` resolve o problema. Um bug foi reportado à Apple. (#1633)

Label In Name and Label At Front
Essas duas regras procuram pelo 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, fazendo com que essas regras falhem. (#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. Desde 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 estão 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 aprendizado de máquina para detectar texto, o que garante que o texto analisado seja visível para os usuários do seu aplicativo. Em casos onde o texto contido em uma visualização seja da mesma cor que o fundo, nosso algoritmo de aprendizado de máquina não consegue detectar se há texto presente, então a regra de contraste de cor não é aplicada 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 em 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 equipadas para tornar essa experiência acessível.

Para superar este 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 mais antigas do Android, contudo, você pode considerar evitar o uso do hintText recurso, já 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 relata como problemas.

Estamos trabalhando em uma solução para este complexo problema. Enquanto isso, se o TalkBack não conseguir acessar essas visualizações, você pode ignorar os problemas correspondentes. Eles não precisam de uma correção para garantir a 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 do 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 a biblioteca ML Kit em seu projeto manualmente. No build.gradle arquivo do seu aplicativo, adicione o seguinte em dependências:

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

A regra de Espaçamento do Alvo de Toque atualmente não está sendo executada em nenhum componente slider que foi escrito em Jetpack Compose. Nenhuma ação pode ser tomada no momento. No entanto, uma solução está a caminho!

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 deste 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'

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 quanto à acessibilidade, certifique-se de que ele esteja totalmente na tela antes de realizar a análise.

Introduzida com o API 31 (Android 12) está a capacidade de ocultar sobreposições que não são do sistema. Para utilizar o aplicativo axe Analyzer, por favor, certifique-se de que essa configuração não esteja ativada. Se você optou por usar esse recurso para seus aprimoramentos de segurança, recomendamos deixá-lo desligado para builds de teste internos, onde você pode usar dados de teste com segurança e eliminar preocupações de segurança dessa maneira. 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 Mobile, certifique-se de que as capturas de tela estejam habilitadas. Recomendamos habilitar capturas de tela em uma versão de depuração ou teste do seu aplicativo que use dados simulados para evitar preocupações com 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 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)
	

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

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

Ao implementar 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 comportem com tecnologia assistiva conforme o desejado.

Se a captura de tela estiver ausente na página de detalhes da varredura, seu aplicativo pode estar impedindo a captura de telas. Freqüentemente, isso ocorre por razões de segurança na sua aplicação de produção. Considere remover esse requisito para sua compilação de teste para permitir a funcionalidade completa no Dashboard Mobile do axe DevTools.

• Android - FLAG_SECURE

Alguns nomes de varredura Android que são definidos por padrão como o título da tela aparecerão como o nome completo da classe, incluindo o identificador do pacote. Em uma futura versão, 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 dashboard ou frameworks. (#1643)