Axe DevTools Mobile Version vom 2. Juli 2026 – Versionshinweise

Die Farbkontrastregel verwendet das Vision-Framework von Apple (Optische Zeichenerkennung, oder OCR), um Text innerhalb der Grenzen eines Elements zu lesen. OCR kann gelegentlich kleinformatige, symbolartige Glyphen - wie Rückwärtspfeil-Häkchen (<), Aufzählungszeichen, dekorative Symbole - als Text fehlidentifizieren. Wenn das passiert, wird die Farbkontrastregel auf ein Element angewendet, das keinen lesbaren Text enthält, was zu einem Ergebnis für eine nur aus Icons bestehende Schaltfläche führen kann. Da die OCR-Ausgabe nicht deterministisch über Scans hinweg ist, 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 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 AppBar.title nicht der nativen Bildschirmtitel-Eigenschaft zu - UIViewController.title, wodurch die Regel für den Bildschirmtitel bei 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 verfolgt wird..

Bei der Durchführung von Barrierefreiheitsprüfungen auf kleineren Bildschirmgrößen oder mit kleineren Schriftgrößen kann die Regel für den Farbkontrast bei Verlaufs-Hintergründen Falschmeldungen anzeigen. In solchen Fällen ist es möglicherweise nicht möglich, die Vordergrundfarbe zu bestimmen, und stattdessen werden die 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 entscheiden, die Regel in Ihren Tests zu ignorieren und den Farbkontrast manuell für diese Ansichten zu ü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 liegt daran, dass das Barrierefreiheitssystem prüft, ob der WKWebView-Container selbst sichtbar ist, anstatt ob dessen Webinhalte tatsächlich ungehindert und für den Benutzer wahrnehmbar sind.

iOS 26 enthält einen Barrierefreiheitsfehler, bei dem standardmäßige Schrittschalter-Schaltflächen nicht als "gedimmt" von unterstützenden Technologien angekündigt werden, um anzuzeigen, dass sie nicht aktiviert sind. Infolgedessen sehen die iOS-Regeln diese Schaltflächen auch als aktiviert an, auch wenn sie es nicht sind. Ein Fehlerbericht wurde bei Apple eingereicht, aber bis dieses Problem behoben ist, können die folgenden Regeln Ergebnisse für deaktivierte Schrittschalter-Schaltflächen melden: AssociatedText, InaccessibleAction, und ColorContrast.

Bis Apple diesen Fehler behebt, besteht die Lösung darin, [die Regeln zu ignorieren](ios-ignore-rule). Die standardmäßigen Schrittschalter-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 aufgrund einer inkorrekten zugeordneten Text-Eigenschaft (#1622) Falschmeldungen mit LabelInName und LabelAtFront melden

Es gibt ein Problem, das den iPhone 15 Pro Simulator betrifft und verhindert, dass die Regel für Unterstützung dynamischer Typen ausgeführt wird. Wenn Sie für die Regel zur Unterstützung dynamischer Typen angemeldet sind, können Sie sie nicht mit einem iPhone 15 Pro Simulator testen. Ein Fehlerbericht wurde bei Apple eingereicht.

Während wir an einer Verbesserung unserer Regeln arbeiteten, stellten wir fest, dass in XCTest geschachtelte Steuerelemente nicht im Barrierefreiheitsbaum zurückgegeben werden. Ein Fehlerbericht wurde bei Apple eingereicht. (#1110)

In UIKit-Apps ist ein Bild ohne `accessibilityLabel` standardmäßig nicht mit unterstützenden Technologien fokussierbar.
Die von uns verwendeten Eigenschaften zur Überprüfung der Fokussierbarkeit von Apple können ungenau sein, wenn auf dem Bild ein `accessibilityIdentifier` gesetzt ist. Aufgrund dieses unerwarteten Verhaltens werden 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 Lösungen für die folgenden Falschmeldungen und werden diese Liste aktualisieren, sobald Lösungen veröffentlicht werden.

In Scroll View
Text innerhalb von bannerähnlichen Elementen kann mit einer „Überprüfung erforderlich“-Nachricht gekennzeichnet sein. 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 ein `accessibilityIdentifier` gesetzt hat, aber nicht durch VoiceOver fokussierbar ist und fokussierbare Steuerelemente darin geschachtelt sind, kann ActiveControlName eine Falschmeldung auf dem UIImageView anzeigen. 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 der sichtbaren Bezeichnung eines Steuerelements in der Nähe befindlicher Elemente, um den Status der Regel zu bestimmen. In einigen Ansichten-Hierarchien kann der falsche nahegelegene Text erkannt werden, was dazu führt, dass diese Regeln fehlschlagen. (#1622)

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

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

Flutter ordnet AppBar.title nicht der nativen Eigenschaft für Bildschirmtitel zu - Activity.setTitle, wodurch die Regel für den Bildschirmtitel bei 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#185894.

In einigen Fällen verlässt sich die unterstützende Technologie auf AccessibilityEvent Beschreibungen aus dem Android-System, um den Benutzern Informationen anzukündigen, wenn keine andere Ankündigung verfügbar ist. Da AccessibilityEventdurch Benutzeraktionen ausgelöst werden, können wir nicht auf die richtige 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 Barrierefreiheit markiert sind. Dies ermöglicht es Talkback, auf die Informationen aus der Ansicht zuzugreifen, die dann von unserem Tool erkannt werden können.

Unsere Regel für Farbkontrast basiert auf maschinellem Lernen zur Texterkennung, was sicherstellt, dass der gescannte Text für die Nutzer Ihrer Anwendung sichtbar ist. Wenn der Text in einer Ansicht die gleiche Farbe wie der Hintergrund hat, kann unser Algorithmus für maschinelles Lernen nicht erkennen, ob Text vorhanden ist, sodass die Farbkontrastregel in dieser Ansicht nicht ausgeführt wird.

Apps, die mit XML geschrieben sind und die Hinweistext-Funktion nutzen, könnten mit der EditTextName Regel falsche positive Ergebnisse erhalten. 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 darauf vorbereitet, diese Erfahrung barrierefrei zu gestalten.

Um dieses Problem zu lösen, empfehlen wir zunächst, Ihre Tests auf neueren Android-Versionen durchzuführen. Wenn es jedoch wichtig ist, dass die App auf älteren Android-Versionen barrierefrei ist, sollten Sie die Nutzung der hintText Funktion vermeiden, da sie nicht offiziell unterstützt wird.

Sie könnten Ergebnisse für Ansichten sehen, die hinter anderen Ansichten auf dem Bildschirm versteckt sind. 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 können Sie, wenn TalkBack diese Ansichten nicht erreichen kann, die entsprechenden Probleme ignorieren. Sie erfordern keine Behebung, um Barrierefreiheit sicherzustellen.

ML Kit-Texterkennung ist in vielen der axe DevTools Mobile-Regeln erforderlich, um die Genauigkeit der Ergebnisse sicherzustellen. Die ML Kit-Bibliothek sollte automatisch importiert werden, wenn Sie in Ihren automatisierten Espresso- oder UIAutomator-Tests auf axe DevTools Mobile verweisen. In einigen Fällen erfolgt 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 lösen, 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:

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

Die Regel für den Abstand der Berührungsziele wird derzeit bei keinen Schiebereglern ausgeführt, die in Jetpack Compose geschrieben wurden. Derzeit kann keine Maßnahme ergriffen werden. Eine Lösung wird jedoch bald verfügbar sein!

Auf Android API 30 hat einer der Orte, an denen wir versuchen, Ergebnisse lokal zu speichern, einen Berechtigungsfehler. Das Ergebnis wird dennoch als JSON-Datei gespeichert, obwohl dieser Fehler angezeigt wird. Der Fehler kann durch Auskommentieren des Codes im folgenden Block unterdrückt werden:

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 Scroll-Ansicht teilweise vom Bildschirm verdeckt 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. Wenn Sie sich dazu entschieden haben, diese Funktion aufgrund ihrer Sicherheitsverbesserungen zu nutzen, empfehlen wir, sie für interne Testversionen ausgeschaltet zu lassen, wo Sie sicher Testdaten nutzen und Sicherheitsbedenken so ausschließen 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 an.

Wenn Sie Ihr Build minimieren, sehen Sie einen Absturz mit einem Fehlerprotokoll, das meldet, dass ein Adapter beim Versuch, sich in die axe DevTools-Bibliothek einzuloggen, nicht gefunden werden konnte. Deaktivieren Sie Minify 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 weiter, um weiterhin Updates zu erhalten. Wenn Sie weiterhin die Compose-APIs verwenden und auf einen Fehler stoßen wie `Erwartet genau '1' Knoten, aber '2' Knoten gefunden, die die Voraussetzung erfüllen: (istRoot)` oder `Kein View initialisiert, haben Sie AxeDevToolsCompose.setComposeTestRule() aufgerufen?`, beziehen Sie sich bitte auf Compose setTestTag API.

Aufgrund von Einschränkungen der MAUI-App-Architektur in der Android-Ökosystem-Darstellung 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 bestätigen Sie in diesem Fall das korrekte Verhalten manuell.

Wenn Sie eigene 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 eigenen Modale oder Dialoge laufen zu lassen, sondern stattdessen manuell zu überprüfen, ob sie sich mit unterstützender Technologie wie gewünscht verhalten.

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 Ihre Testbuilds zu entfernen, um die volle Funktionalität im axe DevTools Mobile Dashboard zu ermöglichen.

• Android - FLAG_SECURE

Einige Android-Scannamen, die standardmäßig auf den Bildschirmtitel gesetzt sind, erscheinen als vollständiger Klassenname einschließlich des Bundle-Kennzeichens. In einer zukünftigen Version wird dieses Problem behoben, sodass der Bildschirmtitel in einen leserlicheren Namen formatiert wird. Als Umgehungslösung können Sie den Scannamen über das Dashboard oder Frameworks festlegen. (#1643)