Axe DevTools Mobile Versionshinweise vom 17. Juni 2026

Die Farbkontrastregel verwendet Apples Vision-Framework (Optical Character Recognition, oder OCR), um Text innerhalb der Grenzen eines Elements zu lesen. OCR kann gelegentlich kleine, iconartige Glyphen - wie Pfeil-Symbole (<), Aufzählungszeichen, dekorative Symbole - fälschlicherweise als Text identifizieren. Wenn das passiert, wird die Farbkontrastregel auf einem Element ohne lesbaren Text angewendet, was zu einem Ergebnis für eine reine Schaltfläche mit Symbol führen kann. Da OCR-Ausgaben bei verschiedenen Scans nicht deterministisch sind, kann dasselbe Element in einem Scan in den Farbkontrastergebnissen erscheinen und im nächsten als „NICHT ANWENDBAR“ gemeldet werden. Dies ist eine bekannte Eigenschaft von OCR und kein Fehler in der Regel.

Um dieses Problem zu umgehen, können Sie die ignore APIs verwenden, um Farbkontrast-Ergebnisse 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 kartiert nicht AppBar.title auf die native Bildschirmitteleigenschaft - UIViewController.title, was dazu führt, dass die Regel für den Bildschirmitel bei allen Flutter-Bildschirmen fehlschlägt, unabhängig davon, ob ein beschreibender Titel vorhanden ist.

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

Beim Ausführen von Barrierefreiheitsprüfungen auf kleineren Bildschirmgrößen oder mit kleineren Schriftgrößen kann die Farbkontrastregel aufgrund von Verlaufs-Hintergründen falsche Fehlermeldungen erzeugen. In solchen Fällen kann es sein, dass die Vordergrundfarbe nicht bestimmt werden kann, und stattdessen werden Hintergrundfarben miteinander verglichen, 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 manuell für diese Ansichten überprüfen.

Apples Barrierefreiheits-APIs können Webinhalte innerhalb eines WKWebView fälschlicherweise als "isVisible" darstellen, auch wenn die Webansicht durch native Overlays (wie modale Ansichten, Warnungen oder andere native UI-Elemente) verdeckt ist. Dies tritt auf, weil das Barrierefreiheitssystem überprüft, ob das WKWebView-Container selbst sichtbar ist, anstatt ob dessen Webinhalte tatsächlich ungehindert und für den Nutzer wahrnehmbar sind.

iOS 26 enthält einen Barrierefreiheitsfehler, bei dem Standard-Schrittschalter von unterstützender Technologie nicht als „gedimmt“ angekündigt werden, um anzuzeigen, dass sie nicht aktiviert sind. Infolgedessen sehen auch die iOS-Regeln diese Schaltflächen als aktiviert an, selbst wenn sie es nicht sind. Ein Fehlerbericht wurde bei Apple eingereicht, aber bis dies gelöst ist, können die folgenden Regeln Ergebnisse bei deaktivierten Schrittschaltern melden: AssociatedText, InaccessibleAction, und ColorContrast.

Bis Apple diesen Fehler behebt, besteht die Lösung darin, die [Regeln zu ignorieren](ios-ignore-rule). Die Standard-Stepper-Tasten haben die Bezeichnungen „Decrement“ und „Increment“ und können bei Bedarf anhand ihrer 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 melden möglicherweise Falschpositive bei LabelInName und LabelAtFront aufgrund einer falschen associatedText-Eigenschaft (#1622)

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

Bei der Suche nach einer Verbesserung unserer Regeln haben wir festgestellt, dass in XCTest verschachtelte Steuerelemente nicht im Barrierefreiheitsbaum zurückgegeben werden. Ein Fehler wurde bei Apple gemeldet. (#1110)

In UIKit-Apps ist ein Bild ohne ein `accessibilityLabel` standardmäßig nicht mit unterstützender Technologie fokussierbar.
Die Eigenschaften, die wir von Apple verwenden, um die Fokussierbarkeit 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 Namensprobleme in UIKit-Apps als Überprüfungsbedarf gemeldet. Ein Fehlerbericht wurde bei Apple eingereicht. (#1633)

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

In Scroll View
Text in bannerähnlichen Elementen wird möglicherweise mit einer „Überprüfung erforderlich“-Nachricht gekennzeichnet. Um diese Elemente für Benutzer zugänglich zu machen, die größere Texte benötigen, verwenden Sie UILargeContentViewer. (#622)

v2.11.0 Image View Name & Active Control Name
Wenn eine UIImageView ein `accessibilityIdentifier` gesetzt hat, aber von VoiceOver nicht fokussiert werden kann und sie fokussierbare Steuerelemente enthält, kann ActiveControlName ein Falschpositiv für die UIImageView melden. Entfernen des `accessibilityIdentifier` löst das Problem. Ein Fehler wurde bei Apple gemeldet. (#1633)

Label In Name and Label At Front
Diese beiden Regeln suchen nach dem sichtbaren Label eines Steuerelements unter den 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)

Bei der Verwendung dekorativer Texte in Ansichten wie „Kontakt-Icons“ kann ein Zugänglichkeitsproblem entstehen. Wenn Sie eine Textansicht verwenden, um Buchstaben anzuzeigen, anstatt die gewünschten Buchstaben als Vektoren in Bilder zu generieren, und Sie dann diese Textansicht als nicht wichtig für die Zugänglichkeit deklarieren, können wir nicht zuverlässig feststellen, ob Sie eine Zugänglichkeitsverletzung eingeführt haben.

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

Flutter kartiert nicht AppBar.title auf die native Bildschirmitteleigenschaft - Activity.setTitle, was dazu führt, dass die Regel für den Bildschirmitel bei allen Flutter-Bildschirmen fehlschlägt, unabhängig davon, ob ein beschreibender Titel vorhanden ist.

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

In einigen Fällen verlassen sich unterstützende Technologien auf AccessibilityEvent Beschreibungen aus dem Android-System, um Informationen für den Benutzer anzukündigen, wenn keine andere Ankündigung verfügbar ist. Da AccessibilityEventdurch Benutzeraktionen ausgelöst werden, können wir nicht auf die korrekte Beschreibung zugreifen, wenn diese Informationen nicht bereitgestellt werden.

Um dieses Problem zu vermeiden, stellen Sie sicher, dass alle relevanten Ansichten als wichtig für die Zugänglichkeit markiert sind. Dies ermöglicht es Talkback, die Informationen aus der Ansicht abzurufen, die von unserem Tool dann erkannt werden können.

Unsere Farbkontrastrege basiert auf maschinellem Lernen zur Texterkennung, 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, kann unser maschinelles Lernalgorithmus nicht erkennen, ob Text vorhanden ist, sodass die Farbkontrastrege für diese Ansicht nicht ausgeführt wird.

Apps, die mit XML geschrieben sind und die Hint-Text-Funktion verwenden, können auf Falschpositive mit der EditTextName -Regel stoßen. Hint-Text wurde erst in Android 8 (SDK 26) eingeführt. Die Verwendung dieses Elements in Ihrer XML-App weist dem Texteingabefeld den Wert des Hint-Texts zu. Neuere Android-Versionen sind besser ausgestattet, um dieses Erlebnis zugänglich zu machen.

Um dieses Problem zu umgehen, empfehlen wir in erster Linie, Ihre Tests auf neueren Android-Versionen auszuführen. Ist es jedoch wichtig, dass die App auf früheren Android-Versionen zugänglich ist, sollten Sie in Erwägung ziehen, auf die Nutzung der hintText Funktion zu verzichten, da sie nicht offiziell unterstützt wird.

Sie können Ergebnisse für Ansichten sehen, die sich hinter anderen Ansichten auf dem Bildschirm verbergen. Diese verborgenen 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 Korrektur, um die Zugänglichkeit sicherzustellen.

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 axe DevTools Mobile in Ihren automatisierten Espresso- oder UIAutomator-Tests referenziert wird. In einigen Fällen erfolgt der automatische Import jedoch nicht und Sie sehen folgenden Fehler im Logcat:

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

Um dieses Problem zu umgehen, 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 kann keine Maßnahme ergriffen werden. Eine Lösung ist jedoch bald verfügbar!

Unter Android API 30 tritt ein Berechtigungsfehler an einem der Speicherorte auf, an dem wir versuchen, Ergebnisse lokal zu speichern. Das Ergebnis wird trotzdem als JSON-Datei gespeichert, obwohl dieser Fehler angezeigt wird. Der Fehler kann unterdrückt werden, indem der Code im folgenden Block 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 auftreten, wenn Elemente in einem Scroll-View teilweise vom Bildschirm abweichen. 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 zu verbergen. Um die axe Analyzer App zu nutzen, stellen Sie sicher, dass diese Einstellung nicht aktiviert ist. Wenn Sie sich entschieden haben, diese Funktion wegen der Sicherheitsverbesserungen zu nutzen, empfehlen wir, sie für interne Test-Builds zu deaktivieren, bei denen Sie Testdaten sicher verwenden können, um Sicherheitsbedenken auf diese Weise zu beseitigen. 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 verwenden, aktualisieren Sie alle Aufrufe der Methode setHideOverlayWindows(true) zu setHideOverlayWindows(false) auf den betroffenen Aktivitätsfenstern.

Um die volle Funktionalität der 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 Ihre Build verkleinern, wird ein Absturz mit einem Fehlerprotokoll angezeigt, in dem berichtet wird, dass ein Adapter nicht gefunden werden konnte, wenn versucht wird, sich bei der axe DevTools-Bibliothek anzumelden. Deaktivieren Sie die Verkleinerung für Ihre Debug-Builds mit implementierten axe DevTools. (#729)

Ein Build mit aktiviertem r8 könnte versuchen, die axeDevTools-Bibliothek zu verkleinern, was zu einem Fehler führt, ähnlich 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 weiterhin verwenden und auf einen Fehler stoßen, der etwa lautet: `Erwartet exakt '1' Knoten, aber es wurden '2' Knoten gefunden, die die Bedingung erfüllen: (isRoot)` oder `Keine Ansicht 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 zur Benennung von Edit Text im Dashboard als 'Benötigt Überprüfung' angezeigt, wenn bei SDK-Version 5.5.0 und höher ein Fehler 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 Ergebnisse für Ansichten hinter dem Modal auftreten. In diesem Fall empfehlen wir, unser Tool nicht gegen diese benutzerdefinierten Modals oder Dialoge laufen zu lassen, sondern sie stattdessen manuell zu überprüfen, um sicherzustellen, dass sie mit unterstützender Technologie wie gewünscht funktionieren.

Wenn der Screenshot auf der Scan-Detailseite fehlt, verhindert Ihre App möglicherweise das Erstellen von Screenshots. Oft geschieht dies aus Sicherheitsgründen in Ihrer Produktionsanwendung. Ziehen Sie in Betracht, diese Anforderung für Ihre Testversion 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 zugewiesen werden, erscheinen als vollständiger Klassenname einschließlich der Bundle-Kennung. In einer zukünftigen Version wird dies behoben, sodass der Bildschirmtitel in einen lesbareren Namen umformatiert wird. Als Zwischenlösung können Sie den Scan-Namen über das Dashboard oder Frameworks festlegen. (#1643)