Notas de Lançamento do Axe DevTools Mobile de 5 de agosto de 2026

No iOS 26 e versões posteriores, se uma tela contiver texto com um sinal de porcentagem (por exemplo, um rótulo de texto dizendo "50% de desconto"), a regra Suporte para Tipo Dinâmico pode ser relatada como Incompleta em vez de aprovada ou reprovada. 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 aquela tela e relata incompleta para cada elemento que contém 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, uma vez que sua varredura 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** > **Tela e Tamanho do Texto** > **Texto Grande**, e confirme se o texto na tela é redimensionado adequadamente. Esse problema foi reportado à Apple. (#2985)

A regra de Contraste de Cor usa a estrutura 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 para trás (<), 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 com ícone. Como 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 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 de título de tela nativa - UIViewController.title, fazendo com que a regra de Título da Tela falhe em todas as telas do 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 degradê. Nesses casos, pode não conseguir determinar a cor do 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 conteúdo da web dentro do 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 do WKWebView está 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 os botões de incremento padrão não anunciam "esmaecido" 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 incremento desabilitados: 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 incremento padrão 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 relatar falsos positivos com LabelInName e LabelAtFront devido a uma propriedade associatedText incorreta encontrada (#1622)

Ao procurar uma melhoria para nossas regras, descobrimos que no XCTest, controles aninhados não são retornados na árvore de acessibilidade. Um bug foi reportado para 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 focalização da Apple podem ser imprecisas quando um `accessibilityIdentifier` é definido na imagem. Devido a esse comportamento inesperado, os resultados dos problemas de Nome do ImageView em aplicativos UIKit serão relatados como Necessita de Análise. Um relatório de bug foi enviado para a Apple. (#1633)

Estamos trabalhando ativamente em soluções para os seguintes falsos positivos e atualizaremos esta lista à medida que correções forem lançadas.

In Scroll View
O texto dentro de elementos que se comportam 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 "Necessita de Análise" 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 uma UIImageView tiver um accessibilityIdentifier definido, mas não for focável pelo VoiceOver, e tiver controles focáveis aninhados, a regra Active Control Name pode relatar um falso positivo na 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 próximo pode ser detectado, causando falhas nessas regras. (#1622)

A regra Label at Front verifica se o rótulo visível de um elemento aparece 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 que essa visualização de texto não é importante para acessibilidade, não poderemos dizer com segurança se você introduziu uma violação de acessibilidade.

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

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

Esta é uma limitação conhecida da plataforma Flutter acompanhada 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 não há outro anúncio disponível. Como AccessibilityEventsão disparados por ações do usuário, não conseguimos acessar a descrição correta se essa informação não for fornecida.

Para evitar este 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 sendo escaneado é visível para os usuários do seu aplicativo. Em casos onde o texto contido em uma visualização tem a mesma cor que o fundo, nosso algoritmo de Aprendizado de Máquina não consegue detectar se há algum texto presente, então 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 regra. O texto de dica não foi introduzido até o Android 8 (SDK 26). Usar este elemento no seu aplicativo XML atribuirá o texto de dica ao valor do campo de entrada de texto. As versões mais recentes do Android estão melhor 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. 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, 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. Essas 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 esse problema complexo. Enquanto isso, se o TalkBack não conseguir alcançar essas visualizações, você pode desconsiderar os problemas correspondentes. Eles não requerem uma soluçã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 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 do Alvo de Toque atualmente não está sendo executada em nenhum componente de deslizante que foi escrito em Jetpack Compose. Nenhuma ação pode ser tomada neste momento. No entanto, uma correção está chegando em breve!

No Android API 30, um dos locais que tentamos salvar resultados localmente tem um erro de permissões. O resultado ainda será salvo como um arquivo JSON, apesar deste erro ser exibido. O erro pode ser suprimido comentando o código no bloco a seguir:

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 varredura.

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 esteja ativada. Se você optou por utilizar este recurso para seus aprimoramentos de segurança, recomendamos deixá-lo desativado para versões de teste interno onde você pode usar 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 quaisquer chamadas para o método setHideOverlayWindows(true) para setHideOverlayWindows(false) nas janelas de atividade afetadas.

Para desbloquear toda a funcionalidade 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 depuração ou teste do seu aplicativo que use dados simulados para evitar preocupações de segurança. Confira nosso guia para habilitar capturas de tela em aplicativos Android.

Se minimizar sua compilação, você verá um crash com um log de erro relatando que um adaptador não pôde ser encontrado ao tentar fazer login na biblioteca Axe DevTools. Desative o minify 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 ao layout para continuar recebendo atualizações. Se você continuar a usar as APIs Compose e encontrar um erro como `Esperado exatamente '1' nó, mas encontrados '2' nós que satisfazem: (isRoot)` ou `Nenhuma View inicializada, você chamou AxeDevToolsCompose.setComposeTestRule()?`, por favor, consulte a API Compose setTestTag.

Devido às limitações da arquitetura do app MAUI ao renderizar no ecossistema Android, a regra de Nome do Edit Text aparecerá como Necessita Revisão no painel quando uma falha for suspeitada para a versão SDK 5.5.0 e superiores. Por favor, confirme o comportamento correto manualmente neste caso.

Ao implementar diálogos ou modais personalizados que não estendem os controles nativos, você pode obter resultados para views atrás do modal. Nesse caso, recomendamos não executar nossa ferramenta contra esses modais ou diálogos personalizados e, em vez disso, verificar manualmente se eles se comportam 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 feitas. Muitas vezes, isso ocorre por razões de segurança em seu aplicativo de produção. Considere remover essa exigência para sua versão de teste para permitir funcionalidade completa no Painel Mobile do Axe DevTools.

• 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 frameworks. (#1643)