Axe DevTools Mobile April 22, 2026 Release Notes

Beim Ausführen von Barrierefreiheitstests auf kleineren Bildschirmgrößen oder mit kleineren Schriftgrößen kann die Farbkontrastregel Falschpositive für Farbverläufe melden. In solchen Fällen kann es sein, dass die Vordergrundfarbe nicht ermittelt werden kann und stattdessen Hintergrundfarben miteinander verglichen werden, was zu einem Fehler führt.

Um dieses Problem zu umgehen, versuchen Sie, Barrierefreiheitstests 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.

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

iOS 26 enthält einen Barrierefreiheits-Bug, bei dem Standard-Stepper-Schaltflächen nicht „gedimmt“ durch Assistive Technologie ankündigen, um anzuzeigen, dass sie nicht aktiviert sind. Infolgedessen sehen die iOS-Regeln diese Schaltflächen als aktiviert an, auch wenn sie es nicht sind. Ein Fehlerbericht wurde bei Apple eingereicht, aber solange dies nicht behoben ist, können die folgenden Regeln Ergebnisse auf deaktivierten Stepper-Schaltflächen melden: AssociatedText, InaccessibleAction, und ColorContrast.

Bis Apple diesen Bug behebt, besteht die Lösung darin, die [Regeln zu ignorieren](ios-ignore-rule). Die Standard-Stepper-Schaltflä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 Falschpositive mit LabelInName und LabelAtFront aufgrund einer falsch ermittelten associatedText-Eigenschaft melden (#1622)

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

Während wir eine Verbesserung unserer Regeln betrachteten, stellten wir fest, dass in XCTest verschachtelte Steuerelemente im Accessibility-Baum nicht zurückgegeben werden. Ein Fehlerbericht wurde bei Apple eingereicht. (#1110)

In UIKit-Apps ist ein Bild ohne ein `accessibilityLabel` standardmäßig nicht mit unterstützenden Technologien 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 "Überprüfung erforderlich" gemeldet. Ein Fehlerbericht wurde bei Apple eingereicht. (#1633)

Wir arbeiten aktiv an Korrekturen 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 Nachricht "Überprüfung erforderlich" markiert werden. Um diese Elemente für diejenigen verfügbar zu machen, die größere Schrift benötigen, verwenden Sie UILargeContentViewer. (#622)

v2.11.0 Image View Name & Active Control Name
Wenn ein UIImageView einen `accessibilityIdentifier` gesetzt hat, aber nicht von VoiceOver fokussierbar ist und verschachtelte fokussierbare Steuerelemente enthält, kann ActiveControlName ein falsch positives Ergebnis auf dem UIImageView melden. Das Entfernen des `accessibilityIdentifier` löst das Problem. Ein Fehlerbericht wurde bei Apple eingereicht. (#1633)

Label In Name and Label At Front
Diese beiden Regeln suchen nach einem sichtbaren Label eines Steuerungselements 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 die unterstützende Technologie auf AccessibilityEvent Beschreibungen aus dem Android-System, um dem Benutzer Informationen bereitzustellen, 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 Farbkontrastregel hängt von maschinellem Lernen ab, um Text zu erkennen, was sicherstellt, 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 maschinelles Lernalgorithmus nicht feststellen, ob Text vorhanden ist, sodass die Farbkontrastregel für diese Ansicht nicht ausgeführt wird.

In XML geschriebene Apps, die die Hint-Text-Funktion nutzen, können falsche Positivmeldungen mit der EditTextName Regel sehen. Hint-Text wurde erst in 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 ausgestattet, um dieses Erlebnis zugänglich zu machen.

Um dieses Problem zu überwinden, empfehlen wir als erstes, Ihre Tests auf neueren Android-Versionen durchzuführen. Sollte es jedoch wichtig sein, dass die App auf älteren Android-Versionen zugänglich ist, sollten Sie die Verwendung des hintText Features erwägen, da es nicht offiziell unterstützt wird.

Sie können Ergebnisse für Ansichten sehen, die hinter anderen Ansichten auf dem Bildschirm verborgen sind. Diese versteckten Ansichten sind für unterstützende Technologien nicht 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, wenn TalkBack diese Ansichten nicht erreichen kann, können Sie die entsprechenden Probleme ignorieren. Sie erfordern keine Lösung, um die Zugänglichkeit zu gewährleisten.

ML Kit Text-Detection 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 Axe DevTools Mobile in Ihren automatisierten Espresso- oder UIAutomator-Tests referenziert wird. In einigen Fällen geschieht 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 überwinden, 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 Regel für den Abstand der Berührungsziele wird derzeit nicht auf Slider-Komponenten angewendet, die in Jetpack Compose geschrieben wurden. Derzeit können keine Maßnahmen ergriffen werden. Eine Lösung ist jedoch in Kürze verfügbar!

Auf Android API 30 hat einer der Speicherorte, an denen wir versuchen, Ergebnisse lokal zu speichern, einen Berechtigungsfehler. Das Ergebnis wird trotz dieser Fehlermeldung weiterhin als JSON-Datei gespeichert. Der Fehler kann unterdrückt werden, indem Sie den Code im folgenden Block auskommentieren:

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 Scroll-Ansicht 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 Fähigkeit eingeführt, nicht-systemische Overlays auszublenden. Um die Axe Analyzer-App zu nutzen, stellen Sie bitte sicher, dass diese Einstellung nicht aktiviert ist. Wenn Sie sich entscheiden, diese Funktion für ihre Sicherheitsverbesserungen zu nutzen, empfehlen wir, sie für interne Testversionen ausgeschaltet zu lassen, in denen Sie sicher Testdaten verwenden und auf diese Weise Sicherheitsbedenken beseitigen 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 Mobilgeräte freizuschalten, stellen Sie sicher, dass Screenshots aktiviert sind. Wir empfehlen, Screenshots in einer Debug- oder Testversion Ihrer App zu aktivieren, die Testdaten verwendet, um Sicherheitsbedenken zu vermeiden. Sehen Sie sich unseren Leitfaden an für Aktivierung von Screenshots in Android-Apps.

Wenn Sie Ihren Build verkleinern, sehen Sie einen Absturz mit einer Fehlerprotokollmeldung, dass ein Adapter nicht gefunden werden konnte, als versucht wurde, sich in die Axe DevTools-Bibliothek einzuloggen. Deaktivieren Sie die Verkleinerung für Ihre Debug-Builds mit implementiertem Axe DevTools. (#729)

Ein Build mit aktiviertem r8 kann versuchen, die axeDevTools-Bibliothek zu minimieren, was zu einem Fehler ähnlich dem folgenden führen kann:

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 weiterhin 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()?`, beachten Sie bitte Compose setTestTag API.

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

Wenn Sie benutzerdefinierte Dialoge oder Modale implementieren, die die nativen Steuerelemente nicht erweitern, können Ergebnisse für Ansichten hinter dem Modal angezeigt werden. In diesem Fall empfehlen wir, unser Tool nicht gegen diese benutzerdefinierten Modale oder Dialoge auszuführen und stattdessen manuell zu überprüfen, ob sie mit unterstützender Technologie wie gewünscht funktionieren.

Wenn der Screenshot auf der Seite mit den Scan-Details fehlt, kann es sein, dass Ihre App verhindert, dass Screenshots gemacht werden. Oft 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 dem Bildschirmtitel entsprechen, werden als vollständiger Klassenname einschließlich des Bundle-Identifiers angezeigt. In einer zukünftigen Version wird dieses Problem behoben, sodass der Bildschirmtitel in einen besser lesbaren Namen formatiert wird. Als Umgehungslösung können Sie den Scan-Namen vom Dashboard oder Frameworks aus festlegen. (#1643)