Note di rilascio di Axe DevTools Mobile del 23 ottobre 2026

Durante la scansione di uno schermo con gerarchie di visualizzazione grandi o complesse, il comando axeScan 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 periodo, WDA annulla la richiesta e il test genera un errore di timeout.

Per modificare 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 hai Xcode 27 e stai eseguendo un'app Mobile Analyzer Desktop più vecchia della versione 2.0.0, l'app non può aprire il simulatore iOS. Si interrompe nel tentativo di lanciare /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app Non puoi avviare una scansione basata su simulatore finché questo problema non viene risolto.

Per eseguire scansioni utilizzando un simulatore su Xcode 27, aggiorna il Desktop Analyzer alla versione 2.0.0 o successiva. Con questo aggiornamento, nota che i risultati dell'accessibilità si trovano ora in Axe Developer Hub.

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

Vision non restituisce sempre lo stesso testo rilevato tra le esecuzioni dello stesso schermo. Quando Vision non rileva il testo su un controllo, le regole che fanno affidamento su 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'incoerenza sta nel fatto che la regola venga 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 basato su Vision come valido - se il Contrasto del colore segnala un controllo, il problema di contrasto è reale e dovrebbe essere affrontato.
• Per la verifica manuale, utilizza il riferimento di Deque University per il relativo criterio di successo WCAG. (I link possono essere trovati in fondo a ciascuna pagina delle regole.)

Su iOS 26 e successivi, se uno schermo contiene testo con un segno di percentuale (ad esempio, un'etichetta di testo che legge "50% Sconto"), la regola Supports Dynamic Type potrebbe riportare come Incompleto invece di un pass o 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 tenere 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 gli altri schermi non sono interessati.

Non è richiesta alcuna azione, poiché la tua scansione si completerà comunque. Per controllare il supporto per Dynamic Type su questi schermi, aumenta la dimensione del testo sul tuo dispositivo sotto **Impostazioni** > **Accessibilità** > **Schermo e testo** > **Testo grande** e conferma che il testo sullo schermo si adatta adeguatamente. Questo problema è stato segnalato ad Apple. (#2985)

La regola del Contrasto del colore utilizza il framework Visivo di Apple (Riconoscimento Ottico dei Caratteri, o OCR) per leggere il testo all'interno dei limiti di un elemento. L'OCR può occasionalmente identificare erroneamente piccoli glifi simili a icone - come simboli di frecce indietro (<), punti elenco, simboli decorativi - come testo. Quando ciò accade, la regola del Contrasto del colore si applica su un elemento che non contiene testo leggibile, il che può produrre un risultato per un pulsante solo icona. Poiché l'output dell'OCR non è deterministico tra le scansioni, lo stesso elemento può apparire nei risultati del Contrasto del colore in una scansione e essere riportato come "INAPPLICABILE" nella successiva. Questa è una caratteristica nota dell'OCR, non un bug nella regola.

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

Flutter non associa 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 tracciata in flutter/flutter#185894.

Quando si eseguono verifiche di accessibilità su schermi di dimensioni ridotte o con dimensioni del carattere ridotte, la regola del Contrasto del colore potrebbe segnalare falsi positivi per gli 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 errore.

Per aggirare questo problema, prova a eseguire le verifiche di accessibilità su dispositivi più grandi. In alternativa, puoi scegliere di ignorare la regola nei tuoi test e verificare manualmente il Contrasto del colore per queste viste.

Le API di accessibilità di Apple potrebbero segnalare erroneamente il contenuto web all'interno di WKWebView come "isVisible", anche quando la visualizzazione web è coperta da sovrapposizioni native (come viste modali, avvisi o altri elementi dell'interfaccia utente 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à in cui i pulsanti stepper predefiniti non annunciano "dimmed" con la Tecnologia Assistiva per indicare che non sono abilitati. Di conseguenza, le regole di iOS vedono anche questi pulsanti come abilitati, anche se non lo sono. È stato presentato un rapporto di bug ad Apple, ma fino a quando questo non sarà risolto, le seguenti regole potrebbero riportare risultati sui pulsanti stepper disabilitati: AssociatedText, InaccessibleAction, e ColorContrast.

Fino a quando Apple non risolverà questo bug, la soluzione sarà [ignorare le regole](ios-ignore-rule). I pulsanti stepper predefiniti hanno gli identifikatori "Decrementa" e "Incrementa", e possono essere ignorati per identifikatore 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 segnalare falsi positivi con LabelInName e LabelAtFront a causa di un'errata associatedText proprietà trovata (#1622)

Durante il miglioramento delle nostre regole, abbiamo scoperto che in XCTest, i controlli annidati non vengono restituiti nell'albero di accessibilità. È stato presentato un bug a Apple. (#1110)

Nelle app UIKit, un'immagine senza un `accessibilityLabel` non è focalizzabile con la tecnologia assistiva per impostazione predefinita.
Le proprietà che utilizziamo per verificare la focalizzabilità da Apple potrebbero essere inaccurate quando è impostato un `accessibilityIdentifier` sull'immagine. A causa di questo comportamento inaspettato, i risultati per i problemi di Nome Immagine nelle app UIKit verranno riportati come Bisogna Review. È stato presentato un bug a Apple. (#1633)

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

In Scroll View
Il testo all'interno di elementi che si comportano come banner, intestazioni/piè di pagina adesivi, pulsanti di azione flottanti e viste a schede personalizzate possono essere contrassegnati con un messaggio "Bisogna Review" o "Fail". Per rendere disponibili questi elementi 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 controlli focalizzabili nidificati al suo interno, Active Control Name potrebbe segnalare un falso positivo sull'UIImageView. Rimuovere il accessibilityIdentifier risolve il problema. È stato presentato 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 visualizzazione, potrebbe essere rilevato il testo errato vicino causando il fallimento di queste regole. (#1622)

Il Floating Action Button (FAB) di Android Accessibility Analyzer non è compatibile con la navigazione swiper di Talkback nelle versioni di Talkback precedenti alla 16.2. Con il rilascio della versione 16.2, Talkback ha corretto un bug nel loro codice per consentire il focus tramite swipe per i FAB sovrapposti.

Nota che questo è puramente un bug di Talkback, che non permetteva ai FAB resi nelle sovrapposizioni di Accessibilità di acquisire o perdere il focus tramite swipe. Il recente aggiornamento alla nostra app Accessibility Analyzer consente di esaminare più tipi di app; quindi potresti ora riscontrare questo problema.

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

La regola Label at Front verifica che l'etichetta visibile di un elemento venga all'inizio del testo annunciato. Un fallimento della regola potrebbe verificarsi quando il testo visibile di un elemento interattivo contiene un'abbreviazione (ad es. "GB", "km") o un identificativo oscurato / troncato, e l'annuncio di accessibilità consiste delle parole rappresentate (ad es. "gigabyte", "chilometri"), anche se questo è il modello raccomandato per rendere il contenuto abbreviato o troncato adatto 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 tranquillamente ignorato. Verificare con un lettore di schermo che l'annuncio completo venga letto come previsto.

Quando si utilizza testo decorativo in viste come "Icone di Contatto", è possibile introdurre un problema di accessibilità. Se si utilizza una vista di testo per visualizzare lettere invece di generare immagini con le lettere desiderate come vettori, e poi si dichiara che la vista di testo non è importante per l'accessibilità, non saremo in grado di determinare in modo affidabile se è stata introdotta una violazione dell'accessibilità.

Se si modifica il testo focalizzabile per ignorare due o meno caratteri, si potrebbero ignorare inavvertitamente molti pulsanti di una parola in varie lingue (ad es. "OK", "No", "Sí"). Per evitare questi problemi, si dovrebbe prendere le lettere desiderate dalla parola che si desidera rappresentare nell'icona e generare le lettere come parte dell'immagine invece di viste di testo separate. `FocusableText` quindi non si applicherà a quelle viste.

Flutter non associa 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 tracciata 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. Siccome AccessibilityEventi sono attivati da azioni dell'utente, non siamo in grado di accedere alla descrizione corretta se queste informazioni non vengono fornite.

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

La nostra regola del Contrasto del colore dipende dall'apprendimento automatico per rilevare il testo, che garantisce che il testo scansionato sia visibile agli utenti della tua applicazione. Nei casi in cui il testo contenuto in una vista ha lo stesso colore dello sfondo, il nostro algoritmo di apprendimento automatico non è in grado di rilevare se è presente del testo, quindi la regola del Contrasto del colore non viene eseguita su questa vista.

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

Per superare questo problema, la nostra prima raccomandazione è 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 , in quanto non è ufficialmente supportata.

Potresti vedere i 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 problema complesso. 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 automaticamente importata quando si fa riferimento a 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 del Bersaglio del Tocco attualmente non viene eseguita su alcun componente slider scritti in Jetpack Compose. Non è possibile eseguire azioni in questo momento. Tuttavia, una soluzione sta arrivando presto!

Su Android API 30, una delle posizioni in cui tentiamo di salvare i risultati localmente riscontra 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 di scorrimento sono parzialmente fuori schermo. Per testare un elemento per l'accessibilità, assicurarsi che sia completamente sullo schermo prima di eseguire la scansione.

Con API 31 (Android 12) è stata introdotta la capacità di nascondere le sovrapposizioni non di sistema. Per utilizzare l'app Axe Analyzer, assicurarsi che questa impostazione non sia attivata. Se hai scelto di utilizzare questa funzione per i suoi miglioramenti di sicurezza, ti raccomandiamo di lasciarla disattivata per le build di test interne dove puoi utilizzare in sicurezza i dati di prova 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 qualsiasi chiamata al metodo setHideOverlayWindows(true) su tutte le finestre delle attività interessate. setHideOverlayWindows(false)

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 fittizi per evitare preoccupazioni di sicurezza. Consulta la nostra guida per abilitazione degli screenshot nelle app Android.

Se si minifica la build, si verificherà un arresto anomalo con un log di errore che segnala che un adattatore non è stato trovato durante il tentativo di accesso alla libreria Axe DevTools. Disabilitare la minificazione per le build di debug con Axe DevTools implementato. (#729)

Una build con r8 abilitato potrebbe tentare di minificare la libreria axeDevTools causando un errore simile a:

Le API di Compose sono deprecate, si prega di usare 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()?`, consulta API Compose setTestTag.

A causa delle limitazioni dell'architettura delle app MAUI nel contesto Android, la regola Nome Edit Text apparirà come Da Revisionare nel cruscotto quando si sospetta un fallimento per la versione SDK 5.5.0 e successive. Si prega di confermare manualmente il corretto comportamento in questo caso.

Quando implementi dialoghi personalizzati o modali che non si estendono dai controlli nativi, potresti ottenere risultati per le viste dietro il modale. In questo caso, si consiglia di non eseguire il nostro strumento contro questi modali o dialoghi personalizzati e invece verificarli manualmente per assicurarsi che si comportino con la tecnologia assistiva come desiderato.

Se lo screenshot manca dalla pagina dei dettagli della scansione, la tua app potrebbe impedire che vengano scattate schermate. Spesso questo avviene per motivi di sicurezza nella tua applicazione di produzione. Valuta la possibilità di rimuovere questo requisito per la tua build di test per consentire la piena funzionalità nel Cruscotto Mobile di Axe DevTools.

• Android - FLAG_SECURE

Alcuni nomi di scansioni Android che sono predefiniti al 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 cruscotto o dai framework. (#1643)