Notas de Lançamento do Axe DevTools Mobile - 16 de Setembro de 2026

Se você está 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 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 estão encontrados em Axe Developer Hub.

O SDK Axe DevTools utiliza o framework Vision da Apple para ler texto na tela para várias regras de acessibilidade (por exemplo, Contraste de Cor, Visõ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 em um controle, as regras que dependem desse texto não serão executadas para esse elemento na análise. As descobertas 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 em Vision reporta uma falha, a falha em si é precisa. A inconsistência está em se a regra é executada ou não. Para superar este problema, experimente o seguinte:

• Reexecute a análise. Se uma regra baseada em Vision foi ignorada para um controle, outra análise da mesma tela frequentemente a detecta.
• Trate qualquer falha de regra baseada em Vision como válida - se o Contraste de Cor indicar um controle, o problema de contraste é real e deve ser solucionado.
• Para verificação manual, use a referência da Deque University para o critério de sucesso WCAG relevante. (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% de Desconto"), a regra de Suporte a Tipo Dinâmico pode ser reportada 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 quando encontra sinais de porcentagem. Para manter seus testes em execução, nossa regra ignora a verificação para essa tela e relata como incompleta para cada elemento que contém um sinal de porcentagem. Todas as demais 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 nessas telas, aumente o tamanho do texto no seu dispositivo em **Ajustes** > **Acessibilidade** > **Tamanho de Texto e Exibição** > **Texto Grande**, e confirme se o texto na tela se dimensiona adequadamente. Este problema foi reportado para a 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 identificar erroneamente pequenos glifos semelhantes a ícones - como setas de retorno (<), 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 somente com ícones. 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 reportado 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 resultados de Contraste de Cor para os elementos afetados.

Flutter não mapeia AppBar.title para a propriedade nativa de título da tela - UIViewController.title, fazendo com que a regra do 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 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 ser capaz de determinar a cor do primeiro plano e, em vez disso, comparar 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 de WKWebView como "isVisible", mesmo quando a visualização da web é coberta por sobreposições nativas (como visualizações modais, alertas ou outros elementos de interface nativos). Isso ocorre porque o sistema de acessibilidade verifica se o contêiner WKWebView em si está visível, em vez de se o conteúdo da web está realmente desobstruído e percebível pelo usuário.

O iOS 26 contém um bug de acessibilidade em que botões incrementadores padrão não anunciam "escurecido" por Tecnologia Assistiva para indicar que eles 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 reportar resultados em botões incrementadores desabilitados: AssociatedText, InaccessibleAction, e ColorContrast.

Até que a Apple corrija esse bug, a resolução será [ignorar as regras](ios-ignore-rule). Os botões incrementadores 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 reportar falsos positivos com LabelInName e LabelAtFront devido a uma propriedade associatedText incorreta ser 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 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 à 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 "Precisa 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 um UIImageView tiver um accessibilityIdentifier definido mas não for focável pelo VoiceOver, e tiver controles focáveis aninhados dentro dele, o Nome do Controle Ativo 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
Essas duas regras buscam 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, fazendo com que essas regras falhem. (#1622)

A regra "Rótulo na Frente" verifica se o rótulo visível de um elemento aparece no início do texto anunciado. Um erro 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 oculto/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 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/oculta diferir, o resultado sinalizado pode ser ignorado com segurança. Verifique com um leitor de tela se o anúncio completo é lido conforme 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 poderemos determinar de forma confiável se você introduziu uma violação de acessibilidade.

Se você editar o texto focalizável para ignorar dois ou menos caracteres, pode involuntariamente 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, não como visualizações de texto separadas. `FocusableText` então não será executado nessas visualizações.

Flutter não mapeia AppBar.title para a propriedade nativa de título da tela - Activity.setTitle, fazendo com que a regra do 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. Desde AccessibilityEventsã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 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 pode então detectar.

Nossa regra de Contraste de Cor depende do Aprendizado de Máquina para detectar texto, o que garante que o texto sendo verificado 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 é incapaz de detectar se há texto presente, então 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. No entanto, se for importante que o aplicativo 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. Estas 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 este 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 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 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:

A regra de Espaçamento de 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 neste 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 este erro ser exibido. O erro pode ser suprimido comentando o código no seguinte bloco:

Em alguns aplicativos híbridos e cross-platform, 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 totalmente na tela antes de realizar a análise.

Introduzida na API 31 (Android 12) está a capacidade de ocultar sobreposições não-sistema. Para utilizar o aplicativo Axe Analyzer, certifique-se de que esta configuração não está ativada. Se você optou por utilizar este recurso por suas melhorias de segurança, recomendamos deixá-lo desativado para as 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 qualquer chamada para o 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 capturas de tela estejam ativadas. Recomendamos ativar capturas de tela em uma versão de depuração ou teste do seu aplicativo que use dados simulados para evitar preocupações de segurança. Confira nosso guia para ativar capturas de tela em aplicativos Android.

Se minimizar sua construção, você verá uma falha com um log de erro relatando que um adaptador não pôde ser encontrado ao tentar fazer o login na biblioteca Axe DevTools. Desative a minimização para suas compilações de depuração com Axe DevTools implementado. (#729)

Uma compilação 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 a API Compose setTestTag.

Devido a limitações da renderização na arquitetura de aplicativo MAUI no ecossistema Android, a regra de Nome Editar Texto aparecerá como Necessita Revisão no painel quando uma falha for suspeitada para a versão 5.5.0 do SDK em diante. 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, você pode obter resultados para vistas 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 eles se comportem com a tecnologia assistiva conforme desejado.

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

• Android - FLAG_SECURE

Alguns nomes de digitalização Android que estão padronizados para o título da tela aparecerão como o nome completo da classe, incluindo o identificador do pacote. Em uma futura versão, isso será resolvido para que o título da tela seja formatado em um nome mais legível. Como solução, você pode definir o nome da digitalização a partir do painel ou frameworks. (#1643)