Notas de Lançamento do Axe DevTools Mobile - 23 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 a comandos desconhecidos, e axeScan se enquadra nessa categoria. Se a varredura não for concluída nesse 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 proxys 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 2.0.0, o aplicativo não pode abrir o simulador iOS. Ele falha ao tentar lançar /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 da acessibilidade agora estão disponíveis em Axe Developer Hub.

O Axe DevTools SDK usa o framework Vision da Apple para ler texto na tela para várias regras de acessibilidade (por exemplo, Contraste de Cor, 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 detecta o texto de um controle, as regras que dependem desse texto não serão aplicadas a esse elemento durante a varredura. Os resultados podem aparecer 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 falha em si é precisa. A inconsistência está em se a regra é executada ou não. Para superar este problema, tente o seguinte:

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

No iOS 26 e posterior, se uma tela contém texto com um sinal de percentagem (por exemplo, uma etiqueta de texto com "50% de desconto"), a regra Suporta Tipo Dinâmico pode reportar como Incompleta em vez de aprovada ou falha. Esta 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 reporta como incompleta para cada elemento que contém um sinal de percentagem. Todas as outras regras funcionam normalmente na tela e outras telas não são afetadas.

Não é necessária nenhuma ação, pois sua varredura será concluída. Para verificar o suporte ao Tipo Dinâmico para essas telas, aumente o tamanho do texto no seu dispositivo em **Configurações** > **Acessibilidade** > **Tamanho do Texto e Exibição** > **Texto Grande**, e confirme se o texto na tela ajusta-se adequadamente. Este problema foi reportado à 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 dos limites de um elemento. O OCR pode ocasionalmente confundir pequenos glifos semelhantes a ícones - como setas (〈), balas, 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 produzir um resultado para um botão apenas com ícone. Como a saída do OCR não é determinística entre varreduras, o mesmo elemento pode aparecer nos resultados de Contraste de Cor em uma varredura e ser reportado como "NÃO APLICÁVEL" na próxima. Esta é uma característica conhecida do OCR, não um bug na regra.

Para contornar este 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 nativa de título da tela - UIViewController.title, fazendo com que a regra de Título da Tela falhe em todas as telas Flutter, independentemente de um título descritivo estar presente.

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

Ao executar verificações de acessibilidade em telas menores ou com tamanhos de fonte menores, a regra de Contraste de Cor pode reportar falsos positivos para fundos gradientes. Nesses casos, pode não ser capaz de determinar a cor de primeiro plano e, em vez disso, comparar as cores de fundo entre si, resultando em uma falha.

Para contornar este 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 web view está coberta por sobreposições nativas (como visõ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, 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 default de 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 bug foi enviado para a 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 este bug, a solução será [ignorar as regras](ios-ignore-rule). Os botões default de 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 apresentar falsos positivos com LabelInName e LabelAtFront devido a um associatedText property encontrado incorretamente (#1622)

Ao revisar 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 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 problemas de Nome de 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 conforme as correções forem lançadas.

In Scroll View
Textos dentro de elementos que funcionam 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 "Precisa de Revisão" ou "Falha". Para tornar esses elementos disponíveis para aqueles 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 é focalizável pelo VoiceOver, e possui controles focalizáveis aninhados, o Active Control Name 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
Estas 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 pode ser detectado, causando falhas nessas regras. (#1622)

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

Observe que este é puramente um bug do Talkback, que não permitia que os FABs renderizados em sobreposições de acessibilidade ganhassem ou perdessem foco via deslize. A recente atualização do nosso aplicativo Accessibility Analyzer permite escanear mais tipos de aplicativos; por isso, você pode estar enxergando esse problema agora.

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

A regra Label at Front verifica se o rótulo visível de um elemento está no início de seu texto anunciado. Uma falha na regra 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"), mesmo que esse seja o padrão recomendado para tornar conteúdo abreviado ou truncado mais acessível ao leitor 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 for diferente, 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 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 focalizável para ignorar dois ou menos caracteres, pode acabar ignorando muitos botões de uma palavra em vários idiomas (por exemplo, "OK", "No", "Sí"). Para evitar esses problemas, você deve obter as letras desejadas da palavra que deseja representar no ícone e gerar essas letras como parte da imagem, e não como 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 nativa de título da tela - Activity.setTitle, fazendo com que a regra de Título da Tela falhe em todas as telas Flutter, independentemente de um título descritivo estar 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. Já que AccessibilityEvents são acionados por ações do usuário, não podemos acessar a descrição correta se essa informação não for fornecida.

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 então poderá detectar.

Nossa regra de Contraste de Cor depende de Aprendizado de Máquina para detectar texto, o que garante que o texto a ser 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 Aprendizado de Máquina não consegue detectar se há algum texto presente, por isso 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 esse 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 hintText recurso, já que 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 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 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 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 acontece e você verá o seguinte erro no logcat:

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

No Android API 30, um dos locais em que 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 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 quanto à acessibilidade, certifique-se de que ele esteja completamente na tela antes de realizar a verificação.

Introduzida com a API 31 (Android 12), está a capacidade de ocultar sobreposições não relacionadas ao sistema. Para utilizar o aplicativo Axe Analyzer, certifique-se de que essa configuração não esteja ativada. Se você optou por utilizar este recurso por seus aprimoramentos de segurança, recomendamos deixá-lo desativado para compilaçõ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 todas as chamadas para o método setHideOverlayWindows(true) na janela das atividades afetadas. setHideOverlayWindows(false)

Para desbloquear a funcionalidade completa do Axe DevTools para dispositivos móveis, 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 use dados simulados para evitar problemas de segurança. Confira nosso guia para ativar capturas de tela em aplicativos Android.

Se você minimizar sua build, 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 builds de depuração com o Axe DevTools implementado. (#729)

Uma build com r8 habilitado pode tentar minimizar a biblioteca axeDevTools resultando em um erro semelhante a:

As APIs Compose estão obsoletas, por favor, use as APIs independentes de layout para continuar recebendo atualizações. Se você continuar a usar as APIs Compose e encontrar um erro semelhante a `Esperado exatamente '1' nó, mas encontrados '2' nós que atendem: (isRoot)` ou `Nenhuma Visão inicializada, você chamou AxeDevToolsCompose.setComposeTestRule()?`, por favor, consulte Compose setTestTag API.

Devido a limitações da arquitetura de aplicativos MAUI no ecossistema Android, a regra de Nome de Texto de Edição aparecerá como Precisa de Revisão no painel quando uma falha for suspeitada para a versão 5.5.0 do SDK e superiores. 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, pode obter resultados para visualizações por trá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 se comportem de maneira adequada com a tecnologia assistiva, conforme desejado.

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

• Android - FLAG_SECURE

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