Axe DevTools Mobile Versionshinweise vom 8. April 2026

Beim Ausführen von Barrierefreiheitsprüfungen auf kleineren Bildschirmen oder mit kleineren Schriftgrößen kann es vorkommen, dass die FarbkontrastregeI falsch positive Ergebnisse für Farbverläufe meldet. In solchen Fällen ist es möglicherweise nicht möglich, die Vordergrundfarbe zu bestimmen und stattdessen Hintergrundfarben miteinander zu vergleichen, was zu einem Fehler führt.

Um dieses Problem zu beheben, versuchen Sie, Barrierefreiheitsprüfungen auf größeren Geräten durchzuführen. Alternativ können Sie die Regel in Ihren Tests ignorieren und den Farbkontrast manuell für diese Ansichten überprüfen.

Apples Barrierefreiheits-APIs können Webinhalte innerhalb von WKWebView fälschlicherweise als „isVisible“ melden, auch wenn die Webansicht von nativen Überlagerungen (wie modalen Ansichten, Warnungen oder anderen nativen UI-Elementen) verdeckt wird. Dies geschieht, weil das Barrierefreiheitsystem prüft, ob der WKWebView-Container selbst sichtbar ist, anstatt ob seine Webinhalte tatsächlich unbehindert und für den Benutzer wahrnehmbar sind.

iOS 26 enthält einen Barrierefreiheitsfehler, bei dem Standard-Stepperschaltflächen nicht als „deaktiviert“ durch unterstützende Technologien angezeigt werden, um anzuzeigen, dass sie nicht aktiviert sind. Infolgedessen sehen auch die iOS-Regeln diese Schaltflächen als aktiviert an, obwohl sie es nicht sind. Ein Fehlerbericht wurde bei Apple eingereicht, aber bis dies behoben ist, können die folgenden Regeln Ergebnisse auf deaktivierten Stepper-Schaltflächen melden: AssociatedText, InaccessibleAction, und ColorContrast.

Bis Apple diesen Fehler behebt, besteht die Lösung darin, die [Regeln zu ignorieren](ios-ignore-rule). Die Standard-Stepperschaltflächen haben die Bezeichner „Decrement“ und „Increment“ und können bei Bedarf nach Bezeichner ignoriert werden.

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.

Einige Bildschirme können falsch-positive Meldungen mit LabelInName und LabelAtFront aufgrund einer fälschlicherweise gefundenen associatedText-Eigenschaft anzeigen (#1622)

Es gibt ein Problem, das den iPhone 15 Pro-Simulator betrifft und verhindert, dass die Supports Dynamic Type-Regel ausgeführt wird. Wenn Sie diese Regel aktiviert haben, können Sie sie nicht mit einem iPhone 15 Pro-Simulator testen. Ein Fehler wurde bei Apple gemeldet.

Während wir nach einer Verbesserung für unsere Regeln suchten, stellten wir fest, dass in XCTest verschachtelte Steuerelemente nicht im Barrierefreiheit-Baum angezeigt werden. Ein Fehler wurde bei Apple gemeldet. (#1110)

In UIKit-Apps ist ein Bild ohne `accessibilityLabel` standardmäßig nicht mit unterstützender Technologie fokussierbar.
Die Eigenschaften, die wir verwenden, um die Fokussierbarkeit bei Apple zu überprüfen, können ungenau sein, wenn ein `accessibilityIdentifier` auf das Bild gesetzt ist. Aufgrund dieses unerwarteten Verhaltens werden die Ergebnisse für ImageView-Name-Probleme in UIKit-Apps als "Überprüfung erforderlich" gemeldet. Ein Fehlerbericht wurde bei Apple eingereicht. (#1633)

Wir arbeiten aktiv an Lösungen für die folgenden falsch-positiven Ergebnisse und werden diese Liste aktualisieren, sobald Korrekturen veröffentlicht werden.

In Scroll View
Text innerhalb von bannerähnlichen Elementen kann mit einer "Überprüfung erforderlich"-Nachricht markiert werden. Um diese Elemente für diejenigen verfügbar zu machen, die größere Textgrößen benötigen, verwenden Sie UILargeContentViewer. (#622)

v2.11.0 Image View Name & Active Control Name
Wenn ein UIImageView ein `accessibilityIdentifier` hat, aber nicht von VoiceOver fokussierbar ist, und es fokussierbare Steuerelemente innerhalb hat, kann ActiveControlName ein falsch-positives Ergebnis auf dem UIImageView melden. Das Entfernen des `accessibilityIdentifier` behebt das Problem. Ein Fehler wurde bei Apple gemeldet. (#1633)

Label In Name and Label At Front
Diese beiden Regeln suchen nach dem sichtbaren Etikett eines Steuerelements unter nahegelegenen Elementen, um den Regelstatus zu bestimmen. In einigen Ansichtenhierarchien kann der falsche nahegelegene Text erkannt werden, was dazu führt, dass diese Regeln fehlschlagen. (#1622)

In einigen Fällen verlassen sich unterstützende Technologien auf AccessibilityEvent Beschreibungen des Android-Systems, um dem Benutzer Informationen anzukündigen, wenn keine andere Ankündigung verfügbar ist. Da AccessibilityEvents are triggered by user actions, we are unable to access the correct description if this information is not provided.

Um dieses Problem zu vermeiden, stellen Sie sicher, dass alle relevanten Ansichten als wichtig für die Barrierefreiheit markiert sind. Dies ermöglicht Talkback den Zugriff auf die Informationen aus der Ansicht, die unser Tool dann erkennen kann.

Unsere Farbkontrastregel hängt von Machine Learning zur Texterkennung ab, was sicherstellt, dass der gescannte Text für die Benutzer Ihrer Anwendung sichtbar ist. In Fällen, in denen der Text in einer Ansicht dieselbe Farbe wie der Hintergrund hat, kann unser Machine Learning-Algorithmus nicht feststellen, ob Text vorhanden ist, sodass die Farbkontrastregel in dieser Ansicht nicht ausgeführt wird.

Apps, die mit XML geschrieben wurden und die Hinweistextfunktion verwenden, können falsch-positive Ergebnisse mit der EditTextName Regel sehen. Hinweistext wurde erst ab Android 8 (SDK 26) eingeführt. Die Verwendung dieses Elements in Ihrer XML-App weist den Hinweistext dem Wert des Texteingabefelds zu. Neuere Android-Versionen sind besser in der Lage, dieses Erlebnis barrierefrei zu gestalten.

Um dieses Problem zu umgehen, ist unsere erste Empfehlung, Ihre Tests auf neueren Android-Versionen durchzuführen. Wenn es jedoch wichtig ist, dass die App auf älteren Android-Versionen zugänglich ist, sollten Sie in Betracht ziehen, die Verwendung des hintText Features zu vermeiden, da es nicht offiziell unterstützt wird.

Sie sehen möglicherweise Ergebnisse für Ansichten, die von anderen Ansichten auf dem Bildschirm verdeckt sind. Diese versteckten Ansichten sind nicht für unterstützende Technologien verfügbar, aber Axe DevTools Mobile meldet sie dennoch als Probleme.

Wir arbeiten an einer Lösung für dieses komplexe Problem. In der Zwischenzeit können Sie, wenn TalkBack diese Ansichten nicht erreichen kann, die entsprechenden Probleme ignorieren. Sie erfordern keine Korrektur, um die Barrierefreiheit zu gewährleisten.

Die ML Kit Texterkennung wird in vielen der Axe DevTools Mobile-Regeln benötigt, um die Genauigkeit der Ergebnisse sicherzustellen. Die ML Kit-Bibliothek sollte automatisch importiert werden, wenn auf Axe DevTools Mobile in Ihren automatisierten Espresso- oder UIAutomator-Tests verwiesen wird. In einigen Fällen erfolgt der automatische Import jedoch nicht, und Sie sehen den folgenden Fehler im Logcat:

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

Um dieses Problem zu beheben, sollten Sie die ML Kit-Bibliothek manuell in Ihr Projekt importieren. In der build.gradle -Datei Ihrer Anwendung fügen Sie Folgendes unter Abhängigkeiten hinzu:

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

Die Touch-Target-Abstandsregel wird derzeit nicht für Schieberegler-Komponenten ausgeführt, die in Jetpack Compose geschrieben wurden. Derzeit kann keine Maßnahme ergriffen werden. Eine Lösung ist jedoch bald verfügbar!

Unter Android API 30 hat einer der Orte, an denen wir versuchen, Ergebnisse lokal zu speichern, einen Berechtigungsfehler. Das Ergebnis wird trotzdem als JSON-Datei gespeichert, obwohl dieser Fehler angezeigt wird. Der Fehler kann unterdrückt werden, indem der folgende Codeblock auskommentiert wird:

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

In einigen Hybrid- und plattformübergreifenden Apps können wir unerwartete Ergebnisse zurückgeben, wenn Elemente in einer Bildlaufansicht teilweise außerhalb des Bildschirms sind. Um ein Element auf Barrierefreiheit zu testen, stellen Sie sicher, dass es vollständig auf dem Bildschirm ist, bevor Sie den Scan durchführen.

Mit API 31 (Android 12) wurde die Möglichkeit eingeführt, nicht-systemeigene Overlays zu verbergen. Um die Axe Analyzer-App nutzen zu können, stellen Sie bitte sicher, dass diese Einstellung nicht aktiviert ist. Wenn Sie sich entschieden haben, dieses Feature wegen seiner Sicherheitsverbesserungen zu nutzen, empfehlen wir, es für interne Test-Builds deaktiviert zu lassen, bei denen Sie Testdaten sicher nutzen und so Sicherheitsbedenken ausschließen können. Note: this setting does not affect Google's accessibility scanner app as it's considered a system overlay.

Um die Axe Accessibility Analyzer-App zu nutzen, aktualisieren Sie alle Aufrufe der Methode setHideOverlayWindows(true) zu setHideOverlayWindows(false) auf den betroffenen Aktivitätsfenstern.

Um den vollen Funktionsumfang von Axe DevTools für Mobile freizuschalten, stellen Sie sicher, dass Screenshots aktiviert sind. Wir empfehlen, Screenshots in einer Debug- oder Testversion Ihrer App zu aktivieren, die mit Mock-Daten arbeitet, um Sicherheitsbedenken zu vermeiden. Siehe unseren Leitfaden für das Aktivieren von Screenshots in Android-Apps.

Wenn Sie Ihr Build minifizieren, werden Sie auf einen Absturz stoßen mit einem Fehlerprotokoll, das berichtet, dass ein Adapter beim Versuch, sich bei der Axe DevTools-Bibliothek anzumelden, nicht gefunden werden konnte. Deaktivieren Sie die Minifizierung für Ihre Debug-Builds mit implementiertem Axe DevTools. (#729)

Ein Build mit aktiviertem r8 könnte versuchen, die axeDevTools-Bibliothek zu minifizieren, was zu einem Fehler führt, der ähnlich ist wie:

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)
	

Die Compose-APIs sind veraltet, bitte verwenden Sie die layout-agnostischen APIs , um weiterhin Updates zu erhalten. Wenn Sie die Compose-APIs weiter verwenden und auf einen Fehler stoßen, der in etwa lautet: `Es wurde genau '1' Knoten erwartet, aber '2' Knoten gefunden, die folgende Bedingung erfüllen: (isRoot)` oder `Kein View initialisiert, haben Sie AxeDevToolsCompose.setComposeTestRule() aufgerufen?`, konsultieren Sie bitte Compose setTestTag API.

Aufgrund von Einschränkungen der MAUI-App-Architektur im Android-Ökosystem wird die Regel zum Bearbeiten von Textnamen im Dashboard als "Bedarf an Überprüfung" angezeigt, wenn ein Fehler für SDK-Version 5.5.0 und höher vermutet wird. Bitte bestätigen Sie in diesem Fall das korrekte Verhalten manuell.

Wenn Sie benutzerdefinierte Dialoge oder Modale implementieren, die die nativen Steuerelemente nicht erweitern, könnten Sie Ergebnisse für Ansichten hinter dem Modal erhalten. In diesem Fall empfehlen wir, unser Tool nicht gegen diese benutzerdefinierten Modale oder Dialoge laufen zu lassen und stattdessen diese manuell zu überprüfen, um sicherzustellen, dass sie mit unterstützenden Technologien wie gewünscht funktionieren.

Wenn der Screenshot auf der Scan-Detailseite fehlt, verhindert Ihre App möglicherweise, dass Screenshots erstellt werden. Häufig geschieht dies aus Sicherheitsgründen in Ihrer Produktionsanwendung. Erwägen Sie, diese Anforderung für Ihren Test-Build zu entfernen, um die volle Funktionalität im Axe DevTools Mobile Dashboard zu ermöglichen.

• Android - FLAG_SECURE

Einige Android-Scan-Namen, die standardmäßig auf den Bildschirmtitel gesetzt sind, werden als vollständiger Klassenname einschließlich des Bündel-Identifiers angezeigt. In einer zukünftigen Version wird dies behoben, sodass der Bildschirmtitel in einen lesbareren Namen formatiert wird. Als Problemumgehung können Sie den Scan-Namen vom Dashboard oder den Frameworks aus festlegen. (#1643)