Notas de Lançamento do Axe DevTools Mobile em 7 de outubro de 2026

Ao escanear uma tela com hierarquias de visualização grandes ou complexas, o axeScan comando pode levar mais de 60 segundos para ser concluído. O proxy WebDriverAgent (WDA) do Appium aplica um tempo limite padrão de 60 segundos para comandos desconhecidos, e axeScan cai nessa categoria. Se o escaneamento não for concluído dentro desse tempo, o WDA cancela a solicitação e o teste lança um erro de tempo limite

Para substituir o tempo limite por comando para comandos proxy do WDA, como axeScan, recomendamos as seguintes configurações nas suas capacidades do Appium:

• appium:commandTimeouts: 240000 (4 minutos)
• appium:wdaConnectionTimeout: 30000 (5 minutos)

Note: appium:newCommandTimeout is a different setting. It controls how long Appium waits between commands from the test script. That is not the cause of this issue. The relevant setting is appium:commandTimeouts

Se você estiver no Xcode 27 e executando um aplicativo Mobile Analyzer Desktop mais antigo que a versão 2.0.0, o aplicativo não pode abrir o simulador do iOS. Ele falha ao tentar iniciar /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app Você não pode iniciar um escaneamento baseado em simulador até que isso seja resolvido.

Para executar escaneamentos usando um simulador no Xcode 27, atualize o Desktop Analyzer para a versão 2.0.0+. Com esta atualização, observe que os resultados de acessibilidade agora podem ser encontrados em Axe Developer Hub.

O SDK do Axe DevTools utiliza o framework Vision da Apple para ler texto na tela para várias regras de acessibilidade (por exemplo, Contraste de Cores, Visualizações Colidindo, qualquer regra que dependa de texto detectado pelo Vision).

O Vision nem sempre retorna o mesmo texto detectado entre execuções da mesma tela. Quando o Vision não captura o texto em um controle, as regras que dependem desse texto não serão executadas para esse elemento naquela varredura. As descobertas podem parecer inconsistentes entre duas varreduras da mesma tela - um problema que falha em uma varredura pode estar ausente na próxima.

Quando uma regra baseada no Vision relata uma falha, a própria falha é precisa. A inconsistência está em se a regra é executada ou não. Para superar esse problema, tente o seguinte:

• Execute a varredura novamente. Se uma regra baseada no Vision foi ignorada para um controle, outra varredura da mesma tela frequentemente a captura.
• Considere qualquer falha em uma regra baseada no Vision como válida - se o Contraste de Cores assinalar um controle, o problema de contraste é real e deve ser corrigido.
• Para verificação manual, use a referência da Deque University para o critério de sucesso WCAG relevante. (Os links podem ser encontrados no final de cada página de regras.)

No iOS 26 e posteriores, se uma tela contiver texto com um sinal de percentagem (por exemplo, um rótulo de texto lendo "50% Off"), a regra Supports Dynamic Type pode relatar como Incompleto em vez de aprovar ou reprovar. Essa regra depende de uma auditoria de acessibilidade fornecida pela Apple, e essa auditoria interrompe a execução do teste quando encontra sinais de percentagem. Para manter seus testes em execução, nossa regra ignora a verificação para essa tela e relata incompleto para cada elemento contendo um sinal de percentagem. Todas as outras regras são executadas normalmente na tela, e outras telas não são afetadas.

Nenhuma ação é necessária, pois sua varredura ainda será concluída. Para verificar o suporte ao Dynamic Type para essas telas, aumente o tamanho do texto no seu dispositivo em **Configurações** > **Acessibilidade** > **Exibição e Tamanho do Texto** > **Texto Grande**, e confirme se o texto na tela escala devidamente. Este problema foi relatado à Apple. (#2985)

A regra de Contraste de Cor usa o framework Vision da Apple (Reconhecimento Óptico de Caracteres, ou OCR) para ler o texto dentro das bordas de um elemento. O OCR pode, ocasionalmente, identificar incorretamente pequenos glifos semelhantes a ícones - como setas de navegação (<), marcadores, símbolos decorativos - como texto. Quando isso acontece, a regra de Contraste de Cor é aplicada a um elemento que não contém texto legível, o que pode gerar um resultado para um botão somente de ícones. Como a saída do OCR não é determinística entre escaneamentos, o mesmo elemento pode aparecer nos resultados de Contraste de Cor em uma varredura e ser reportado como "INAPLICÁVEL" na próxima. Esta é uma característica conhecida do OCR, não um bug na regra.

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

O Flutter não mapeia AppBar.title para a propriedade do título da tela nativa - UIViewController.title, fazendo com que a regra do título da tela falhe em todas as telas do Flutter, independentemente de haver um título descritivo 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 tamanhos de fonte menores, a regra de Contraste de Cor pode relatar falsos positivos para fundos em gradiente. Nesses casos, pode não conseguir 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 o Contraste de Cor manualmente para essas visualizações.

As APIs de acessibilidade da Apple podem relatar incorretamente o conteúdo da web dentro de um 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 contêiner WKWebView em si é visível, ao invés de se o seu conteúdo web está realmente desobstruído e perceptível para o usuário.

O iOS 26 contém um bug de acessibilidade em que 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 quando não estão. 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 desativados: 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 a uma associatedText propriedade incorreta encontrada (#1622)

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 enviado à Apple. (#1110)

Em aplicativos UIKit, uma imagem sem um `accessibilityLabel` não é focável com 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 questões de Nome de ImageView em aplicativos UIKit serão reportados como Precisam 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
Textos dentro de elementos que se comportam como banners, cabeçalhos/rodapés fixos, botões de ação flutuantes e visualizações de abas personalizadas podem ser sinalizados com uma mensagem de "Precisam de Revisão" ou "Falha". Para tornar esses elementos disponíveis para aqueles que necessitam de texto maior, use UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Se uma UIImageView tem um accessibilityIdentifier definido mas não é focável pelo VoiceOver, e possui controles focáveis aninhados dentro dela, o Nome de Controle Ativo pode relatar um falso positivo na UIImageView. Remover o accessibilityIdentifier resolve o problema. Um bug foi enviado à 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 incorreto próximo pode ser detectado, fazendo com que essas regras falhem. (#1622)

A regra Label at Front verifica se o rótulo visível de um elemento aparece no início do texto anunciado. Pode ocorrer uma falha na regra quando o texto visível de um elemento interativo contém uma abreviação (por exemplo, "GB", "km") ou um identificador obscurecido/truncado, e o anúncio de acessibilidade consiste nas palavras representadas (por exemplo, "gigabytes", "quilômetros"), mesmo que este seja o padrão recomendado para tornar o conteúdo abreviado ou truncado mais acessível para leitores de tela.

Se a primeira parte do rótulo visível de um elemento interativo corresponder ao início do anúncio do leitor de tela e apenas a parte abreviada/obscurecida diferir, o resultado sinalizado pode ser ignorado com segurança. Verifique com um leitor de tela se o anúncio completo é lido conforme o esperado.

Ao usar texto decorativo em visualizações 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 que essa visualização de texto não é importante para acessibilidade, não poderemos garantir que você não 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 única palavra em vários idiomas (por exemplo, "OK", "No", "Sí"). Para evitar esses problemas, você deve extrair as letras desejadas da palavra que deseja representar no ícone e gerar as letras como parte da imagem, em vez de visualizações de texto separadas. O `FocusableText` então não será executado nessas visualizações.

O Flutter não mapeia AppBar.title para a propriedade do título da tela nativa - Activity.setTitle, fazendo com que a regra do título da tela falhe em todas as telas do Flutter, independentemente de haver um título descritivo 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 não há outro anúncio disponível. Como AccessibilityEventsão acionadas por ações do usuário, não conseguimos acessar a descrição correta se essa informação não for fornecida.

Para evitar este 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á então detectar.

Nossa regra de Contraste de Cor depende de Machine Learning 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 é da mesma cor que o fundo, nosso algoritmo de Machine Learning não consegue detectar se há texto presente, então a regra de Contraste de Cor não é aplicada a essa visualização.

Apps desenvolvidos com XML que utilizam o recurso de texto de sugestão podem ver falsos positivos com a EditTextName regra. O texto de sugestão não foi introduzido até o Android 8 (SDK 26). Usar este elemento em seu app XML atribuirá o texto de sugestão ao valor do campo de entrada de texto. Versões mais recentes do Android estão mais bem 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. No entanto, se for importante que o app seja acessível em versões anteriores do Android, você 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 tecnologia assistiva, mas o Axe DevTools Mobile ainda as relata como problemas.

Estamos trabalhando em uma solução para este problema complexo. Enquanto isso, se o TalkBack não conseguir acessar essas visualizações, você pode desconsiderar os problemas correspondentes. Eles não exigem 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 Espresso ou UIAutomator. No entanto, em alguns casos, a importação automática não acontece e você verá o seguinte erro no logcat:

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

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

Em alguns apps 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 completamente na tela antes de realizar a análise.

Introduzida com a API 31 (Android 12), está a capacidade de ocultar sobreposições não-sistêmicas. Para utilizar o aplicativo Axe Analyzer, certifique-se de que essa configuração não esteja ativada. Se você optou por utilizar esse recurso por suas melhorias de segurança, recomendamos deixá-lo desativado para as versões de teste internas, onde você pode utilizar dados de testes com segurança e eliminar preocupações com 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 toda a funcionalidade do Axe DevTools para Mobile, certifique-se de que as capturas de tela estejam ativadas. Recomendamos habilitar as capturas de tela em uma versão de depuração ou teste de seu aplicativo que use dados simulados para evitar preocupações com segurança. Confira nosso guia para habilitar capturas de tela em apps Android.

Se estiver minimizando sua build, você verá uma falha com um log de erro informando que um adaptador não pôde ser encontrado ao tentar fazer login na biblioteca Axe DevTools. Desative a minimização para suas builds de depuração com a implementação do Axe DevTools. (#729)

Um build com r8 ativado pode tentar minimizar a biblioteca axeDevTools, resultando em um erro semelhante a:

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

Devido a limitações da arquitetura do aplicativo MAUI no ecossistema Android, a regra do Nome de Texto Editável aparecerá como Precisa de Revisão no dashboard quando uma falha for suspeitada para a versão SDK 5.5.0 e superiores. 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 atrás do modal. Nesse caso, recomendamos não executar nossa ferramenta nesses modais ou diálogos personalizados e, em vez disso, verificá-los manualmente para garantir que se comportem com a tecnologia assistiva como desejado.

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

• Android - FLAG_SECURE

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