Axe DevTools Mobile Versionshinweise zur Veröffentlichung am 20. Juli 2026

Die Farbkontrastregel verwendet Apples Vision Framework (Optical Character Recognition, oder OCR), um Text innerhalb eines Elementrahmens zu lesen. OCR kann gelegentlich kleine, symbolartige Glyphen - wie Pfeilspitzen (<), Aufzählungszeichen, dekorative Symbole - fälschlicherweise als Text identifizieren. Wenn dies geschieht, wird die Farbkontrastregel auf ein Element angewendet, das keinen lesbaren Text enthält, was zu einem Ergebnis für eine Schaltfläche mit nur Symbolen führen kann. Da die OCR-Ausgabe über Scans hinweg nicht deterministisch ist, kann dasselbe Element in Farbkontrastergebnissen in einem Scan erscheinen und im nächsten als "NICHT ANWENDBAR" gemeldet werden. Dies ist eine bekannte Eigenschaft von OCR, kein Fehler in der Regel.

Um dieses Problem zu umgehen, können Sie die ignore APIs verwenden, um Farbkontrastergebnisse für die betroffenen Elemente zu unterdrücken.

// Ignore Color Contrast for a specific element by accessibility identifier
axeDevTools?.configuration.ignore(rulesFor: [
    "backButton": [AxeRuleId.ColorContrast.toString()]
])

Flutter ordnet nicht AppBar.title der nativen Bildschirmtitel-Eigenschaft zu - UIViewController.title, was dazu führt, dass die Bildschirmtitelregel auf allen Flutter-Bildschirmen fehlschlägt, unabhängig davon, ob ein beschreibender Titel vorhanden ist.

Dies ist eine bekannte Einschränkung der Flutter-Plattform, die in flutter/flutter#185894verfolgt wird.

Beim Ausführen von Barrierefreiheitsprüfungen auf kleineren Bildschirmgrößen oder mit kleineren Schriftgrößen kann die Farbkontrastregel bei Hintergrundverläufen falsch positive Ergebnisse melden. In solchen Fällen kann es sein, dass die Vordergrundfarbe nicht bestimmt werden kann und stattdessen die Hintergrundfarben miteinander verglichen werden, was zu einem Fehler führt.

Um dieses Problem zu umgehen, versuchen Sie, die Barrierefreiheitsprüfungen auf größeren Geräten auszufü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önnten Webinhalte innerhalb von WKWebView fälschlicherweise als "isVisible" melden, selbst wenn die Webansicht durch native Überlagerungen (wie modale Ansichten, Warnungen oder andere native UI-Elemente) verdeckt wird. Dies geschieht, weil das Barrierefreiheitssystem prüft, ob der WKWebView-Container selbst sichtbar ist, anstatt ob dessen Webinhalt tatsächlich ungehindert und für den Benutzer wahrnehmbar ist.

iOS 26 enthält einen Barrierefreiheitsfehler, bei dem Standard-Taster von Assistive Technology nicht als "gedimmt" angesagt werden, um anzuzeigen, dass sie nicht aktiviert sind. Infolgedessen sehen die iOS-Regeln diese Taster ebenfalls als aktiviert an, auch wenn sie es nicht sind. Ein Fehlerbericht wurde bei Apple eingereicht, aber bis dies gelöst wird, können die folgenden Regeln Ergebnisse für deaktivierte Taster melden: AssociatedText, InaccessibleAction, und ColorContrast.

Solange Apple diesen Fehler nicht behebt, wird die Lösung sein, [die Regeln zu ignorieren](ios-ignore-rule). Die Standard-Taster 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 aufgrund einer falsch zugeordneten associatedText-Eigenschaft (#1622) falsch positive Ergebnisse bei LabelInName und LabelAtFront melden

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

Bei der Betrachtung einer Verbesserung unserer Regeln haben wir festgestellt, dass in XCTest verschachtelte Steuerungen nicht im Barrierefreiheitsbaum zurückgegeben 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 von Apple zu überprüfen, können ungenau sein, wenn ein `accessibilityIdentifier` auf dem 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 an Apple gesendet. (#1633)

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

In Scroll View
Text innerhalb von bannerartig agierenden Elementen kann mit einer Nachricht "Überprüfung erforderlich" markiert werden. Um diese Elemente für diejenigen zugänglich zu machen, die größere Text 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 fokussierbar ist und fokussierbare Steuerelemente darin verschachtelt sind, kann ActiveControlName ein falsch positives Ergebnis auf dem UIImageView melden. Das Entfernen des `accessibilityIdentifier` löst das Problem. Ein Fehler wurde bei Apple gemeldet. (#1633)

Label In Name and Label At Front
Diese zwei Regeln suchen anhand von nahegelegenen Elementen nach dem sichtbaren Label eines Steuerelements, um den Regelstatus zu bestimmen. In einigen Ansichts-Hierarchien kann falscher nahegelegener Text erkannt werden, was dazu führt, dass diese Regeln fehlschlagen. (#1622)

Die Regel "Label vorne" überprüft, dass das sichtbare Label eines Elements am Anfang des angekündigten Textes steht. Ein Regelversagen kann auftreten, wenn der sichtbare Text eines interaktiven Elements eine Abkürzung (z. B. "GB", "km") oder einen verdeckten/abgekurzten Bezeichner enthält und die Barrierefreiheitsansage aus den repräsentierten Wörtern besteht (z. B. "Gigabytes", "Kilometer"), auch wenn dies das empfohlene Muster ist, um gekürzten Inhalt für Bildschirmleser nutzbar zu machen.

Wenn der erste Teil des sichtbaren Labels eines interaktiven Elements mit dem Beginn der Bildschirmleseransage übereinstimmt und nur der abgekürzte/verdeckte Teil abweicht, kann das markierte Ergebnis sicher ignoriert werden. Überprüfen Sie mit einem Bildschirmleser, ob die vollständige Ansage wie vorgesehen gelesen wird.

Bei der Verwendung von dekorativem Text in Ansichten wie "Kontakt-Icons" kann ein Barrierefreiheitsproblem auftreten. Wenn Sie eine Textansicht verwenden, um Buchstaben anzuzeigen, anstatt Bilder mit den gewünschten Buchstaben als Vektoren zu erzeugen, und Sie dann diese Textansicht als nicht wichtig für Barrierefreiheit deklarieren, können wir nicht zuverlässig feststellen, ob Sie eine Barrierefreiheitsverletzung eingeführt haben.

Wenn Sie fokussierbaren Text so bearbeiten, dass zwei oder weniger Zeichen ignoriert werden, könnten Sie unabsichtlich viele Ein-Wort-Schaltflächen in verschiedenen Sprachen ignorieren (z. B. "OK", "Nein", "Sí"). Um diese Probleme zu vermeiden, sollten Sie die gewünschten Buchstaben aus dem Wort greifen, das Sie im Icon darstellen möchten, und die Buchstaben als Teil des Bildes und nicht als separate Textansichten generieren. `FocusableText` wird dann auf diesen Ansichten nicht ausgeführt.

Flutter ordnet nicht AppBar.title der nativen Bildschirmlänge-Eigenschaft zu - Activity.setTitle, was dazu führt, dass die Bildschirmlänge-Regel auf allen Flutter-Bildschirmen fehlschlägt, unabhängig davon, ob ein beschreibender Titel vorhanden ist.

Dies ist eine bekannte Flutter-Plattformbeschränkung, die verfolgt wird in flutter/flutter#185894.

In einigen Fällen verlässt sich die unterstützende Technologie auf AccessibilityEvent Beschreibungen des Android-Systems, um Informationen an den Benutzer auszugeben, wenn keine andere Bekanntmachung verfügbar ist. Da AccessibilityEvente durch Benutzeraktionen ausgelöst werden, können wir nicht auf die korrekte Beschreibung zugreifen, wenn diese Information nicht bereitgestellt wird.

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

Unsere Kontrastregel ist auf maschinelles Lernen angewiesen, 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 Text innerhalb einer Ansicht die gleiche Farbe wie der Hintergrund hat, kann unser maschinelles Lernalgorithmus nicht erkennen, ob Text vorhanden ist, sodass die Kontrastregel in dieser Ansicht nicht ausgeführt wird.

Apps, die mit XML geschrieben sind und die Hinweistextfunktion nutzen, können falsch positive Ergebnisse 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 Text-Eingabefelds zu. Neuere Versionen von Android sind besser ausgestattet, um dieses Erlebnis zugänglich zu machen.

Um dieses Problem zu überwinden, wird zunächst empfohlen, Ihre Tests auf neueren Android-Versionen auszuführen. Wenn es jedoch wichtig ist, dass die App auf älteren Android-Versionen zugänglich ist, sollten Sie die Verwendung der hintText Funktion vermeiden, da sie nicht offiziell unterstützt wird.

Möglicherweise sehen Sie Ergebnisse für Ansichten, die hinter anderen Ansichten auf dem Bildschirm verborgen sind. Diese verborgenen Ansichten sind für unterstützende Technologie 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 können Sie, wenn TalkBack diese Ansichten nicht erreichen kann, die entsprechenden Probleme ignorieren. Sie erfordern keine Lösung, um die Barrierefreiheit sicherzustellen.

ML Kit Texterkennung ist in vielen der Axe DevTools Mobile-Regeln erforderlich, um die Genauigkeit der Ergebnisse zu gewährleisten. Die ML Kit-Bibliothek sollte automatisch importiert werden, wenn Sie auf Axe DevTools Mobile in Ihren automatisierten Espresso- oder UIAutomator-Tests verweisen. In einigen Fällen erfolgt jedoch der automatische Import nicht, und Sie werden den folgenden Fehler in der Logcat sehen:

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 Ihrer build.gradle Datei fügen Sie das Folgende unter "dependencies" hinzu:

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

Die Regel für den Touch-Ziel-Abstand wird derzeit nicht auf Schieberelemente angewendet, die in Jetpack Compose geschrieben wurden. Es kann momentan keine Maßnahme ergriffen werden. Eine Lösung kommt jedoch bald!

Auf Android API 30 verursacht einer der Speicherorte, 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 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 sichtbar 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. Sollten Sie diese Funktion aus Sicherheitsgründen nutzen, empfehlen wir, sie für interne Test-Builds ausgeschaltet zu lassen, wo 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) bei 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 an.

Wenn Sie Ihren Build minimieren, kommt es zu einem Absturz mit einem Fehlerprotokoll, das meldet, dass kein Adapter gefunden werden konnte, wenn versucht wird, sich in die Axe DevTools-Bibliothek einzuloggen. Deaktivieren Sie die Minimierung für Ihre Debug-Builds mit implementierten Axe DevTools. (#729)

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

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 wie `Genau '1' Knoten erwartet, aber '2' Knoten gefunden, die folgende Bedingung erfüllen: (isRoot)` oder `Kein View initialisiert, haben Sie AxeDevToolsCompose.setComposeTestRule() aufgerufen?` stoßen, beachten Sie bitte Compose setTestTag API.

Aufgrund von Einschränkungen der MAUI-App-Architektur im Android-Ökosystem wird die Regel „Edit Text Name“ im Dashboard als Überprüfung erforderlich angezeigt, wenn ab SDK-Version 5.5.0 ein Fehler vermutet wird. Bitte bestätigen Sie in diesem Fall manuell das korrekte Verhalten.

Wenn Sie benutzerdefinierte Dialoge oder Modale 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 Modale oder Dialoge auszuführen und stattdessen manuell zu überprüfen, ob sie wie gewünscht mit unterstützender Technologie funktionieren.

Wenn der Screenshot auf der Scan-Detail-Seite fehlt, könnte Ihre App das Erstellen von Screenshots verhindern. 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 auf den Bildschirmtitel gesetzt sind, erscheinen als vollständiger Klassenname einschließlich der Bundle-ID. In einer zukünftigen Version wird dieses Problem behoben, sodass der Bildschirmtitel in einen lesbareren Namen formatiert wird. Als Workaround können Sie den Scan-Namen vom Dashboard oder über die Frameworks festlegen. (#1643)