Notas de Lançamento do Axe DevTools Mobile de Agosto de 2026

No iOS 26 e versões posteriores, se uma tela contiver texto com um sinal de porcentagem (por exemplo, uma etiqueta de texto que diz "50% de desconto"), a regra de Suporte a Tipo Dinâmico pode ser relatada como Incompleta em vez de uma aprovação ou reprovação. Essa 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 informa incompleto para cada elemento que contém um sinal de porcentagem. Todas as outras regras funcionam normalmente na tela, e outras telas não são afetadas.

Nenhuma ação é necessária, uma vez que sua varredura ainda será concluída. Para verificar o suporte a Tipo Dinâmico para essas telas, aumente o tamanho do texto em seu dispositivo em **Ajustes** > **Acessibilidade** > **Tela e Tamanho do Texto** > **Texto Grande**, e confirme se o texto na tela se ajusta 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 o texto dentro dos limites de um elemento. OCR pode, ocasionalmente, identificar incorretamente pequenos glifos semelhantes a ícones - como setas de retorno (<), 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 produzir um resultado para um botão apenas de ícone. Como a saída de OCR não é determinística entre as varreduras, o mesmo elemento pode aparecer nos resultados de Contraste de Cor em uma varredura e ser relatado como "INAPLICÁVEL" na próxima. Essa é 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.

Flutter não mapeia AppBar.title para a propriedade de título da 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 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 ser capaz de 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 da WKWebView como "isVisible", mesmo quando a visualização da web é 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 próprio contêiner da WKWebView 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 em que os botões 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 registrado com a Apple, mas 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 esse bug, a solução será [ignorar as regras](ios-ignore-rule). Os botões 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 propriedade associatedText incorreta encontrada (#1622)

Enquanto analisávamos 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 do ImageView em aplicativos UIKit serão relatados como Necessitando Revisão. Um relatório de bug foi registrado com 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 em elementos que se comportam como banner, cabeçalhos/rodapés fixos, botões de ação flutuantes e visualizações de aba personalizadas podem ser marcados com uma mensagem de "Necessita Revisão" ou "Falha". Para tornar esses elementos disponíveis para aqueles que requerem texto ampliado, 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 possuir controles focáveis aninhados dentro dele, o NomeControlAtivo 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 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, causando falha nessas regras. (#1622)

A regra Label at Front verifica se o rótulo visível de um elemento está 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 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/obscurecida for diferente, o resultado marcado 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 declarar essa visualização de texto como não importante para acessibilidade, não poderemos dizer de maneira confiável se você introduziu uma violação de acessibilidade.

Se você editar o texto focável para ignorar duas ou menos letras, poderá 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. `TextoFocável` então não será executado nessas visualizações.

O Flutter não mapeia AppBar.title para a propriedade de título da tela nativa - 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. Como AccessibilityEvents são acionados por ações dos usuários, 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 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 Aprendizado de Máquina para detectar texto, o que garante que o texto escaneado seja visível para os usuários do seu aplicativo. Em casos nos quais o texto contido em uma visualização é da mesma cor que o fundo, nosso algoritmo de Aprendizado de Máquina não consegue detectar a presença de qualquer texto, então a regra de Contraste de Cor não é executada nessa visualização.

Apps 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 em seu aplicativo 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 resolver esse problema, nossa primeira recomendação é rodar seus testes em versões mais recentes do Android. Se for importante que o aplicativo seja acessível em versões anteriores do Android, convém evitar o uso do hintText recurso, pois ele não é oficialmente suportado.

Você pode ver resultados para vistas que estão ocultas atrás de outras vistas na tela. Essas vistas 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 esse problema complexo. Enquanto isso, se o TalkBack não puder acessar essas vistas, você pode desconsiderar 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 em seus testes automatizados de 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 do Alvo de Toque atualmente não está sendo executada em componentes de slider escritos 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 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 a acessibilidade de um elemento, certifique-se de que ele esteja totalmente na tela antes de realizar a verificação.

Introduzido com o API 31 (Android 12) está a habilidade de esconder 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 para 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, assim, eliminar preocupações com segurança. 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 quaisquer chamadas 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 as capturas de tela estejam habilitadas. Recomendamos habilitar capturas de tela em uma versão de debug ou teste do seu aplicativo que usa dados simulados para evitar preocupações com segurança. Confira nosso guia para ativar capturas de tela em aplicativos Android.

Se minificar sua build, você verá um travamento 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 minificação para suas builds de debug com Axe DevTools implementado. (#729)

Uma build com r8 ativado pode tentar minificar a biblioteca axeDevTools resultando em um erro semelhante a:

As APIs Compose estão obsoletas, por favor, utilize 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 `Esperado exatamente '1' nó, mas foram encontrados '2' nós que satisfazem: (éRaiz)` ou `Nenhuma View 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 será exibida como Necessita Revisão no painel quando uma falha for suspeita para a versão do SDK 5.5.0 e superior. 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, pode obter resultados para vistas atrá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 se comportem conforme desejado com tecnologia assistiva.

Se a captura de tela estiver faltando na página de detalhes de varredura, seu aplicativo pode estar impedindo que capturas de tela sejam tiradas. Isso geralmente ocorre por razões de segurança no seu aplicativo de produção. Considere remover esse requisito para sua build de teste para permitir funcionalidade completa no Painel do Axe DevTools Mobile.

• Android - FLAG_SECURE

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