Note di rilascio di Axe DevTools Mobile 8 settembre 2026

Questo stato è obsoleto e verrà rimosso nell'ottobre 2026. A quel punto, le regole ignorate verranno saltate nell'iterazione e non restituiranno più un risultato.

Nota che AxeDevTools itself non è deprecato. I seguenti metodi saranno sostituiti o rimossi completamente nell'uscita di ottobre 2026.

• ignoreByViewIdResourceName(viewIdResourceName: String, ruleList: List) (Sarà sostituito con ignoreRulesOnElementWithId(id: String, vararg rules: AxeRuleName))
• ignoreRules(rulesToIgnore: List)
• resetIgnoredRules()
• tagScansAs(tag: TagSet)
• deleteResult(axeDevToolsResultKey: AxeDevToolsResultKey)
• getResult(axeDevToolsResultKey: AxeDevToolsResultKey)

• getResult()
• postResult()
• deleteResult()
• tag()
• setScanName()
• getUserInfo()
• getResultSync()
• postResultSync()
• deleteResultSync()
• tagSync()
• setScanNameSync()
• getSessionId()
• BASE_FRONTEND_URL
• DB_DEFAULT_URL
• DB_QA_URL
• DB_DEV_URL

Il concetto di regole sperimentali verrà rimosso completamente nell'uscita di ottobre. Lo stesso vale per i tag - andranno via con il pensionamento del Mobile Dashboard.

Queste regole erano sperimentali e non vengono promosse. Sono state rimosse dalla nostra iterazione delle regole.

• AxeDevToolsResultKey
• AxeDevToolsResultSummaryResponse
• ConnectionConfig - Questo sarà sostituito da dbUrl costruttore con argomento singolo
• class TagsSet()
• Le regole sperimentali vengono promosse o rimosse

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 di Colore, Visualizzazioni Sovrapposte, 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 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 può essere assente nella successiva.

Quando una regola basata su Vision riporta un fallimento, il fallimento stesso è accurato. L'incoerenza è se la regola viene eseguita o meno. Per superare questo problema, prova quanto segue:

• Rieseguire la scansione. Se una regola basata su Vision è stata saltata per un controllo, un'altra scansione dello stesso schermo spesso la rileva.
• Trattare qualsiasi fallimento delle regole basate su Vision come valido - se Contrasto di Colore segnala un controllo, il problema di contrasto è reale e dovrebbe essere affrontato.
• Per la verifica manuale, utilizzare il riferimento di Deque University per il criterio di successo WCAG pertinenti. (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 "Sconto 50%"), la regola Supporto per Tipo Dinamico potrebbe essere segnalata come Incompleta invece che come superata o fallita. Questa regola si basa su un audit di accessibilità fornito da Apple, e quell'audit interrompe l'esecuzione dei test quando incontra segni percentuali. Per mantenere i test in esecuzione, la nostra regola salta il controllo per quello schermo e riporta incompleto per ogni elemento contenente un segno di percentuale. Tutte le altre regole funzionano normalmente sullo schermo, e le altre schermate non sono influenzate.

Non è richiesta alcuna azione, poiché la scansione verrà comunque completata. Per verificare il supporto per Tipo Dinamico su queste schermate, aumentare la dimensione del testo sul dispositivo sotto **Impostazioni** > **Accessibilità** > **Display e Dimensione Testo** > **Testo Grande**, e confermare che il testo sullo schermo 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 piccole icone simili a glifi - come i chevron di freccia indietro (<), elenchi puntati, simboli decorativi - come testo. Quando ciò accade, la regola del Contrasto di Colore si esegue 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 di Colore in una scansione e essere segnalato come "INAPPLICABILE" nella successiva. Questa è una caratteristica nota dell'OCR, non un bug nella regola.

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

Flutter non mappa AppBar.title alla proprietà del titolo schermo nativa - UIViewController.title, causando il fallimento della regola Titolo Schermo su tutti gli schermi Flutter indipendentemente dal fatto che sia presente 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 ridotte o con dimensioni di carattere minori, la regola del Contrasto del Colore potrebbe riportare falsi positivi per gli sfondi a gradiente. In tali casi, potrebbe non essere in grado di determinare il colore in primo piano e invece confrontare i colori di sfondo tra loro, risultando in un errore.

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

Le API di accessibilità di Apple potrebbero riportare erroneamente contenuti web all'interno di WKWebView come „isVisible“, anche quando la vista web è coperta da sovrapposizioni native (come viste modali, avvisi o altri elementi dell'interfaccia utente nativa). Ciò accade perché il sistema di accessibilità verifica se il contenitore di 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 dei selettori predefiniti non annunciano "oscurato" 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 segnalato un bug ad Apple, ma fino a quando non sarà risolto, le seguenti regole potrebbero riportare risultati su pulsanti di selezione disabilitati: AssociatedText, InaccessibleAction, e ColorContrast.

Fino a quando Apple non risolverà questo bug, la soluzione sarà [ignorare le regole](ios-ignore-rule). I pulsanti di selezione predefiniti hanno gli identificatori „Decrement“ e „Increment“ e possono essere ignorati tramite 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.

Alcune schermate potrebbero 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 di accessibilità. È stato segnalato un bug 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 verificare la focalizzabilità da Apple potrebbero essere imprecise quando un `accessibilityIdentifier` è impostato sull'immagine. A causa di questo comportamento inatteso, i risultati relativi ai problemi del Nome di ImageView nelle app UIKit verranno segnalati come Da Rivedere. È stato segnalato un bug ad Apple. (#1633)

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

In Scroll View
Il testo all'interno di elementi che si comportano come banner, intestazioni/piè di pagina appiccicosi, pulsanti di azione flottanti e visualizzazioni a schede personalizzate potrebbero essere contrassegnati con un messaggio "Da Rivedere" o "Fallito". Per rendere disponibili questi elementi a chi ha bisogno di caratteri più grandi, usa 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 potrebbe segnalare un falso positivo su UIImageView. Rimuovere il 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 visualizzazione, il testo vicino errato potrebbe essere rilevato causando il fallimento di queste regole. (#1622)

La regola Label at Front verifica che l'etichetta visibile di un elemento venga all'inizio del testo annunciato. Un errore di regola può verificarsi quando il testo visibile di un elemento interattivo contiene un'abbreviazione (es. „GB“, „km“) o un identificatore oscurato/troncato, e l'annuncio di accessibilità è costituito dalle parole rappresentate (es. "gigabyte", "chilometri"), anche se questo è il modello consigliato per rendere il contenuto abbreviato o troncato accessibile 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 è diversa, il risultato contrassegnato può essere tranquillamente ignorato. Verifica con un lettore di schermo che l'annuncio completo venga letto come previsto.

Quando si utilizzano testi decorativi in visualizzazioni come "Icone di Contatto", è possibile introdurre un problema di accessibilità. Se si utilizza una vista testo per visualizzare lettere invece di generare immagini con le lettere desiderate come vettori, e poi dichiari che quella vista testo non è importante per l'accessibilità, non saremo in grado di determinare in modo affidabile se hai introdotto una violazione dell'accessibilità.

Se modifichi il testo focalizzabile per ignorare due o meno caratteri, potresti involontariamente ignorare molti pulsanti di una parola in varie lingue (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 invece di singole visualizzazioni di testo. `FocusableText` non verrà quindi eseguito su queste visualizzazioni.

Flutter non mappa AppBar.title alla proprietà del titolo schermo nativa - Activity.setTitle, causando il fallimento della regola Titolo Schermo su tutti gli schermi Flutter indipendentemente dal fatto che sia presente un titolo descrittivo.

Questa è una limitazione nota della piattaforma Flutter monitorata 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 ci sono altri annunci disponibili. Poiché AccessibilityEventvengono 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 visualizzazioni rilevanti 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 del Contrasto del Colore si basa sul Machine Learning per rilevare il testo, il che garantisce che il testo analizzato 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 Machine Learning 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 suggerito potrebbero 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. Le versioni più recenti di Android sono meglio attrezzate per rendere questa esperienza accessibile.

Per superare questo problema, la nostra prima raccomandazione è eseguire i tuoi test su versioni più recenti di Android. Tuttavia, se è importante che l'app sia accessibile su versioni precedenti di Android, potresti considerare di non utilizzare il hintText funzione, poiché non è ufficialmente supportata.

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

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

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

La regola della Spaziatura del Target di Tocco attualmente non viene eseguita su componenti slider scritti in Jetpack Compose. Al momento, non è possibile intervenire. Tuttavia, una soluzione è in arrivo!

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

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

Introdotta con API 31 (Android 12) è la possibilità di nascondere le 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ì le preoccupazioni sulla 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.

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

Se riduci la tua build, vedrai un crash con un log di errore che riporta che un adattatore non è stato trovato quando tenti di accedere alla libreria Axe DevTools. Disabilita il minify per le tue build di debug con Axe DevTools implementato. (#729)

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

Le API Compose sono deprecate, per favore utilizza le API agnostiche al layout per continuare a ricevere aggiornamenti. Se continui a utilizzare le API 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()?`, fai riferimento a Compose setTestTag API.

A causa delle limitazioni dell'architettura dell'app MAUI nel rendering nell'ecosistema Android, la regola Nome Testo Editabile verrà visualizzata come Da rivedere nella dashboard quando viene sospettato un fallimento per la versione SDK 5.5.0 e successive. Si prega di confermare il comportamento corretto manualmente in questo caso.

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

Se lo screenshot è assente dalla pagina dei dettagli della scansione, la tua app potrebbe impedire che gli screenshot vengano effettuati. Spesso questo accade per motivi di sicurezza nella tua applicazione di produzione. Considera di rimuovere questo requisito per la tua build di test per consentire la piena funzionalità nella Dashboard Mobile di Axe DevTools.

• Android - FLAG_SECURE

Alcuni nomi di scansioni Android che sono predefiniti come titolo dello schermo appariranno come il nome completo della classe incluso l'identificatore del pacchetto. In un prossimo aggiornamento, 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 dalla dashboard o dai framework. (#1643)