Notas de Lançamento do Axe DevTools Mobile de 23 de outubro de 2026

Ao escanear uma tela com hierarquias de visualizações 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 se enquadra nessa categoria. Se a varredura não for concluída 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 em suas capacidades 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 consegue abrir o simulador iOS. Ele falha ao tentar iniciar /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app Você não pode iniciar uma varredura baseada em simulador até que isso seja resolvido.

Para executar varreduras 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 são encontrados em Axe Developer Hub.

O SDK Axe DevTools usa o framework Vision da Apple para ler textos na tela para várias regras de acessibilidade (por exemplo, Contraste de Cor, Vistas 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 detecta o texto em um controle, as regras que dependem desse texto não serão executadas para esse elemento na mesma análise. Os resultados podem parecer inconsistentes entre duas análises da mesma tela - um problema que falha em uma análise pode estar ausente na próxima.

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

• Reexecute a análise. Se uma regra baseada no Vision foi ignorada para um controle, outra análise da mesma tela geralmente a detecta.
• Trate qualquer falha de regra baseada no Vision como válida - se Contraste de Cor sinaliza um controle, o problema de contraste é real e deve ser abordado.
• Para verificação manual, use a referência da Universidade Deque para o critério de sucesso relevante do WCAG. (Os links podem ser encontrados no final de cada página de regras.)

No iOS 26 e versões posteriores, se uma tela contiver texto com um sinal de porcentagem (por exemplo, um rótulo de texto lendo "50% de desconto"), a regra de Suporte a Tipo Dinâmico pode reportar como Incompleta em vez de aprovada ou reprovada. Esta regra depende de uma auditoria de acessibilidade fornecida pela Apple, e essa auditoria interrompe a execução do teste ao encontrar sinais de porcentagem. Para manter seus testes em execução, nossa regra ignora a verificação para essa tela e reporta como incompleta para cada elemento contendo um sinal de porcentagem. 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 análise ainda será concluída. Para verificar o suporte a Tipo Dinâmico 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 adequadamente. Este problema foi relatado à Apple. (#2985)

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 semelhantes a ícones - como setas de retorno (<), balas, símbolos decorativos - como texto. Quando isso ocorre, a regra de Contraste de Cor é executada em um elemento que não contém texto legível, o que pode gerar um resultado para um botão apenas com ícone. Como a saída do OCR não é determinística entre as análises, o mesmo elemento pode aparecer nos resultados de Contraste de Cor em uma análise e ser reportado como "INAPLICÁVEL" na próxima. Esta é uma característica conhecida do OCR, e não um erro na regra.

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

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

Esta é uma limitação conhecida da plataforma Flutter rastreada 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 ser incapaz de determinar a cor do primeiro plano e, em vez disso, compará-la com as cores do segundo plano, resultando em uma falha.

Para contornar este problema, tente executar as verificações de acessibilidade em dispositivos maiores. Alternativamente, você pode optar por ignorar a regra nos seus testes e verificar o Contraste de Cor manualmente para estas visualizações.

As APIs de acessibilidade da Apple podem relatar incorretamente conteúdo da web dentro de 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 está visível, em vez de verificar se seu conteúdo da web está realmente desobstruído e perceptível para o usuário.

O iOS 26 contém um bug de acessibilidade onde botões padrão de stepper não anunciam "atenuado" pela Tecnologia Assistiva para indicar que não estão ativados. Como resultado, as regras do iOS também vêem esses botões como ativados mesmo que não estejam. Um relatório de bug foi enviado para a Apple, porém 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 este erro, a resolução será [ignorar as regras](ios-ignore-rule). Os botões de stepper padrão 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 incorreta associatedText propriedade sendo encontrada (#1622)

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 focalização da Apple podem ser imprecisas quando um `accessibilityIdentifier` está definido na imagem. Devido a este comportamento inesperado, os resultados para problemas de Nome da ImageView em aplicativos UIKit serão reportados como Precisam de Revisão. Um relatório de bug 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 forem lançadas.

In Scroll View
Texto dentro de elementos com comportamento de banner, 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 àqueles que precisam de texto maior, use UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Se um UIImageView tem um accessibilityIdentifier definido, mas não pode ser focado pelo VoiceOver, e tem controles focáveis aninhados, o Nome do Controle Ativo pode relatar um falso positivo no UIImageView. Remover o accessibilityIdentifier resolve o problema. Um bug foi reportado 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 pode ser detectado, fazendo com que essas regras falhem. (#1622)

O Botão de Ação Flutuante (FAB) do Android Accessibility Analyzer não é compatível com a navegação por deslize do Talkback em versões anteriores a 16.2. Com o lançamento da 16.2, o Talkback corrigiu um bug no código, permitindo o foco por deslize para FABs sobrepostos.

Note que isso é puramente um bug do Talkback, que não permitia que FABs renderizados em sobreposições de Acessibilidade ganhassem ou perdessem foco via deslize. A recente atualização para nosso aplicativo Accessibility Analyzer permite escanear mais tipos de aplicativos; então, você pode estar começando a ver esse problema agora.

Esse problema pode ser resolvido atualizando o Talkback para a versão 16.2 ou posterior.

A regra Rótulo na Frente verifica se o rótulo visível de um elemento aparece no início do texto anunciado. Uma falha pode ocorrer 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"), embora esse seja o padrão recomendado para tornar conteúdo abreviado ou truncado amigável ao leitor de tela.

Se a primeira parte do rótulo visível de um elemento interativo coincidir com o 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 que o anúncio completo seja 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 em vez 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 seremos capazes de determinar de forma confiável se você introduziu uma violação de acessibilidade.

Se você editar texto focável para ignorar dois ou menos caracteres, pode, inadvertidamente, ignorar muitos botões de uma palavra em vários idiomas (por exemplo, "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 em vez de como visualizações de texto separadas. `FocusableText` então não funcionará nessas visualizações.

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

Esta é uma limitação conhecida da plataforma Flutter rastreada 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 podemos acessar a descrição correta se essas informações não forem fornecidas.

Para evitar esse 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 aprendizado de máquina para detectar texto, o que garante que o texto escaneado seja visível para os usuários de seu aplicativo. Em casos onde o texto contido em uma visualização é da mesma cor do fundo, nosso algoritmo de aprendizado de máquina não consegue detectar se há texto presente, de modo que a regra de Contraste de Cor não é executada nessa visualização.

Apps escritos com XML que utilizam o recurso de texto sugestivo podem ver falsos positivos com a EditTextName regra. O texto sugestivo não foi introduzido até o Android 8 (SDK 26). Usar este elemento no seu aplicativo XML atribuirá o texto sugestivo 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 , pois 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 as relata 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 ignorar os problemas correspondentes. Eles não requerem 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 nos 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:

A regra de Espaçamento do Alvo de Toque atualmente não está funcionando em nenhum componente deslizante 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 onde tentamos salvar 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 seguinte bloco:

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 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-sistêmicas. Para utilizar o aplicativo Axe Analyzer, certifique-se de que essa configuração não está ativada. Se você optou por utilizar esse recurso por seus aprimoramentos de segurança, recomendamos deixá-lo desativado para versões de teste internas onde você pode utilizar 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 qualquer chamada ao método setHideOverlayWindows(true) para setHideOverlayWindows(false) nas janelas de atividades afetadas.

Para desbloquear a funcionalidade completa do Axe DevTools para Mobile, certifique-se de que as capturas de tela estejam ativadas. Recomendamos ativar capturas de tela em uma versão de depuração ou teste do seu aplicativo que utiliza dados fictícios para evitar preocupações de segurança. Confira nosso guia para ativar capturas de tela em aplicativos Android.

Se você minimizar seu build, 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 seus builds de depuração com Axe DevTools implementado. (#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 próximo 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 de aplicativos MAUI na renderização no ecossistema Android, a regra Nome de Texto Editável aparecerá como Necessita Revisão no painel quando uma falha for suspeitada para a versão SDK 5.5.0 e superior. Por favor, confirme o comportamento correto manualmente neste caso.

Quando você estiver implementando diálogos ou modais personalizados que não estendem os controles nativos, poderá 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 funcionem com tecnologia assistiva conforme desejado.

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

• Android - FLAG_SECURE

Alguns nomes de digitalizações 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 digitalização a partir do painel ou frameworks. (#1643)