Note di rilascio di Axe DevTools Mobile 7 ottobre 2026

Quando si scansiona una schermata con gerarchie di visualizzazione grandi o complesse, il axeScan comando può richiedere più di 60 secondi per completarsi. Il proxy WebDriverAgent (WDA) di Appium applica un timeout predefinito di 60 secondi a comandi sconosciuti, e axeScan ricade in quella categoria. Se la scansione non è terminata entro quel tempo, WDA cancella la richiesta e il test genera un errore di timeout

Per sovrascrivere il timeout per comando per comandi proxy WDA come axeScan, consigliamo le seguenti impostazioni nelle tue capacità Appium:

• appium:commandTimeouts: 240000 (4 minuti)
• appium:wdaConnectionTimeout: 30000 (5 minuti)

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 sei su Xcode 27 e stai eseguendo un'app Mobile Analyzer Desktop precedente alla versione 2.0.0, l'app non può aprire il simulatore iOS. Si verifica un errore quando tenta di avviare /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app Non è possibile avviare una scansione basata su simulatore fino a quando questo problema non è risolto.

Per eseguire scansioni utilizzando un simulatore su Xcode 27, aggiorna l'Analizzatore Desktop alla versione 2.0.0+. Con questo aggiornamento, nota che i risultati di accessibilità ora si trovano in Axe Developer Hub.

L'SDK Axe DevTools utilizza il framework Vision di Apple per leggere il testo dallo schermo per diverse regole di accessibilità (ad esempio, Contrasto del Colore, Visualizzazioni in Collisione, qualsiasi regola che dipende dal testo rilevato da Vision).

Vision non restituisce sempre lo stesso testo rilevato tra esecuzioni dello stesso schermo. Quando Vision non rileva il testo su un controllo, le regole che dipendono da quel testo non verranno eseguite per quell'elemento in quella scansione. I risultati possono apparire incoerenti tra due scansioni dello stesso schermo - un problema che fallisce in una scansione potrebbe essere assente nella successiva.

Quando una regola basata su Vision riporta un errore, l'errore stesso è accurato. L'incoerenza sta nel fatto se la regola venga eseguita o meno. Per superare questo problema, prova quanto segue:

• Riesegui la scansione. Se una regola basata su Vision è stata saltata per un controllo, un'altra scansione dello stesso schermo spesso la rileva.
• Tratta qualsiasi errore di regola basata su Vision come valido - se Contrasto del Colore segnala un controllo, il problema di contrasto è reale e dovrebbe essere affrontato.
• Per la verifica manuale, utilizza il riferimento della Deque University per il criterio di successo WCAG rilevante. (I collegamenti si trovano in fondo a ciascuna pagina delle regole.)

Su iOS 26 e successivi, se una schermata contiene testo con un segno di percentuale (ad esempio, un'etichetta di testo che recita "50% di Sconto"), la regola Supporta il Tipo Dinamico potrebbe riportare come Incompleto invece di un successo o un fallimento. Questa regola dipende da una verifica di accessibilità fornita da Apple, e quella verifica interrompe l'esecuzione del test quando incontra segni di percentuale. Per mantenere i tuoi test operativi, la nostra regola salta il controllo per quella schermata e riporta incompleto per ogni elemento contenente un segno di percentuale. Tutte le altre regole funzionano normalmente sulla schermata, e le altre schermate non sono influenzate.

Non è necessaria alcuna azione, poiché la tua scansione verrà comunque completata. Per controllare il supporto del Tipo Dinamico per queste schermate, aumenta la dimensione del testo sul tuo dispositivo sotto **Impostazioni** > **Accessibilità** > **Display e Dimensione del Testo** > **Testo Grande**, e conferma che il testo sulla schermata si scala correttamente. Questo problema è stato segnalato ad Apple. (#2985)

La regola del Contrasto di Colore utilizza il framework Vision di Apple (Riconoscimento Ottico dei Caratteri, o OCR) per leggere il testo all'interno dei confini di un elemento. L'OCR può occasionalmente identificare erroneamente piccoli glifi simili a icone - come le chevron delle frecce indietro (<), i puntini, i simboli decorativi - come testo. Quando ciò accade, la regola del Contrasto di Colore si attiva su un elemento che non contiene testo leggibile, il che può produrre un risultato per un pulsante costituito solo da un'icona. Poiché l'output dell'OCR non è deterministico tra le varie scansioni, lo stesso elemento può apparire nei risultati del Contrasto di Colore in una scansione e essere riportato come "NON APPLICABILE" nella successiva. Questa è una caratteristica nota dell'OCR, non un difetto nella regola.

Per aggirare questo problema, puoi utilizzare le ignore API per sopprimere i risultati del Contrasto di Colore per gli elementi interessati.

Flutter non mappa AppBar.title alla proprietà nativa del titolo dello schermo - UIViewController.title, causando il fallimento della regola del Titolo dello Schermo su tutti gli schermi Flutter indipendentemente dalla presenza di un titolo descrittivo.

Questa è una limitazione nota della piattaforma Flutter monitorata in flutter/flutter#185894.

Quando si eseguono controlli di accessibilità su schermi di dimensioni più piccole o con dimensioni del carattere ridotte, la regola del Contrasto di Colore può riportare falsi positivi per sfondi a gradiente. In tali casi, potrebbe non essere in grado di determinare il colore del primo piano e invece confrontare i colori di sfondo tra loro, risultando in un fallimento.

Per aggirare questo problema, prova a eseguire i controlli di accessibilità su dispositivi più grandi. In alternativa, puoi scegliere di ignorare la regola nei tuoi test e controllare manualmente il Contrasto di Colore per queste visualizzazioni.

Le API di accessibilità di Apple possono riportare erroneamente contenuti web all'interno di WKWebView come "isVisible", anche quando la visualizzazione web è coperta da overlay nativi (come viste modali, avvisi o altri elementi UI nativi). Questo accade perché il sistema di accessibilità controlla se il contenitore del WKWebView stesso è visibile, piuttosto che se il suo contenuto web è effettivamente non ostruito e percepibile per l'utente.

iOS 26 contiene un bug di accessibilità in cui i pulsanti stepper predefiniti non annunciano "attutito" dalla Tecnologia Assistiva per indicare che non sono abilitati. Di conseguenza, anche le regole di iOS vedono questi pulsanti come abilitati, anche se non lo sono. È stato inviato un rapporto di bug ad Apple, ma fino a quando questo non sarà risolto, le seguenti regole potrebbero riportare risultati sui pulsanti stepper disattivati: AssociatedText, InaccessibleAction, e ColorContrast.

Finché Apple non risolve questo bug, la soluzione sarà [ignorare le regole](ios-ignore-rule). I pulsanti stepper predefiniti hanno gli identificatori "Decrement" e "Increment", e possono essere ignorati per identificatore se necessario.

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.

Alcuni schermi possono riportare falsi positivi con LabelInName e LabelAtFront a causa di una proprietà associatedText errata trovata (#1622)

Durante l'analisi di un miglioramento per le nostre regole, abbiamo scoperto che in XCTest, i controlli annidati non vengono restituiti nell'albero dell'accessibilità. Un bug è stato segnalato ad Apple. (#1110)

Nelle app UIKit, un'immagine senza un `accessibilityLabel` non è focalizzabile con la tecnologia assistiva per impostazione predefinita.
Le proprietà che utilizziamo per controllare la focalizzabilità da Apple possono essere inaccurate quando è impostato un `accessibilityIdentifier` sull'immagine. A causa di questo comportamento inatteso, i risultati per i problemi di Nome ImmagineView nelle app UIKit verranno segnalati come Da Revisionare. È stato inviato un rapporto di bug ad Apple. (#1633)

Stiamo lavorando attivamente a delle correzioni per i seguenti falsi positivi e aggiorneremo questo elenco man mano che le correzioni verranno rilasciate.

In Scroll View
Il testo all'interno di elementi che si comportano come banner, intestazioni/piè di pagina fissi, pulsanti di azione flottanti e visualizzazioni di tab personalizzate può essere segnalato con un messaggio "Da Revisionare" o "Fail". Per rendere questi elementi disponibili a chi richiede testo più grande, utilizza UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Se un UIImageView ha un accessibilityIdentifier impostato ma non è focalizzabile da VoiceOver, e ha controlli focalizzabili annidati al suo interno, Nome Controllo Attivo può riportare un falso positivo sull'UIImageView. Rimuovere il accessibilityIdentifier risolve il problema. Un bug è stato segnalato ad Apple. (#1633)

Label In Name and Label At Front
Queste due regole cercano l'etichetta visibile di un controllo tra gli elementi vicini per determinare lo stato della regola. In alcune gerarchie di vista, il testo vicino potrebbe essere rilevato in modo errato causando il fallimento di queste regole. (#1622)

La regola Label at Front verifica che l'etichetta visibile di un elemento venga all'inizio del suo testo annunciato. Un fallimento della regola può verificarsi quando il testo visibile di un elemento interattivo contiene un'abbreviazione (ad es. "GB", "km") o un identificatore oscurato/troncato, e l'annuncio di accessibilità consiste nelle parole rappresentate (ad es. "gigabyte", "chilometri"), anche se questo è il modello raccomandato per rendere il contenuto abbreviato o troncato amichevole per i lettori di schermo.

Se la prima parte dell'etichetta visibile di un elemento interattivo corrisponde all'inizio dell'annuncio del lettore di schermo e solo la parte abbreviata/oscurata differisce, il risultato segnalato può essere tranquillamente ignorato. Verifica con un lettore di schermo che l'annuncio completo venga letto come previsto.

Quando si utilizza del testo decorativo in viste come "Icone di Contatto", è possibile introdurre un problema di accessibilità. Se utilizzi una vista di testo per visualizzare lettere invece di generare immagini con le lettere desiderate come vettori, e dichiari poi che questa vista di testo non è importante per l'accessibilità, non saremo in grado di determinare con affidabilità se hai introdotto una violazione di accessibilità.

Se modifichi il testo focalizzabile per ignorare due o meno caratteri, potresti inavvertitamente ignorare molti pulsanti a una parola in varie lingue (ad es. "OK", "No", "Sí"). Per evitare questi problemi, dovresti prelevare le lettere desiderate dalla parola che desideri rappresentare nell'icona e generare le lettere come parte dell'immagine anziché come viste di testo separate. `FocusableText` quindi non funzionerà su quelle visualizzazioni.

Flutter non mappa AppBar.title alla proprietà nativa del titolo dello schermo - Activity.setTitle, causando il fallimento della regola del Titolo dello Schermo su tutti gli schermi Flutter indipendentemente dalla presenza di un titolo descrittivo.

Questa è una limitazione nota della piattaforma Flutter monitorata in flutter/flutter#185894.

In alcuni casi, le tecnologie assistive si affidano a AccessibilityEvent descrizioni dal sistema Android per annunciare informazioni all'utente quando non sono disponibili altri annunci. Poiché AccessibilityEventvengono attivati dalle azioni dell'utente, non siamo in grado di accedere alla descrizione corretta se queste informazioni non sono fornite.

Per evitare questo problema, assicurati che tutte le visualizzazioni rilevanti siano contrassegnate come importanti per l'accessibilità. Questo permetterà a Talkback di accedere alle informazioni dalla visualizzazione, che il nostro strumento può quindi rilevare.

La nostra regola del Contrasto di Colore dipende dal Machine Learning per rilevare il testo, il che garantisce che il testo in fase di scansione sia visibile agli utenti della tua applicazione. Nei casi in cui il testo contenuto in una vista è dello stesso colore dello sfondo, il nostro algoritmo di Machine Learning non è in grado di rilevare se è presente del testo, quindi la regola del Contrasto di Colore non si attiva su questa vista.

Le app scritte con XML che utilizzano la funzione di testo suggerito potrebbero ricevere falsi positivi con la regola EditTextName . La funzionalità di testo suggerito è stata introdotta solo con Android 8 (SDK 26). Utilizzare questo elemento nella tua app XML assegnerà il testo suggerito al valore del campo di input di testo. Le versioni più recenti di Android sono meglio attrezzate per rendere questa esperienza accessibile.

Per risolvere questo problema, il nostro primo consiglio è di eseguire i test su versioni più recenti di Android. Tuttavia, se è importante che l'app sia accessibile su versioni precedenti di Android, potresti considerare di evitare l'uso della funzione hintText , poiché non è ufficialmente supportata.

Potresti vedere risultati per visualizzazioni che sono nascoste dietro altre visualizzazioni sullo schermo. Queste visualizzazioni nascoste non sono disponibili per le tecnologie assistive, ma Axe DevTools Mobile le riporta comunque come problemi.

Stiamo lavorando a una soluzione per questo complesso problema. Nel frattempo, se TalkBack non riesce a raggiungere queste visualizzazioni, puoi ignorare i problemi corrispondenti. Non richiedono una soluzione per garantire l'accessibilità.

Il rilevamento del testo di ML Kit è richiesto in molte delle regole di Axe DevTools Mobile per assicurare l'accuratezza dei risultati. La libreria ML Kit dovrebbe essere importata automaticamente quando si fa riferimento ad Axe DevTools Mobile nei tuoi test automatizzati Espresso o UIAutomator. In alcuni casi, tuttavia, l'importazione automatica non avviene e vedrai il seguente errore nel logcat:

La regola di Spaziatura dei Target di Tocco non è attualmente eseguita su alcun componente slider scritto in Jetpack Compose. Al momento non si possono prendere provvedimenti. Tuttavia, una soluzione è in arrivo presto!

Su Android API 30, una delle posizioni in cui tentiamo di salvare i risultati localmente ha un errore di autorizzazione. Nonostante questo errore venga visualizzato, il risultato sarà ancora salvato come file JSON. L'errore può essere soppresso commentando il codice nel seguente blocco:

In alcune app ibride e multipiattaforma, potremmo restituire risultati inaspettati quando gli elementi in una vista a scorrimento sono parzialmente fuori schermo. Per testare un elemento per l'accessibilità, assicurati che sia completamente sullo schermo prima di eseguire la scansione.

Introdotta con API 31 (Android 12) è la capacità di nascondere le sovrapposizioni non di sistema. Per utilizzare l'app Axe Analyzer, assicurati che questa impostazione non sia attiva. Se hai scelto di utilizzare questa funzione per i suoi miglioramenti di sicurezza, ti consigliamo di lasciarla disattivata per le build di test interne dove puoi utilizzare dati di test in sicurezza ed eliminare in questo modo i problemi di sicurezza. Note: this setting does not affect Google's accessibility scanner app as it's considered a system overlay.

Per utilizzare l'app Axe Accessibility Analyzer, aggiorna qualsiasi chiamata al metodo setHideOverlayWindows(true) con setHideOverlayWindows(false) nelle finestre delle attività interessate.

Per sbloccare la piena funzionalità di Axe DevTools per Mobile, assicurati che gli screenshot siano abilitati. Raccomandiamo di abilitare gli screenshot su una versione di debug o di test della tua app che utilizza dati fittizi per evitare problemi di sicurezza. Consulta la nostra guida per abilitare gli screenshot nelle app Android.

Se minimizzi il tuo build, vedrai un arresto anomalo con un log di errore che riporta che un adattatore non è stato trovato quando si tenta di accedere alla libreria Axe DevTools. Disabilita la minimizzazione per i tuoi build di debug con Axe DevTools implementato. (#729)

Una build con r8 abilitato può tentare di minimizzare la libreria axeDevTools, causando un errore simile a:

Le API di Compose sono deprecate, per favore utilizza le API indipendenti dal layout per continuare a ricevere aggiornamenti. Se continui a utilizzare le API di Compose e incontri un errore del tipo `Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)` o `No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?`, per favore fai riferimento a API Compose setTestTag.

A causa delle limitazioni dell'architettura dell'app MAUI nel rendering nell'ecosistema Android, la regola per il Nome degli Edit Text apparirà come Da Rivedere nel dashboard quando viene sospettato un errore per la versione SDK 5.5.0 e successive. Si prega di confermare manualmente il corretto funzionamento in questo caso.

Quando implementi dialoghi o modali personalizzati che non estendono i controlli nativi, potresti ottenere risultati per visualizzazioni dietro il modale. In questo caso, raccomandiamo di non eseguire il nostro strumento contro questi modali o dialoghi personalizzati e invece controllarli manualmente per assicurarsi che si comportino con le tecnologie assistive come desiderato.

Se lo screenshot manca dalla pagina dei dettagli della scansione, la tua app potrebbe impedire la cattura degli screenshot. Spesso ciò avviene per motivi di sicurezza nella tua applicazione in produzione. Considera di rimuovere questo requisito per la tua build di test per consentire la piena funzionalità nel Pannello di Controllo Mobile di Axe DevTools.

• Android - FLAG_SECURE

Alcuni nomi di scansioni Android che sono preimpostati come titolo dello schermo appariranno come il nome completo della classe incluso l'identificatore del bundle. In una versione futura, questo sarà risolto in modo che il titolo dello schermo sia formattato in un nome più leggibile. Come soluzione alternativa, puoi impostare il nome della scansione dal pannello di controllo o dai framework. (#1643)