Notas de Lançamento do Axe DevTools Mobile - 8 de setembro de 2026

Este status está obsoleto e será removido em outubro de 2026. Naquele momento, regras ignoradas serão puladas na iteração e não retornarão mais um resultado.

Note que AxeDevTools itself não está obsoleto. Os seguintes métodos serão substituídos ou removidos completamente na versão de outubro de 2026.

• ignoreByViewIdResourceName(viewIdResourceName: String, ruleList: List) (Será substituído por ignoreRulesOnElementWithId(id: String, vararg rules: AxeRuleName))
• ignoreRules(rulesToIgnore: List)
• resetIgnoredRules()
• tagScansAs(tag: TagSet)
• deleteResult(axeDevToolsResultKey: AxeDevToolsResultKey)
• getResult(axeDevToolsResultKey: AxeDevToolsResultKey)

• getResult()
• postResult()
• deleteResult()
• tag()
• setScanName()
• getUserInfo()
• getResultSync()
• postResultSync()
• deleteResultSync()
• tagSync()
• setScanNameSync()
• getSessionId()
• BASE_FRONTEND_URL
• DB_DEFAULT_URL
• DB_QA_URL
• DB_DEV_URL

O conceito de regras experimentais será completamente removido na versão de outubro. O mesmo se aplica às etiquetas - elas desaparecerão com a descontinuação do Painel Móvel.

Essas regras eram experimentais e não estão sendo promovidas. Elas foram removidas de nossa iteração de regras.

• AxeDevToolsResultKey
• AxeDevToolsResultSummaryResponse
• ConnectionConfig - Isto será substituído por dbUrl construtor de argumento único
• class TagsSet()
• Regras experimentais estão sendo promovidas ou removidas

O SDK do Axe DevTools usa o framework Vision da Apple para ler texto da tela para várias regras de acessibilidade (por exemplo, Contraste de Cor, Visualizações Colidentes, 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 percebe o texto em um controle, as regras que dependem desse texto não serão executadas para aquele elemento naquela verificação. As descobertas podem parecer inconsistentes entre duas verificações da mesma tela - um problema que falha em uma verificação pode estar ausente na próxima.

Quando uma regra baseada em 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 verificação novamente. Se uma regra baseada em Vision foi ignorada para um controle, outra varredura da mesma tela frequentemente a detecta.
• Considere qualquer falha de regra baseada em Vision como válida - se o Contraste de Cor sinalizar um controle, o problema de contraste é real e deve ser resolvido.
• Para verificação manual, use a referência da Universidade Deque para o critério de sucesso WCAG relevante. (Os links podem ser encontrados na parte inferior de cada página de regras.)

No iOS 26 e posteriores, se uma tela contiver texto com um sinal de porcentagem (por exemplo, um rótulo de texto dizendo "50% Off"), a regra Suporta Tipo Dinâmico pode ser relatada como Incompleta em vez de passar ou falhar. Esta regra depende de uma auditoria de acessibilidade fornecida pela Apple, e essa auditoria interrompe a execução do teste quando encontra sinais de porcentagem. Para manter seus testes em execução, nossa regra pula a verificação para essa tela e relata incompleta para cada elemento que contenha 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 verificação ainda 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** > **Exibição e Tamanho do Texto** > **Texto Amplo**, e confirme se o texto na tela dimensiona adequadamente. 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 texto dentro dos limites de um elemento. O OCR pode ocasionalmente identificar de forma errada glifos pequenos parecidos com ícones - como setas em forma de "<", marcadores, símbolos decorativos - como texto. Quando isso acontece, a regra de Contraste de Cor é executada em um elemento que não contém texto legível, o que pode produzir um resultado para um botão apenas de ícone. Porque a saída do OCR não é determinística entre as verificações, o mesmo elemento pode aparecer nos resultados de Contraste de Cor em uma verificação e ser relatado como "INAPLICÁVEL" na próxima. 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 os resultados de Contraste de Cor para os elementos afetados.

O Flutter não mapeia AppBar.title para a propriedade de título de tela nativa - 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 rastreada em flutter/flutter#185894.

Ao realizar 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 as cores de fundo entre si, resultando em uma falha.

Para contornar esse problema, tente realizar 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 conteúdo da web dentro do WKWebView como "isVisible", mesmo quando a visualização web está coberta por sobreposições nativas (como visualizações modais, alertas ou outros elementos de IU nativos). Isso ocorre porque o sistema de acessibilidade verifica se o contêiner do WKWebView está visível, em vez de verificar se o 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 "desativado" 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 arquivado com 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 de stepper padrão têm os identificadores "Decrement" e "Increment", e podem ser ignorados pelo 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)

Ao considerar uma melhoria para nossas regras, descobrimos que no XCTest, controles aninhados não são retornados na árvore de acessibilidade. Um bug foi relatado à 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 possibilidade de foco 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 relatados como Precisando de Revisão. Um relatório de bug foi arquivado com 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 que se comportam como banner, cabeçalhos/rodapés fixos, botões de ação flutuantes e visualizações de guia 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 uma UIImageView tiver um accessibilityIdentifier definido mas não for focável pelo VoiceOver, e tiver controles focáveis aninhados, o Nome do Controle Ativo pode relatar um falso positivo na UIImageView. Remover o accessibilityIdentifier resolve o problema. Um relatório de bug foi arquivado com a Apple. (#1633)

Label In Name and Label At Front
Essas duas regras procuram o rótulo visível de um controle entre os 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 a falha dessas regras. (#1622)

A regra de Label at Front verifica se o rótulo visível de um elemento vem no início do 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 este seja o padrão recomendado para tornar o conteúdo abreviado ou truncado amigá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 pretendido.

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 declarar essa visualização de texto como não importante para acessibilidade, não poderemos determinar com confiança se você introduziu uma violação de acessibilidade.

Se você editar o 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 capturar 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. `TextoFocável` então não será executado nessas visualizações.

O Flutter não mapeia AppBar.title para a propriedade de título de tela nativa - 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 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 conseguimos 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 sejam marcadas como importantes para acessibilidade. Isso permitirá que o Talkback acesse as informações da visualização, que nossa ferramenta pode então detectar.

Nossa regra de Contraste de Cor depende de Aprendizado de Máquina para detectar texto, o que garante que o texto sendo 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 do fundo, nosso algoritmo de Aprendizado de Máquina é incapaz de detectar se algum texto está presente, portanto, a regra de Contraste de Cor não é executada nesta visualização.

Apps escritos com XML que utilizam o recurso de texto de dica podem ver falsos positivos com a EditTextName . O texto de dica não foi introduzido até o Android 8 (SDK 26). Usar este elemento no seu app XML atribuirá o texto de dica 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 este 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 recurso 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 reporta como problemas.

Estamos trabalhando em uma correçã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 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 assegurar a precisão dos resultados. A biblioteca ML Kit deve ser importada automaticamente ao referenciar o Axe DevTools Mobile em seus testes automatizados Espresso ou UIAutomator. No entanto, em alguns casos, a importação automática não ocorre e você verá o seguinte erro no logcat:

A regra de Espaçamento do Alvo de Toque atualmente não está sendo executada em nenhum componente deslizante que foi 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 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:

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 quanto à acessibilidade, assegure-se de que ele esteja totalmente na tela antes de realizar a verificação.

Introduzida com API 31 (Android 12) está a capacidade de ocultar sobreposições não-sistêmicas. Para utilizar o app Axe Analyzer, por favor, assegure-se de que essa configuração não esteja ativada. Se você optou por utilizar este recurso para seus aprimoramentos de segurança, recomendamos deixá-lo desativado para builds de teste interno 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 toda a funcionalidade 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 utilize dados simulados 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 implementados. (#729)

Um build com r8 ativada 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 do tipo `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 de aplicativos MAUI na renderização no ecossistema Android, a regra Edit Text Name aparecerá como Necessita 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 nesse caso.

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

Se a captura de tela estiver ausente da página de detalhes da verificação, seu aplicativo pode estar impedindo que capturas 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 seu build de teste para permitir funcionalidade completa no Painel do Axe DevTools Mobile.

• Android - FLAG_SECURE

Alguns nomes de verificação 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)