Axe DevTools Mobile Release Notes vom 4. Februar 2026

Beim Durchführen von Barrierefreiheitsprüfungen auf kleineren Bildschirmgrößen oder mit kleineren Schriftgrößen kann die Regel Farbkontrast falsche positive Ergebnisse für Verlaufs-Hintergründe melden. In solchen Fällen ist es möglicherweise nicht möglich, die Vordergrundfarbe zu bestimmen und vergleicht stattdessen Hintergrundfarben miteinander, was zu einem Fehler führt.

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

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) überlagert ist. Dies tritt auf, weil das Barrierefreiheitssystem prüft, ob der WKWebView-Container selbst sichtbar ist, anstatt zu prüfen, ob seine Webinhalte tatsächlich ungehindert und für den Benutzer wahrnehmbar sind.

iOS 26 enthält einen Barrierefreiheitsfehler, bei dem Standard-Schrittschalter nicht " AssociatedTextgedimmt“ von unterstützender Technologie angekündigt werden, um anzuzeigen, dass sie nicht aktiviert sind. Infolgedessen sehen die iOS-Regeln diese Schaltflächen als aktiviert, selbst wenn sie es nicht sind. Ein Fehlerbericht wurde bei Apple eingereicht, aber bis dieser Fehler behoben wird, könnten die folgenden Regeln Ergebnisse auf deaktivierten Schrittschaltern melden: InaccessibleAction, und ColorContrast.

Bis Apple diesen Fehler behebt, wird die Lösung darin bestehen, die [Regeln zu ignorieren](ios-ignore-rule). Die standardmäßigen Stepper-Tasten haben die Bezeichnungen „Decrement“ und „Increment“ und können bei Bedarf durch ihre 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 aufgrund einer falschen associatedText-Eigenschaft, die gefunden wurde (#1622), Falsch Positives mit LabelInName und LabelAtFront melden.

Es gibt ein Problem, das den iPhone 15 Pro Simulator betrifft und verhindert, dass die Unterstützt Dynamischen Typ-Regel ausgeführt wird. Wenn Sie sich für die Unterstützt Dynamischen Typ-Regel angemeldet haben, können Sie sie nicht mit einem iPhone 15 Pro Simulator testen. Ein Fehlerbericht wurde an Apple gesendet.

Bei der Betrachtung einer Verbesserung unserer Regeln haben wir festgestellt, dass in XCTest verschachtelte Steuerelemente nicht im Barrierefreiheitsbaum zurückgegeben werden. Ein Fehlerbericht wurde an Apple gesendet. (#1110)

In UIKit-Apps ist ein Bild ohne ein accessibilityLabel standardmäßig nicht mit assistiver Technologie fokussierbar.
Die Eigenschaften, die wir zur Überprüfung der Fokussierbarkeit von Apple verwenden, können ungenau sein, wenn ein accessibilityIdentifier auf das Bild gesetzt ist. Aufgrund dieses unerwarteten Verhaltens werden die Ergebnisse für ImageView-Namensprobleme in UIKit-Apps als „Benötigt Überprüfung“ gemeldet. Ein Fehlerbericht wurde an Apple gesendet. (#1633)

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

In Scroll View
Möglicherweise werden Probleme für Text innerhalb von Banner-verhaltenden Elementen gemeldet. Um diese Elemente für Benutzer mit größerem Text zugänglich zu machen, verwenden Sie UILargeContentViewer. (#622)

v2.11.0 Image View Name & Active Control Name
Wenn ein UIImageView einen accessibilityIdentifier gesetzt hat, aber nicht mit VoiceOver fokussierbar ist und fokussierbare Steuerelemente innerhalb davon verschachtelt sind, kann ActiveControlName ein Falsch Positiv auf dem UIImageView melden. Das Entfernen des accessibilityIdentifier löst das Problem. Ein Fehlerbericht wurde an Apple gesendet. (#1633)

Label In Name and Label At Front
Diese beiden Regeln suchen nach dem sichtbaren Label eines Steuerelements unter nahegelegenen Elementen, um den Regelstatus zu bestimmen. In einigen Ansichten-Hierarchien kann fälschlicherweise nahegelegener Text erkannt werden, was zu Regelversagen führt. (#1622)

In einigen Fällen sind Hilfstechnologien auf AccessibilityEvent Beschreibungen vom Android-System angewiesen, 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. Dadurch kann Talkback die Informationen aus der Ansicht abrufen, die unser Tool dann erkennen kann.

Unsere Farbkontrastregel ist von maschinellem Lernen abhängig, um Text zu erkennen, was sicherstellt, dass der gescannte Text für die Benutzer Ihrer Anwendung sichtbar ist. In Fällen, in denen der Text in einer Ansicht die gleiche Farbe wie der Hintergrund hat, ist unser Algorithmus für maschinelles Lernen nicht in der Lage zu erkennen, ob Text vorhanden ist, sodass die Farbkontrastregel auf dieser Ansicht nicht ausgeführt wird.

Apps, die mit XML geschrieben sind und die Hinweistextfunktion nutzen, können Falsch Positives mit der EditTextName -Regel sehen. Hinweistext wurde erst mit Android 8 (SDK 26) eingeführt. Die Verwendung dieses Elements in Ihrer XML-App weist den Hinweistext dem Wert des Texteingabefeldes zu. Neuere Android-Versionen sind besser ausgestattet, um dieses Erlebnis barrierefrei zu gestalten.

Um dieses Problem zu überwinden, ist unsere erste Empfehlung, Ihre Tests auf neueren Android-Versionen auszuführen. Wenn es jedoch wichtig ist, dass die App auf früheren Android-Versionen barrierefrei ist, sollten Sie in Erwägung ziehen, auf die Verwendung der hintText -Funktion zu verzichten, da sie offiziell nicht unterstützt wird.

Es kann sein, dass Sie Ergebnisse für Ansichten sehen, die hinter anderen Ansichten auf dem Bildschirm verborgen sind. Diese verborgenen Ansichten sind für Hilfstechnologien 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, wenn TalkBack diese Ansichten nicht erreichen kann, können Sie die entsprechenden Probleme ignorieren. Sie erfordern keine Korrektur, um Barrierefreiheit sicherzustellen.

Die ML Kit Texterkennung ist für viele der Axe DevTools Mobile-Regeln erforderlich, um die Genauigkeit der Ergebnisse zu gewährleisten. 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 jedoch erfolgt der automatische Import nicht und Sie sehen den folgenden Fehler im Logcat:

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 das Folgende unter Abhängigkeiten hinzu:

Die Touch Target Spacing-Regel wird derzeit nicht auf Schiebereglerkomponenten ausgeführt, die in Jetpack Compose geschrieben wurden. Derzeit kann keine Maßnahme ergriffen werden. Es kommt jedoch bald eine Lösung!

Auf Android API 30 tritt bei einem der Speicherorte, an dem wir versuchen, Ergebnisse lokal zu speichern, ein Berechtigungsfehler auf. Das Ergebnis wird trotzdem als JSON-Datei gespeichert, obwohl dieser Fehler angezeigt wird. 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'
// finalizedBy {
// fetchAndroidFolderAxeReportsTask
// }
}

Bitte beachten Sie, dass dieser Code nur für API 30 auskommentiert werden sollte, da er bei anderen API-Leveln Probleme beim lokalen Speichern verursacht.

In einigen hybriden und plattformübergreifenden Apps können wir unerwartete Ergebnisse zurückgeben, wenn Elemente in einer Scroll-Ansicht teilweise vom Bildschirm verschwunden 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 diese Funktion aus Sicherheitsgründen nutzen möchten, empfehlen wir, sie für interne Test-Builds deaktiviert zu lassen, wo Sie sicher Testdaten verwenden können und Sicherheitsbedenken auf diese Weise eliminieren. 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) für die betroffenen Aktivitätsfenster.

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. Überprüfen Sie unseren Leitfaden zum Aktivieren von Screenshots in Android-Apps.

Wenn Sie Ihre Build minimieren, werden Sie einen Absturz mit einem Fehlerprotokoll bemerken, das meldet, dass ein Adapter nicht gefunden werden konnte, wenn versucht wird, sich in die Axe DevTools-Bibliothek einzuloggen. Deaktivieren Sie die Minimierung für Ihre Debug-Builds, in denen Axe DevTools implementiert ist. (#729)

Ein Build mit aktiviertem r8 versucht möglicherweise, die axeDevTools-Bibliothek zu minimieren, was zu einem Fehler führt, der wie folgt 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)
Um diesen Fehler zu beheben, fügen Sie Ihrer ProGuard-Datei folgende Zeile hinzu, um axeDevTools-Klassen beizubehalten:
keep class com.deque.** { *; }

Die Compose-APIs sind veraltet, bitte verwenden Sie die layout-unabhängigen APIs , um weiterhin Updates zu erhalten. Wenn Sie weiterhin die Compose-APIs nutzen und auf einen Fehler stoßen, der sich ähnlich wie `Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)` oder `No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?` anhört, beziehen Sie sich bitte auf Compose setTestTag API.

Wenn Sie diese Nachricht erhalten, könnten einige Regelergebnisse nicht wie erwartet zurückgegeben werden, wenn diese Regel künstliche Intelligenz nutzt. Betroffene Regeln sind Farbkontrast, fokussierbarer Text und verschachtelte Elementnamen. (#841)

Aufgrund von Einschränkungen der MAUI-App-Architektur im Android-Ökosystem wird die Regel für Bearbeiten-Text-Name im Dashboard als Überprüfung erforderlich 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 Steuerungen 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 auszuführen, sondern sie manuell zu überprüfen, um sicherzustellen, dass sie wie gewünscht mit unterstützender Technologie funktionieren.

Wenn der Screenshot auf der Scan-Detailseite fehlt, könnte Ihre App verhindern, 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-Scannamen, die auf den Bildschirmtitel voreingestellt sind, werden als vollständiger Klassenname einschließlich des Bundle-Identifikators angezeigt. In einer zukünftigen Version wird dieses Problem behoben, damit der Bildschirmtitel in einen besser lesbaren Namen formatiert wird. Als Workaround können Sie den Scannamen vom Dashboard oder den Frameworks aus festlegen. (#1643)