Note di rilascio di Axe DevTools Mobile del 5 agosto 2026

This page is not available in the language you requested. You have been redirected to the English version of the page.
Link to this page copied to clipboard

5 agosto 2026

Not for use with personal data

iOS

  • SDK iOS (axeDevToolsXCUI v4.1.0)
  • App desktop analizzatore iOS (axe-devtools-mobile-desktop-app v1.3.0)

Come aggiornare: SDK iOS, App desktop analizzatore iOS

Android

  • SDK Android (axe-devtools-android v9.1.0)
  • Plugin Gradle per Android (axe-devtools-android-plugin v1.2.0)
  • Analizzatore Android (Axe Accessibility Analyzer v3.2.0)

Come aggiornare Plugin Gradle per Android, Analizzatore Android

Novità?

Ignorare le schermate durante l'esecuzione della scansione automatica

Stai utilizzando la Scansione Automatica con i nostri SDK? Ora puoi ignorare le schermate che non dovrebbero essere incluse nei risultati della scansione racchiudendo le sezioni con AxeAutoScan.skipScan. La sessione di scansione riprende automaticamente quando il blocco termina. Trova i dettagli sull'implementazione della Scansione Automatica nelle seguenti pagine:

Maggiore Copertura WCAG

Deque ha un impegno costante a offrire e ottimizzare regole che rilevano con precisione i veri problemi di accessibilità. Con questo rilascio, stiamo espandendo la nostra copertura WCAG 2.0 promuovendo due regole che erano precedentemente contrassegnate come sperimentali.

iOS

La regola Supporta Tipo Dinamico è diventata una regola completa. Questa regola si mappa su WCAG 2.0, 1.4.4 Ridimensionamento Testo (AA) e ora viene eseguita di default, mentre prima era in opt-in. Tipo Dinamico è una funzionalità iOS che consente agli utenti di impostare una dimensione di carattere preferita a livello di dispositivo. Questa regola verifica che le app rispettino tale preferenza utilizzando font scalabili. Si prega di notare che questa regola viene eseguita sull'API di audit di Accessibilità XCUI di Apple, che richiede iOS 17.0+. La regola Supporta Tipo Dinamico viene eseguita solo durante i test mirati. Il supporto per la Scansione Automatica è in arrivo!
Scopri di più su questa regola di accessibilità: Supporta Tipo Dinamico.

Android

La regola Azione Inaccessibile per Android è diventata una regola completa, espandendo la nostra copertura di WCAG 2.0, 2.1.1 Tastiera (A). Questa regola verifica che l'azione associata a un elemento interattivo possa essere sia messa a fuoco e attivata tramite tecnologia assistiva come TalkBack o Switch Access.
Scopri di più su questa regola di accessibilità: Azione Inaccessibile.

Correzioni

iOS

  • Miglioramenti alla precisione della regola Testo Tagliato

Android

  • Miglioramenti alla precisione delle seguenti regole: Testo Focalizzabile, Nome Testo Modificabile, Azione Inaccessibile e Elemento Focalizzabile Nidificato

Deprecazioni e Rimozioni

iOS

La proprietà optInToSupportsDynamicType è deprecata. La regola Supporta Tipo Dinamico ora viene eseguita di default. Se in precedenza avevi attivato questa regola, rimuovi la proprietà dal tuo codice.

Android

Le regole Controllo Attivo Nidificato e Nome Elemento Nidificato sono state disabilitate e non vedrai più questi problemi segnalati nei tuoi risultati. Entrambe le regole saranno rimosse - almeno temporaneamente - in un secondo momento.

Problemi Noti

Se stai riscontrando uno dei problemi sotto elencati, contattaci a helpdesk@deque.com o support.deque.com. Potremo così informarti una volta risolto o di una soluzione alternativa individuata se non è elencata.

important
  • I test automatizzati di Axe DevTools Mobile vengono eseguiti su applicazioni native iOS, Android native e React Native. Contatta il tuo rappresentante Deque per soluzioni di test di accessibilità per il tuo stack tecnologico.
  • Anche se potresti ottenere alcuni risultati da visualizzazioni web o PDF renderizzati, consigliamo vivamente di effettuare test utilizzando Axe DevTools per il Web o Axe Monitor per il più completo testing di accessibilità per il web.

iOS

Risultati incompleti per la regola Supporta Tipo Dinamico su schermi con segni percentuali nel testo

Su iOS 26 e versioni successive, se uno schermo contiene testo con un segno percentuale (ad es. un'etichetta di testo che riporta "50% di Sconto"), la regola Supporta Tipo Dinamico 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 percentuali. Per mantenere in esecuzione i tuoi test, la nostra regola ignora il controllo per quello schermo e riporta incompleto per ciascun elemento contenente un segno percentuale. Tutte le altre regole vengono eseguite normalmente sullo schermo, e altri schermi non sono interessati.

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 andando su **Impostazioni** > **Accessibilità** > **Display e Dimensione Testo** > **Testo Grande**, e conferma che il testo sullo schermo si ridimensiona correttamente. Questo problema è stato segnalato ad Apple. (#2985)

Il Contrasto del Colore potrebbe essere eseguito su elementi solo icone a causa dell'OCR

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 contorni di un elemento. L'OCR può occasionalmente identificare erroneamente piccoli glifi simili a icone - come le frecce indietro (<), i punti elenco, i simboli decorativi - come testo. Quando ciò accade, la regola del Contrasto di Colore viene eseguita 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 di Contrasto di Colore in una scansione e essere segnalato come "NON APPLICABILE" nella successiva. Questa è una caratteristica nota dell'OCR, non un bug nella regola.

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



// Ignore Color Contrast for a specific element by accessibility identifier
axeDevTools?.configuration.ignore(rulesFor: [
    "backButton": [AxeRuleId.ColorContrast.toString()]
])

// Or ignore Color Contrast globally
axeDevTools?.configuration.ignore(rule: AxeRuleId.ColorContrast.toString())

Scopri di più su come ignorare le regole.

Falso positivo del titolo della schermata nelle app Flutter

Flutter non mappa AppBar.title alla proprietà del titolo della schermata nativa - UIViewController.title, causando il fallimento della regola del Titolo della Schermata su tutte le schermate Flutter a prescindere dalla presenza di un titolo descrittivo.

Questa è una limitazione conosciuta della piattaforma Flutter tracciata in flutter/flutter#185894.

Falsi positivi per la regola del Contrasto di Colore con sfondi a gradiente su schermi piccoli

Quando si eseguono controlli di accessibilità su schermi di dimensioni minori o con dimensioni dei caratteri 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 confrontare invece i colori di sfondo tra loro, risultando in un'insufficienza.

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

Inaccurata isVisible proprietà da XCTest

Le API di accessibilità di Apple potrebbero segnalare erroneamente il contenuto web all'interno di WKWebView come "isVisible", anche quando il web view è coperto da sovrapposizioni native (come visualizzazioni modali, avvisi o altri elementi dell'interfaccia utente nativa). Questo accade perché il sistema di accessibilità controlla se il contenitore WKWebView stesso è visibile, piuttosto che se il suo contenuto web è effettivamente libero da ostacoli e percepibile per l'utente.

Bug di accessibilità di iOS 26 con gli stepper

iOS 26 contiene un bug di accessibilità per cui i pulsanti predefiniti dello stepper non annunciano "dimmed" alla 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 presentato un rapporto di bug ad Apple, ma fino a quando questo non sarà risolto, le seguenti regole potrebbero riportare risultati su pulsanti dello 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 predefiniti dello stepper hanno gli identificatori "Decrement" e "Increment", e possono essere ignorati tramite l'identificatore se necessario.

Color Contrast rule does not run when text and background colors are the same

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.

Falso positivo: LabelInName e LabelAtFront in SwiftUI & App multipiattaforma

Alcune schermate potrebbero riportare falsi positivi con LabelInName e LabelAtFront a causa di una proprietà associatedText errata (#1622)

Regole contro i controlli annidati

Durante l'esame di un miglioramento per le nostre regole, abbiamo scoperto che in XCTest i controlli annidati non vengono restituiti nell'albero di accessibilità. È stato presentato un rapporto di bug ad Apple. (#1110)

La Regola del Nome dell'ImageView ha bisogno di rivedere i risultati per le app UIKit

Nelle app UIKit, un'immagine senza un `accessibilityLabel` non è focalizzabile con la tecnologia assistiva per impostazione predefinita.
Le proprietà che usiamo per controllare la focalizzabilità da parte di Apple potrebbero risultare inaccurate quando viene impostato un `accessibilityIdentifier` sull'immagine. A causa di questo comportamento inaspettato, i risultati per i problemi di Nome dell'ImageView nelle app UIKit verranno segnalati come Da Rivedere. È stato presentato un rapporto di bug ad Apple. (#1633)

Falso positivo: In Scroll View, Label In Name, Label at Front e v2.11.0 Nome dell'Immagine & NomeControlloAttivo

Stiamo lavorando attivamente su 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 di tipo banner, intestazioni/piedipagina fissi, pulsanti di azione fluttuanti e visualizzazioni personalizzate delle schede può essere contrassegnato con un messaggio "Da Rivedere" o "Insufficiente". Per rendere disponibili questi elementi a coloro che necessitano di 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, il Nome Controllo Attivo potrebbe segnalare un falso positivo sull'UIImageView. Rimuovere il accessibilityIdentifier risolve il problema. È stato presentato un rapporto di 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 aiutare a determinare lo stato della regola. In alcune gerarchie di visualizzazione, il testo vicino erroneo potrebbe essere rilevato causando il fallimento di queste regole. (#1622)

Android

Label at Front falsi positivi con testo visibile oscurato

La regola Label at Front verifica che l'etichetta visibile di un elemento venga all'inizio del testo annunciato. Potrebbe verificarsi un fallimento della regola quando il testo visibile di un elemento interattivo contiene un'abbreviazione (es. "GB", "km") o un identificatore oscurato/troncato, e l'annuncio di accessibilità consiste nelle parole rappresentate (es. "gigabyte", "chilometri"), anche se questo è il modello raccomandato per rendere 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/occulta differisce, il risultato contrassegnato può essere ignorato in sicurezza. Verifica con un lettore di schermo che l'annuncio completo legga come previsto.

Potenziali problemi di accessibilità per il Testo Focalizzabile

Quando si utilizza testo decorativo in visualizzazioni come "Icone di Contatto", è possibile introdurre un problema di accessibilità. Se si utilizza una visualizzazione di testo per visualizzare lettere anziché generare immagini con le lettere desiderate come vettori, e poi si dichiara che tale visualizzazione di testo non è importante per l'accessibilità, non saremo in grado di determinare in modo affidabile se è stato introdotto un problema di accessibilità.

Se si modifica il testo focalizzabile per ignorare due o meno caratteri, si potrebbe involontariamente ignorare molti pulsanti a parola singola in varie lingue (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, anziché come visualizzazioni di testo separate. `FocusableText` non verrà eseguito su quelle visualizzazioni.

Falso positivo del titolo dello schermo nelle app Flutter

Flutter non associa AppBar.title alla proprietà del titolo dello schermo nativo - 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.

Falso positivo del rilevamento del testo annunciato

In alcuni casi, la tecnologia assistiva si basa su AccessibilityEvent descrizioni dal sistema Android per annunciare informazioni all'utente quando non è disponibile un altro annuncio. Poiché AccessibilityEventvengono attivate da azioni dell'utente, non possiamo accedere alla descrizione corretta se queste informazioni non sono fornite.

Per evitare questo problema, assicurati 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 regola del contrasto di colore non viene eseguita quando i colori del testo e dello sfondo sono gli stessi

La nostra regola del contrasto di colore si basa sul Machine Learning per rilevare il testo, garantendo che il testo scansionato 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 la presenza di testo, quindi la regola del contrasto di colore non viene eseguita su questa vista.

EditTextName su Android 7 (SDK 24-25)

Le app scritte con XML che utilizzano la funzione di testo suggerito possono vedere falsi positivi con la EditTextName regola. Il testo suggerito non è stato introdotto fino ad Android 8 (SDK 26). Utilizzare questo elemento nella tua app XML assegnerà il testo suggerito al valore del campo di input di testo. Versioni più recenti di Android sono meglio attrezzate per rendere questa esperienza accessibile.

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

Viste nascoste di Android che restituiscono risultati

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 riporta ancora come problemi.

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

Errore durante l'esecuzione del rilevamento del testo ML Kit

Il rilevamento del testo 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 automatici Espresso o UIAutomator. In alcuni casi, tuttavia, l'importazione automatica non avviene e vedrai il seguente errore nel logcat:


Axe DevTools Android: Error while running mlKit Text Detection: MlKitContext has not been initialized.

Per superare questo problema, dovresti importare manualmente la libreria ML Kit nel tuo progetto. Nel file della tua applicazione build.gradle , aggiungi il seguente sotto le dipendenze:

debugImplementation 'com.google.mlkit:text-recognition:16.0.1'

Trova un esempio completo di funzionamento della libreria ML Kit importata nella sezione Iniziare con Android Mobile SDK, sotto Implementazione

Spaziatura dell'obiettivo tattile e Jetpack Compose

La regola della spaziatura dell'obiettivo tattile attualmente non viene eseguita su nessun componente slider scritto in Jetpack Compose. Al momento non è possibile intraprendere alcuna azione. Tuttavia, una soluzione è in arrivo presto!

Errore durante il salvataggio dei risultati localmente su API 30

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

def clearDirectoryTask = task('clearDirectoryTask', type: Exec, group: 'reporting') {
	executable "${android.getAdbExecutable().toString()}"
	args 'shell', 'rm', '-r', '/storage/emulated/0/Documents/AxeTestCases'

//    finalizedBy {
//        fetchAndroidFolderAxeReportsTask
//    }
}

Si noti che questo codice dovrebbe essere commentato solo per API 30 poiché causerà problemi durante il salvataggio locale per altri livelli API.

Rilevamento dello scorrimento su app ibride e app multipiattaforma

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

App di Analisi: Il pulsante di azione fluttuante scompare

Introdotta con API 31 (Android 12) è la capacità di nascondere sovrapposizioni diverse dal 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 consigliamo di lasciarla disattivata per le build di test interne, dove puoi utilizzare in sicurezza i dati di test ed eliminare così le preoccupazioni 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 tutte le chiamate al metodo setHideOverlayWindows(true) a setHideOverlayWindows(false) sulle finestre delle attività interessate.

Screenshot mancante (Blocco Nero) nel dashboard

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 simulati per evitare preoccupazioni di sicurezza. Consulta la nostra guida per abilitare gli screenshot nelle app Android.

Arresto anomalo quando minifiedEnabled è impostato su true

Se si riduce al minimo la tua 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 il ridimensionamento per i tuoi build di debug con Axe DevTools implementato. (#729)

Le build con r8 abilitato generano un errore

Una build con r8 abilitato può tentare di ridimensionare la libreria axeDevTools provocando un errore simile a:


Caused by: java.lang.NullPointerException: throw with null exception at g.b.b.a$a.a(Unknown Source:1) at g.b.b.a$a.a(Unknown Source:0) at g.b.b.a.a(AccessToken.java:190)

Per risolvere questo errore aggiungi la seguente riga al tuo file ProGuard per mantenere le classi axeDevTools:

keep class com.deque.** { *; }
Messaggi di errore quando si utilizzano le API Compose

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

MAUI: Regola Nome Testo Modifica

A causa delle limitazioni dell'architettura dell'app MAUI nel rendering nell'ecosistema Android, la regola Nome Testo Modifica verrà visualizzata come Da Rivedere nel pannello di controllo 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.

Android Nativo: Dialoghi/Modali Personalizzati

Quando stai implementando dialoghi o modali personalizzati che non estendono i 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 di controllarli manualmente per garantire che si comportino con la tecnologia assistiva come desiderato.

Pannello Web

Screenshot Mancante

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 di produzione. Considera la possibilità di rimuovere questo requisito per la tua versione di test per consentire la piena funzionalità nel Pannello Mobile di Axe DevTools.

Alcuni nomi di scansioni Android non sono formattati

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 un prossimo aggiornamento, questo sarà risolto in modo che il titolo dello schermo venga formattato in un nome più leggibile. Come soluzione temporanea, puoi impostare il nome della scansione dal pannello o dai framework. (#1643)