Note di rilascio di Axe DevTools Mobile 23 ottobre 2026

Quando si scansiona uno schermo 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 ai comandi sconosciuti, e axeScan rientra in quella categoria. Se la scansione non è terminata entro quel tempo, WDA annulla la richiesta e il test genera un errore di timeout

Per bypassare il timeout per comando per i comandi proxy di WDA come axeScan, raccomandiamo 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 usi Xcode 27 e stai eseguendo un'app Desktop Analyzer Mobile precedente alla versione 2.0.0, l'app non può aprire il simulatore iOS. Fallisce quando tenta di lanciare /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app Non puoi iniziare una scansione basata su simulatore finché questo non è risolto.

Per eseguire scansioni usando un simulatore su Xcode 27, aggiorna il Desktop Analyzer 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 sullo schermo per diverse regole di accessibilità (ad esempio, Contrasto Colori, Vista Collidente, qualsiasi regola che dipenda 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 durante quella scansione. I risultati potrebbero 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 segnala un errore, l'errore stesso è accurato. L'incongruenza è se la regola viene eseguita o meno. Per superare questo problema, prova quanto segue:

• Ripeti 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 Colori 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 link possono essere trovati in fondo a ciascuna pagina delle regole.)

Su iOS 26 e versioni successive, se uno schermo contiene testo con un segno di percentuale (ad esempio, un'etichetta di testo che dice "50% di Sconto"), la regola Supporta Tipo Dinamico potrebbe segnalarlo come Incompleto invece di un pass o un fail. Questa regola si basa su un audit di accessibilità fornito da Apple, e quell'audit interrompe l'esecuzione del test quando incontra segni di percentuale. Per mantenere i tuoi test in esecuzione, la nostra regola salta il controllo per quello schermo e segnala incompleto per ciascun elemento contenente un segno di percentuale. Tutte le altre regole funzionano normalmente sullo schermo, e altri schermi non sono influenzati.

Non è richiesta alcuna azione, poiché la tua scansione si completerà comunque. Per verificare il supporto del Tipo Dinamico per questi schermi, aumenta la dimensione del testo sul tuo dispositivo sotto **Impostazioni** > **Accessibilità** > **Display e Dimensione Testo** > **Testo Grande**, e conferma che il testo sullo schermo si scala in modo appropriato. Questo problema è stato segnalato ad Apple. (#2985)

La regola Contrasto Colori 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 chevron a freccia indietro (<), punti elenco, simboli decorativi - come testo. Quando ciò accade, la regola Contrasto Colori viene eseguita su un elemento che non contiene testo leggibile, il che può produrre un risultato per un pulsante a icona. Poiché l'output dell'OCR non è deterministico tra le scansioni, lo stesso elemento potrebbe apparire nei risultati del Contrasto Colori in una scansione e essere segnalato come "INAPPLICABILE" nella successiva. Questa è una caratteristica nota dell'OCR, non un bug nella regola.

Per ovviare a questo problema, puoi utilizzare le ignore API per sopprimere i risultati di Contrasto Colori per gli elementi interessati.

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

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

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

Per ovviare a 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 verificare manualmente il Contrasto Colori per queste viste.

Le API di accessibilità di Apple possono riportare erroneamente contenuti Web all'interno di WKWebView come "isVisible", anche quando il web view è coperto da sovrapposizioni native (come viste modali, avvisi o altri elementi UI nativi). Questo accade perché il sistema di accessibilità verifica se il contenitore 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à per cui i pulsanti degli stepper predefiniti non annunciano "attenuato" dalla Tecnologia Assistiva per indicare che non sono abilitati. Di conseguenza, le regole iOS vedono anche questi pulsanti come abilitati anche se non lo sono. Un rapporto di bug è stato inoltrato ad Apple, ma fino a quando questo non sarà risolto, le seguenti regole potrebbero riportare risultati su pulsanti stepper disabilitati: AssociatedText, InaccessibleAction, e ColorContrast.

Fino a quando Apple non correggerà questo bug, la soluzione sarà [ignorare le regole](ios-ignore-rule). I pulsanti stepper predefiniti hanno gli identificatori "Decrementa" e "Incrementa", 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 "impropria" associatedText proprietà trovata (#1622)

Durante un miglioramento delle nostre regole, abbiamo scoperto che in XCTest, i controlli annidati non sono restituiti nell'albero di accessibilità. Un bug è stato inoltrato 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 potrebbero essere inaccurate quando un `accessibilityIdentifier` è impostato sull'immagine. A causa di questo comportamento inatteso, i risultati per i problemi del Nome ImageView nelle app UIKit verranno segnalati come Bisogno di Revisione. Un rapporto di bug è stato inoltrato ad Apple. (#1633)

Stiamo lavorando attivamente su correzioni per i seguenti falsi positivi e aggiorneremo questa lista man mano che le correzioni verranno rilasciate.

In Scroll View
Il testo all'interno di elementi con comportamento da banner, intestazioni/piedini aderenti, pulsanti di azione fluttuanti e viste a schede personalizzate possono essere contrassegnati con un messaggio "Necessita Revisione" o "Fallimento". Per rendere questi elementi disponibili a coloro che richiedono 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 dei controlli focalizzabili al suo interno, il Nome del Controllo Attivo potrebbe segnalare un falso positivo sull'UIImageView. La rimozione del accessibilityIdentifier risolve il problema. È stato segnalato un bug 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 errato vicino potrebbe essere rilevato causando il fallimento di queste regole. (#1622)

Il pulsante di azione fluttuante (FAB) dell'Android Accessibility Analyzer non è compatibile con la navigazione swipe di Talkback nelle versioni di Talkback precedenti alla 16.2. Con il rilascio della versione 16.2, Talkback ha risolto un bug nel loro codice per consentire il focus tramite swipe sugli FAB sovrapposti.

Si noti che questo è puramente un bug di Talkback, che non permetteva agli FAB visualizzati nei sovrapposizioni di accessibilità di acquisire o perdere focus tramite swipe. L'aggiornamento recente alla nostra app Accessibility Analyzer consente di analizzare più tipi di app; quindi potresti ora vedere questo problema.

Questo problema può essere risolto aggiornando Talkback alla versione 16.2 o successiva.

La regola Etichetta Frontale verifica che l'etichetta visibile di un elemento appaia all'inizio del suo testo annunciato. Un fallimento della regola può verificarsi quando il testo visibile di un elemento interattivo contiene un'abbreviazione (ad esempio "GB", "km") o un identificatore oscurato/troncato, e l'annuncio di accessibilità consiste nelle parole rappresentate (ad esempio "gigabyte", "chilometri"), anche se questo è il modello raccomandato per rendere i contenuti abbreviati o troncati accessibili ai 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 ignorato in sicurezza. Verifica con un lettore di schermo che l'annuncio completo venga letto come previsto.

Quando si utilizza testo decorativo in viste come "Icone dei Contatti", è possibile introdurre un problema di accessibilità. Se stai usando una vista di testo per visualizzare lettere invece di generare immagini con le lettere desiderate come vettori, e poi dichiari che la vista di testo non è importante per l'accessibilità, non saremo in grado di determinare in maniera affidabile se hai introdotto una violazione dell'accessibilità.

Se modifichi il testo focalizzabile per ignorare due o meno caratteri, potresti inavvertitamente ignorare molti pulsanti a una sola parola in varie lingue (ad esempio "OK", "No", "Sí"). Per evitare questi problemi, dovresti estrarre le lettere desiderate dalla parola che vuoi rappresentare nell'icona e generare le lettere come parte dell'immagine invece che come viste di testo separate. `FocusableText` quindi non verrà eseguito su queste viste.

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

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

In alcuni casi, la tecnologia assistiva si basa su AccessibilityEvent descrizioni dal sistema Android per annunciare informazioni all'utente quando non è disponibile nessun altro annuncio. Poiché AccessibilityEventsono attivati da azioni dell'utente, non siamo in grado di accedere alla descrizione corretta se queste informazioni non vengono fornite.

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

La nostra regola Contrasto Colori dipende dal Machine Learning per rilevare il testo, il che assicura che il testo scansionato sia visibile agli utenti della tua applicazione. Nei casi in cui il testo contenuto in una vista è dello stesso colore del fondo, il nostro algoritmo di Machine Learning non è in grado di rilevare se c'è del testo presente, quindi la regola Contrasto Colori non viene eseguita su questa vista.

Le app scritte con XML che utilizzano la funzione di testo di suggerimento potrebbero rilevare falsi positivi con la EditTextName regola. Il testo di suggerimento non è stato introdotto fino ad Android 8 (SDK 26). Utilizzando questo elemento nella tua app XML, il testo di suggerimento verrà assegnato al valore del campo di inserimento del testo. Le versioni più recenti di Android sono meglio equipaggiate per rendere accessibile questa esperienza.

Per superare questo problema, la nostra prima raccomandazione è eseguire i tuoi test su versioni più recenti di Android. Se è importante che l'app sia accessibile su versioni precedenti di Android, tuttavia, potresti considerare di evitare l'uso della hintText funzione, in quanto non è ufficialmente supportata.

Potresti vedere risultati per viste che sono nascoste dietro altre viste sullo schermo. Queste viste nascoste non sono disponibili per la tecnologia assistiva, ma Axe DevTools Mobile le segnala comunque come problemi.

Stiamo lavorando a una soluzione per questo complesso problema. Nel frattempo, se TalkBack non può raggiungere queste viste, 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 garantire l'accuratezza dei risultati. La libreria ML Kit dovrebbe essere importata automaticamente quando si fa riferimento ad Axe DevTools Mobile nei tuoi test automatici Espresso o UIAutomator. In alcuni casi, tuttavia, l'importazione automatica non avviene e vedrai il seguente errore nel logcat:

La regola di Spaziatura del bersaglio di tocco attualmente non funziona su alcun componente slider scritto in Jetpack Compose. Al momento non possono essere prese misure. Tuttavia, una soluzione è in arrivo!

Su Android API 30, una delle posizioni in cui tentiamo di salvare i risultati localmente presenta un errore di autorizzazione. Il risultato verrà comunque salvato come file JSON nonostante questo errore venga visualizzato. 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 a schermo prima di eseguire la scansione.

Introdotta con API 31 (Android 12) è la possibilità di nascondere sovrapposizioni non di sistema. Per utilizzare l'app Axe Analyzer, assicurati che questa impostazione non sia attivata. Se hai scelto di utilizzare questa funzione per i suoi miglioramenti di sicurezza, ti consigliamo di lasciarla disattivata per le versioni di test interne dove puoi utilizzare in sicurezza i dati di test ed eliminare così 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 ogni chiamata al metodo setHideOverlayWindows(true) all'interno delle finestre dell'attività interessata. setHideOverlayWindows(false) all'interno delle finestre dell'attività interessata.

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

Se riducete il vostro build, vedrete 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. Disabilitate la riduzione per i vostri build di debug con Axe DevTools implementato. (#729)

Un build con r8 abilitato potrebbe tentare di ridurre la libreria axeDevTools risultando in un errore simile a:

Le API Compose sono deprecate, per favore usate le API indipendenti dal layout per continuare a ricevere aggiornamenti. Se continuate a usare le API Compose e incontrate un errore simile a `Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)` o `No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?`, si prega di fare riferimento a l'API Compose setTestTag.

A causa delle limitazioni dell'architettura delle app MAUI nel rendering nell'ecosistema Android, la regola Nome Modifica Testo verrà mostrata come Da Rivedere nel dashboard quando si sospetta un errore per la versione SDK 5.5.0 e successive. Si prega di confermare manualmente il comportamento corretto per questo caso.

Quando implementate dialoghi o modali personalizzati che non estendono i controlli nativi, potreste ottenere risultati per le viste dietro il modale. In questo caso, consigliamo di non utilizzare il nostro strumento contro questi modali o dialoghi personalizzati e di verificarli manualmente per garantire che funzionino con la tecnologia assistiva come desiderato.

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

• Android - FLAG_SECURE

Alcuni nomi di scansione Android che sono predefiniti per il titolo dello schermo appariranno come nome completo della classe incluso l'identificatore del pacchetto. In un futuro aggiornamento, questo sarà risolto in modo che il titolo dello schermo sia formattato in un nome più leggibile. Come soluzione temporanea, potete impostare il nome della scansione dal dashboard o dai framework. (#1643)