Axe DevTools Mobile Versionshinweise vom 18. Mai 2026

Wenn Sie Barrierefreiheitsprüfungen auf kleineren Bildschirmgrößen oder mit kleineren Schriftgrößen durchführen, kann die Farbkontrastregel falsch positive Ergebnisse für Verlaufs-Hintergründe melden. In solchen Fällen kann es die Vordergrundfarbe möglicherweise nicht bestimmen und vergleicht stattdessen die Hintergrundfarben miteinander, was zu einem Fehler führt.

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

Die Barrierefreiheits-APIs von Apple können Webinhalte innerhalb von WKWebView fälschlicherweise als „isVisible“ melden, selbst wenn der Webview von nativen Overlays (wie Modals, Warnungen oder anderen nativen UI-Elementen) verdeckt ist. Dies tritt auf, weil das Barrierefreiheits-System prüft, ob der WKWebView-Container selbst sichtbar ist, und nicht, ob sein Webinhalt tatsächlich ungehindert und wahrnehmbar für den Benutzer ist.

iOS 26 enthält einen Barrierefreiheitsfehler, bei dem die standardmäßigen Schrittkontrollknöpfe nicht "gedimmt" von unterstützender Technologie angekündigt werden, um anzuzeigen, dass sie nicht aktiviert sind. Dadurch sehen die iOS-Regeln diese Knöpfe als aktiviert an, auch wenn sie es nicht sind. Ein Fehlerbericht wurde an Apple gesendet, aber bis dieses Problem gelöst ist, können die folgenden Regeln Ergebnisse bei deaktivierten Schrittkontrollknöpfen melden: AssociatedText, InaccessibleAction, und ColorContrast.

Bis Apple diesen Fehler behebt, besteht die Lösung darin, [die Regeln zu ignorieren](ios-ignore-rule). Die Standard-Schrittkontrollknöpfe haben die Bezeichnungen "Decrement" und "Increment" und können bei Bedarf nach Bezeichnung 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 Ergebnisse mit LabelInName und LabelAtFront melden, aufgrund einer fälschlich gefundenen associatedText-Eigenschaft (#1622)

Es gibt ein Problem, das den iPhone 15 Pro Simulator betrifft und verhindert, dass die Supports Dynamic Type Regel läuft. Wenn Sie sich für die Supports Dynamic Type Regel angemeldet haben, können Sie sie mit einem iPhone 15 Pro Simulator nicht testen. Ein Fehler wurde an Apple gemeldet.

Bei der Betrachtung einer Verbesserung für unsere Regeln haben wir festgestellt, dass in XCTest verschachtelte Steuerungen im Barrierefreiheitsbaum nicht zurückgegeben werden. Ein Fehler wurde an 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 von Apple zu überprüfen, können ungenau sein, wenn auf dem Bild ein `accessibilityIdentifier` gesetzt ist. Aufgrund dieses unerwarteten Verhaltens werden die Ergebnisse für ImageView-Name-Probleme in UIKit-Apps als "Muss überprüft werden" gemeldet. Ein Fehlerbericht wurde an Apple gesendet. (#1633)

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

In Scroll View
Text innerhalb von zeichenhaft wirkenden Elementen kann mit einer "Muss überprüft werden"-Nachricht markiert werden. Um diese Elemente für diejenigen verfügbar zu machen, die größere Texte benötigen, verwenden Sie UILargeContentViewer. (#622)

v2.11.0 Image View Name & Active Control Name
Wenn ein UIImageView einen `accessibilityIdentifier` hat, aber nicht von VoiceOver fokussiert werden kann, und es darin verschachtelte fokussierbare Steuerungen gibt, kann ActiveControlName ein falsch-positives Ergebnis auf dem UIImageView melden. Das Entfernen des `accessibilityIdentifier` löst das Problem. Ein Fehler wurde an Apple gemeldet. (#1633)

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

In einigen Fällen verlässt sich unterstützende Technologie auf AccessibilityEvent Beschreibungen des Android-Systems, um Informationen anzusagen, 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. Dadurch kann Talkback die Informationen aus der Ansicht abrufen, die unser Tool dann erkennen kann.

Unsere Farbkontrastrege hängt von maschinellem Lernen ab, um Text zu erkennen, wodurch sichergestellt wird, dass der gescannte Text für die Benutzer Ihrer Anwendung sichtbar ist. In Fällen, in denen der in einer Ansicht enthaltene Text die gleiche Farbe wie der Hintergrund hat, kann unser Algorithmus für maschinelles Lernen nicht erkennen, ob Text vorhanden ist, sodass die Farbkontrastrege in dieser Ansicht nicht läuft.

Apps, die mit XML geschrieben wurden und die Feature für Hinweistexte verwenden, können mit der EditTextName Regel falsch-positive Ergebnisse sehen. Der Hinweistest wurde erst mit Android 8 (SDK 26) eingeführt. Wenn Sie dieses Element in Ihrer XML-App verwenden, wird der Hinweistext dem Wert des Texteingabefelds zugewiesen. Neuere Versionen von Android sind besser dafür ausgerüstet, diese Erfahrung zugänglich zu machen.

Um dieses Problem zu lösen, 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 erwägen, auf die Verwendung des hintText Features zu verzichten, da es nicht offiziell unterstützt wird.

Es können Ergebnisse für Ansichten angezeigt werden, die hinter anderen Ansichten auf dem Bildschirm verborgen sind. Diese verborgenen Ansichten sind assistiven Technologien nicht zugänglich, 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 die entsprechenden Probleme ignorieren, wenn TalkBack diese Ansichten nicht erreichen kann. Sie erfordern keine Lösung, um Barrierefreiheit sicherzustellen.

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 Sie Axe DevTools Mobile in Ihren automatisierten Espresso- oder UIAutomator-Tests referenzieren. In einigen Fällen findet der automatische Import jedoch nicht statt 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 lösen, sollten Sie die ML Kit-Bibliothek manuell in Ihr Projekt importieren. In der build.gradle Datei Ihrer Anwendung fügen Sie Folgendes unter den Abhängigkeiten hinzu:

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

Die Regel für den Berührungsziel-Abstand wird derzeit nicht auf Schiebereglerkomponenten angewendet, die in Jetpack Compose geschrieben wurden. Derzeit kann keine Maßnahme ergriffen werden. Allerdings wird bald eine Lösung bereitgestellt!

Auf Android API 30 tritt an einem der Orte, an denen wir versuchen, Ergebnisse lokal zu speichern, ein Berechtigungsfehler auf. Das Ergebnis wird dennoch 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 unerwartete Ergebnisse zurückgegeben werden, 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 auszublenden. Um die Axe Analyzer-App zu nutzen, stellen Sie bitte sicher, dass diese Einstellung nicht aktiviert ist. Wenn Sie sich entschieden haben, diese Funktion wegen der Sicherheitsverbesserungen zu verwenden, empfehlen wir, sie für interne Test-Builds auszuschalten, bei denen Sie sicher Testdaten verwenden und Sicherheitsbedenken auf diese Weise eliminieren 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 die volle Funktionalität 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 Mock-Daten verwendet, um Sicherheitsbedenken zu vermeiden. Sehen Sie sich unseren Leitfaden zum Aktivieren von Screenshots in Android-Apps

Wenn Sie Ihren Build minifizieren, stürzt dieser mit einem Fehlerprotokoll ab, das besagt, dass kein Adapter gefunden werden konnte, wenn Sie versuchen, sich bei der Axe DevTools-Bibliothek anzumelden. Deaktivieren Sie Minify für Ihre Debug-Builds mit implementierten Axe DevTools. (#729)

Ein Build mit aktiviertem r8 kann versuchen, die axeDevTools-Bibliothek zu minifizieren, was zu einem Fehler führt, der folgendermaßen aussieht:

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 weiterhin die Compose APIs verwenden und auf einen Fehler stoßen wie „Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)“ oder „No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?“, lesen Sie bitte Compose setTestTag API.

Aufgrund der Einschränkungen der MAUI App-Architektur im Android-Ökosystem wird die Edit Text Name Regel im Dashboard als Überprüfung erforderlich angezeigt, wenn ein Fehler für SDK-Version 5.5.0 und höher vermutet wird. Bitte überprüfen Sie in diesem Fall das korrekte Verhalten manuell.

Wenn Sie benutzerdefinierte Dialoge oder Modals implementieren, die die nativen Steuerelemente nicht erweitern, können Sie Ergebnisse für Ansichten hinter dem Modal erhalten. In diesem Fall empfehlen wir, unser Tool nicht gegen diese benutzerdefinierten Modals oder Dialoge auszuführen, sondern sie stattdessen manuell zu überprüfen, um sicherzustellen, dass sie mit assistiven Technologien wie gewünscht funktionieren.

Wenn der Screenshot auf der Scan-Detailseite fehlt, kann es sein, dass Ihre App verhindert, dass Screenshots gemacht werden. Oft ist dies aus Sicherheitsgründen in Ihrer Produktionsanwendung der Fall. 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-Scannnamen, die standardmäßig als Bildschirmtitel festgelegt sind, erscheinen als vollständiger Klassenname einschließlich des Paketbezeichners. In einer zukünftigen Version wird dieses Problem behoben, sodass der Bildschirmtitel in einen lesbareren Namen formatiert wird. Als Übergangslösung können Sie den Scannnamen vom Dashboard oder den Frameworks aus festlegen. (#1643)