Notas de Lançamento do Axe DevTools Mobile - 17 de junho de 2026

A regra de Contraste de Cor utiliza o framework Vision da Apple (Reconhecimento Óptico de Caracteres, ou OCR) para ler texto dentro dos limites de um elemento. O OCR pode ocasionalmente identificar erroneamente pequenos glifos parecidos com ícones - como setas de retorno (<), marcadores, símbolos decorativos - como texto. Quando isso acontece, a regra de Contraste de Cor executa-se em um elemento que não contém texto legível, o que pode produzir um resultado para um botão apenas com ícone. Como a saída do OCR não é determinística entre análises, o mesmo elemento pode aparecer nos resultados de Contraste de Cor em uma análise e ser relatado como "INAPLICÁVEL" na seguinte. Esta é uma característica conhecida do OCR, não um erro na regra.

Para contornar esse problema, você pode usar as ignore APIs para suprimir resultados de Contraste de Cor para os elementos afetados.

// Ignore Color Contrast for a specific element by accessibility identifier
axeDevTools?.configuration.ignore(rulesFor: [
    "backButton": [AxeRuleId.ColorContrast.toString()]
])

O Flutter não mapeia AppBar.title para a propriedade nativa de título de tela - UIViewController.title, causando a falha da regra de Título da Tela em todas as telas Flutter, independentemente de um título descritivo estar presente.

Esta é uma limitação conhecida da plataforma Flutter, acompanhada em flutter/flutter#185894.

Ao executar verificações de acessibilidade em tamanhos de tela menores ou com fontes 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 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 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 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 botões de stepper padrão não anunciam "dimmed" pela Tecnologia Assistiva para indicar que não estão habilitados. Como resultado, as regras do iOS também veem esses botões como ativados mesmo que não estejam. Um relatório de bug 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 este 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 a uma propriedade associatedText incorreta ser encontrada (#1622)

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

Ao buscar uma melhoria para 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 capacidade de foco da Apple podem ser imprecisas quando um `accessibilityIdentifier` é definido na imagem. Devido a esse comportamento inesperado, os resultados para problemas de Nome do ImageView em aplicativos UIKit serão relatados como Necessita 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 conforme as correções forem liberadas.

In Scroll View
Textos dentro de elementos com comportamento de banner podem ser sinalizados com uma mensagem de „Necessita Revisão“. Para tornar esses elementos disponíveis para aqueles que necessitam de texto maior, utilize 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 reportado à 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)

Ao usar texto decorativo em vistas como „Ícones de Contato“, é possível introduzir um problema de acessibilidade. Se você estiver usando uma visualização de texto para exibir letras ao invés de gerar imagens com as letras desejadas como vetores, e então declarar essa visualização de texto como não importante para acessibilidade, não poderemos determinar de forma confiável se você introduziu uma violação de acessibilidade.

Se você editar texto focável para ignorar duas ou menos caracteres, pode inadvertidamente ignorar muitos botões de uma palavra em vários idiomas (ex.: „OK“, „No“, „Sí“). Para evitar esses problemas, você deve pegar as letras desejadas da palavra que deseja representar no ícone e gerar as letras como parte da imagem ao invés de como visualizações de texto separadas. `FocusableText` então não será executado nessas visualizações.

O Flutter não mapeia AppBar.title para a propriedade nativa de título da tela - Activity.setTitle, causando a falha da regra de Título da Tela em todas as telas Flutter, independentemente de um título descritivo estar presente.

Esta é uma limitação conhecida da plataforma Flutter acompanhada em flutter/flutter#185894.

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. Como AccessibilityEvents são acionados por ações do usuário, não conseguimos acessar a descrição correta se essas informações não forem fornecidas.

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 cores depende de Machine Learning 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 tem a mesma cor que o fundo, nosso algoritmo de Machine Learning não consegue detectar se algum texto está presente, portanto, a regra de contraste de cores 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. 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 de hintText , já que não é oficialmente suportado.

Pode ser que você veja resultados para visualizações 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 soluçã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 necessitam 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 automaticamente importada 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 ocorre e você verá o seguinte erro no logcat:

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

Para resolver este problema, você deve importar a biblioteca ML Kit em seu projeto manualmente. No arquivo build.gradle do seu aplicativo, 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 está funcionando em nenhum componente deslizante escrito em Jetpack Compose. Nenhuma ação pode ser tomada neste momento. No entanto, uma correção chegará 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 este 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 para acessibilidade, certifique-se de que ele está totalmente visível antes de realizar a varredura.

Introduzida com a API 31 (Android 12) está a capacidade de ocultar sobreposições que não são do sistema. Para utilizar o aplicativo axe Analyzer, certifique-se de que essa configuração não está ativada. Se você optou por utilizar este recurso para seus aprimoramentos de segurança, recomendamos deixá-lo desativado para versões de teste 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 todas as chamadas para o método setHideOverlayWindows(true) para setHideOverlayWindows(false) nas janelas de atividade afetadas.

Para desbloquear a funcionalidade completa do axe DevTools para Mobile, certifique-se de que as capturas de tela estão ativadas. Recomendamos ativar capturas de tela em uma versão de depuração ou teste 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 indicando 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 similar 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 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 o API Compose setTestTag.

Devido a limitações da arquitetura do aplicativo MAUI ao renderizar no ecossistema Android, a regra de Nome da Caixa de Texto Editável aparecerá como Precisa de Revisão no painel quando uma falha é 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, pode receber resultados para as visualizações atrás do modal. Neste caso, recomendamos não executar nossa ferramenta contra esses modais ou diálogos personalizados e, em vez disso, verificar manualmente para garantir que eles se comportem com a tecnologia assistiva conforme desejado.

Se a captura de tela estiver faltando 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 este requisito para sua compilação de teste para permitir a funcionalidade completa no Painel Mobile do axe DevTools.

• Android - FLAG_SECURE

Alguns nomes de varredura do 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 alternativa, você pode definir o nome de varredura a partir do painel ou das estruturas. (#1643)