Axe DevTools Mobile Versionshinweise zum 30. Juni 2026

Die Farbkontrasregel verwendet Apples Vision-Framework (Optical Character Recognition, oder OCR), um Text innerhalb der Grenzen eines Elements zu lesen. OCR kann gelegentlich kleine symbolähnliche Glyphen - wie Rückpfeil-Klammern (<), Aufzählungszeichen, dekorative Symbole - als Text falsch identifizieren. Wenn dies geschieht, wird die Farbkontrasregel auf einem Element ausgeführt, das keinen lesbaren Text enthält, was zu einem Ergebnis für einen nur aus Symbolen bestehenden Button führen kann. Da OCR-Ergebnisse bei verschiedenen Scans nicht deterministisch sind, kann dasselbe Element in einem Scan in den Ergebnissen der Farbkontrasregel 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 Bildschirmtitelleistes-Eigenschaft zu - UIViewController.title, was dazu führt, dass die Bildschirmüberschriftregel auf allen Flutter-Bildschirmen fehlschlägt, unabhängig davon, ob ein beschreibender Titel vorhanden ist oder nicht.

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

Beim Ausführen von Barrierefreiheitsprüfungen auf kleineren Bildschirmgrößen oder mit kleineren Schriftgrößen kann die Farbkontrasregel falsche Positive für Farbverläufe melden. In solchen Fällen kann sie möglicherweise die Vordergrundfarbe nicht bestimmen und stattdessen Hintergrundfarben miteinander vergleichen, 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 Web-Inhalte in WKWebView fälschlicherweise als „isVisible“ melden, selbst wenn die Webansicht von nativen Überlagerungen (wie modalen Ansichten, Warnungen oder anderen nativen UI-Elementen) verdeckt ist. Dies geschieht, weil das Barrierefreiheits-System überprüft, ob der WKWebView-Container selbst sichtbar ist, anstatt ob sein Web-Inhalt tatsächlich ungehindert und für den Benutzer wahrnehmbar ist.

iOS 26 enthält einen Barrierefreiheitsfehler, bei dem Standard-Stepper-Schaltflächen nicht als „gedimmt“ durch assistive Technologie angekündigt werden, um anzuzeigen, dass sie nicht aktiviert sind. Infolgedessen sehen die iOS-Regeln diese Schaltflächen ebenfalls als aktiviert an, selbst wenn sie es nicht sind. Ein Fehlerbericht wurde bei Apple eingereicht, aber bis dies behoben ist, können die folgenden Regeln Ergebnisse für deaktivierte Stepper-Schaltflächen melden: AssociatedText, InaccessibleActionund ColorContrast.

Bis Apple diesen Fehler behebt, besteht die Lösung darin, die [Regeln zu ignorieren](ios-ignore-rule). Die Standard-Steuertasten 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 fehlerhaften associatedText-Eigenschaft (#1622) Falsch-Positiv-Meldungen bei LabelInName und LabelAtFront anzeigen.

Es gibt ein Problem, das den iPhone 15 Pro Simulator betrifft und die Ausführung der Unterstützt Dynamische Schriftart Regel verhindert. Wenn Sie sich für die Regel zur Unterstützung dynamischer Schriftarten entschieden haben, können Sie diese nicht mit einem iPhone 15 Pro Simulator testen. Ein Fehlerbericht wurde bei Apple eingereicht.

Beim Prüfen einer Verbesserung unserer Regeln haben wir festgestellt, dass in XCTest verschachtelte Steuerelemente nicht im Accessibility-Baum zurückgegeben werden. Ein Fehlerbericht wurde bei Apple eingereicht. (#1110)

In UIKit-Apps ist ein Bild ohne `accessibilityLabel` standardmäßig nicht mit assistiver 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 bei Apple eingereicht. (#1633)

Wir arbeiten aktiv an der Behebung der folgenden Falsch-Positiv-Meldungen und werden diese Liste aktualisieren, sobald Korrekturen vorliegen.

In Scroll View
Text innerhalb von banner-verhaltenden Elementen kann mit einer „Überprüfung erforderlich“ Nachricht gekennzeichnet werden. Um diese Elemente für Nutzer, die größere Schriftarten benötigen, verfügbar zu machen, verwenden Sie UILargeContentViewer. (#622)

v2.11.0 Image View Name & Active Control Name
Wenn ein UIImageView ein `accessibilityIdentifier` gesetzt hat, aber nicht von VoiceOver fokussierbar ist und es fokussierbare Steuerelemente enthält, kann ActiveControlName ein Falsch-Positiv für das 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 das sichtbare Label eines Steuerelements 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)

Bei der Verwendung von dekorativem Text in Ansichten wie „Kontakticons“ kann ein Barrierefreiheitsproblem entstehen. Wenn Sie ein Textfeld verwenden, um Buchstaben anzuzeigen, anstatt Bilder mit den gewünschten Buchstaben als Vektoren zu erzeugen, und Sie dieses Textfeld dann für die Barrierefreiheit als unwichtig deklarieren, können wir nicht zuverlässig feststellen, ob Sie eine Barrierefreiheitsverletzung eingeführt haben.

Wenn Sie fokussierbaren Text so bearbeiten, dass Sie zwei oder weniger Zeichen ignorieren, könnten Sie unbeabsichtigt 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, das Sie im Icon darstellen möchten, entnehmen und die Buchstaben als Teil des Bildes generieren, anstatt als separate Textansichten. `FocusableText` wird dann nicht auf diesen Ansichten ausgeführt.

Flutter weist AppBar.title der nativen Eigenschaft für Bildschirmlabels nicht zu - Activity.setTitle, 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 verfolgt wird unter flutter/flutter#185894.

In einigen Fällen verlässt sich assistive Technologie auf AccessibilityEvent Beschreibungen durch das Android-System, um Informationen an den Benutzer anzukündigen, wenn keine andere Ankündigung verfügbar ist. Da AccessibilityEvente durch Benutzeraktionen ausgelöst werden, können wir die richtige Beschreibung nicht abrufen, wenn diese Informationen nicht bereitgestellt werden.

Um dieses Problem zu vermeiden, stellen Sie sicher, dass alle relevanten Ansichten als barrierefrei wichtig gekennzeichnet sind. Dies ermöglicht TalkBack, auf die Informationen der Ansicht zuzugreifen, die unser Tool dann erkennen kann.

Unsere Farbkontrastregel stützt sich auf maschinelles Lernen zur Erkennung von Text, 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, und daher wird die Farbkontrastregel auf dieser Ansicht nicht ausgeführt.

Apps, die mit XML geschrieben sind und die Hinweistextfunktion nutzen, können unter Umständen Falschmeldungen mit der EditTextName Regel sehen. Hinweistext wurde erst mit Android 8 (SDK 26) eingeführt. Die Verwendung dieses Elements in Ihrer XML-App weist dem Eingabefeld den Wert des Hinweistextes zu. Neuere Versionen von Android sind besser geeignet, um dieses Erlebnis zugänglicher zu machen.

Um dieses Problem zu überwinden, empfehlen wir, 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 Verwendung des hintText Features vermeiden, 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 assistive Technologien 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 Lösung, um die Barrierefreiheit sicherzustellen.

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

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

Um dieses Problem zu beheben, sollten Sie die ML Kit-Bibliothek manuell in Ihr Projekt importieren. In der Datei Ihrer Anwendung build.gradle fügen Sie Folgendes unter Abhängigkeiten hinzu:

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

Die Regel für den Abstand von Touch-Zielen wird derzeit nicht bei Schiebereglern angewendet, die mit Jetpack Compose geschrieben wurden. Derzeit kann keine Maßnahme ergriffen werden. Jedoch ist eine Lösung in Kürze verfügbar!

Auf Android API 30 besteht an einem der Orte, an denen wir versuchen, die Ergebnisse lokal zu speichern, ein Berechtigungsfehler. Das Ergebnis wird trotz der angezeigten Fehlermeldung weiterhin als JSON-Datei gespeichert. Der Fehler kann unterdrückt werden, indem der folgende Codeblock 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 wir unerwartete Ergebnisse erhalten, wenn Elemente in einer Scrollansicht teilweise außerhalb des Bildschirms liegen. 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 wegen ihrer Sicherheitsverbesserungen verwenden, empfehlen wir, sie für interne Testbuilds deaktiviert zu lassen, in denen Sie sicher Testdaten verwenden können, um so Sicherheitsbedenken auszuschalten. 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) auf den betroffenen Aktivitätsfenstern. setHideOverlayWindows(false) , um weiterhin Updates zu erhalten. Wenn Sie weiterhin die Compose-APIs verwenden und auf einen Fehler stoßen, der sagt `Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)` oder `No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?`, verweisen Sie bitte auf

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 mit Mock-Daten arbeitet, um Sicherheitsbedenken zu vermeiden. Schauen Sie sich unseren Leitfaden für das Aktivieren von Screenshots in Android-Apps an.

Wenn Sie Ihren Build optimieren, sehen Sie einen Absturz mit einem Fehlerprotokoll, das besagt, dass ein Adapter beim Versuch, sich in die axe DevTools-Bibliothek einzuloggen, nicht gefunden werden konnte. Deaktivieren Sie die Minifizierung für Ihre Debug-Builds mit implementierten axe DevTools. (#729)

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

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 layoutunabhängigen APIs , um weiterhin Updates zu erhalten. Wenn Sie weiterhin die Compose-APIs verwenden und auf einen Fehler stoßen, der sagt `Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)` oder `No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?`, verweisen Sie bitte auf compose setTestTag API.

Aufgrund von Einschränkungen der MAUI-App-Architektur im Android-Ökosystem wird die Regel für Edit-Text-Namen im Dashboard als Überprüfung erforderlich angezeigt, wenn für die SDK-Version 5.5.0 und höher ein Fehler vermutet wird. Bitte bestätigen Sie das korrekte Verhalten manuell für diesen Fall.

Wenn Sie benutzerdefinierte Dialoge oder Modale implementieren, die nicht die nativen Steuerelemente 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, sondern sie stattdessen manuell zu überprüfen, um sicherzustellen, dass sie mit assistiver Technologie wie gewünscht funktionieren.

Wenn der Screenshot auf der Scan-Details-Seite fehlt, kann Ihre App verhindern, dass Screenshots gemacht werden. Oft liegt dies an Sicherheitsgründen in Ihrer Produktionsanwendung. Erwägen Sie, diese Anforderung für Ihren Testbuild aufzuheben, 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 besser lesbaren Namen formatiert wird. Als Workaround können Sie den Scan-Namen vom Dashboard oder den Frameworks aus festlegen. (#1643)