Axe DevTools Mobile Versionshinweise 7. Oktober 2026

Beim Scannen eines Bildschirms mit großen oder komplexen Ansichtshierarchien kann der axeScan -Befehl länger als 60 Sekunden benötigen, um abgeschlossen zu werden. Appiums WebDriverAgent (WDA)-Proxy wendet ein Standardtimeout von 60 Sekunden auf unbekannte Befehle an, und axeScan fällt in diese Kategorie. Wenn der Scan innerhalb dieser Zeit nicht abgeschlossen ist, storniert WDA die Anforderung und der Test wirft einen Timeout-Fehler

Um das Pro-Befehl-Timeout für WDA-proxied Befehle wie axeScanzu überschreiben, empfehlen wir folgende Einstellungen in Ihren Appium-Eigenschaften:

• appium:commandTimeouts: 240000 (4 Minuten)
• appium:wdaConnectionTimeout: 30000 (5 Minuten)

Note: appium:newCommandTimeout is a different setting. It controls how long Appium waits between commands from the test script. That is not the cause of this issue. The relevant setting is appium:commandTimeouts

Wenn Sie Xcode 27 verwenden und eine Mobile Analyzer Desktop-App älter als Version 2.0.0 ausführen, kann die App den iOS-Simulator nicht öffnen. Es schlägt fehl, wenn versucht wird, /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app zu starten. Sie können keinen simulatorbasierten Scan starten, bis dies behoben ist.

Um Scans mit einem Simulator auf Xcode 27 durchzuführen, aktualisieren Sie den Desktop Analyzer auf Version 2.0.0+. Mit diesem Update beachten Sie bitte, dass die Barrierefreiheitsergebnisse jetzt in Axe Developer Hubzu finden sind.

Das Axe DevTools SDK verwendet Apples Vision-Framework, um Text auf dem Bildschirm für verschiedene Barrierefreiheits-Regeln zu lesen (z. B. Farbkontrast, sich überschneidende Ansichten, jede Regel, die von Vision-erkanntem Text abhängt).

Vision gibt nicht immer den gleichen erkannten Text bei Läufen desselben Bildschirms zurück. Wenn Vision den Text auf einem Kontrollfeld nicht erkennt, werden Regeln, die von diesem Text abhängen, nicht für dieses Element in diesem Scan ausgeführt. Ergebnisse können zwischen zwei Scans desselben Bildschirms inkonsistent erscheinen - ein Problem, das bei einem Scan fehlschlägt, kann beim nächsten fehlen.

Wenn eine Vision-basierte Regel einen Fehler meldet, ist der Fehler selbst zutreffend. Die Inkonsistenz liegt darin, ob die Regel ausgeführt wird oder nicht. Um dieses Problem zu überwinden, versuchen Sie Folgendes:

• Führen Sie den Scan erneut aus. Wenn eine Vision-basierte Regel für ein Kontrollfeld übersprungen wurde, erfasst ein weiterer Scan desselben Bildschirms dies oft.
• Behandeln Sie jeden Fehler bei Vision-basierten Regeln als gültig - wenn der Farbkontrast ein Kontrollfeld kennzeichnet, ist das Kontrastproblem real und sollte behoben werden.
• Für die manuelle Überprüfung verwenden Sie die Deque University-Referenz für das entsprechende WCAG-Erfolgskriterium. (Links finden sich am unteren Ende jeder Regel-Seite.)

Auf iOS 26 und später kann die Supports Dynamic Type-Regel als unvollständig gemeldet werden, wenn ein Bildschirm Text mit einem Prozentzeichen enthält (z. B. ein Textlabel, das "50% Rabatt" liest), anstatt bestehen oder fehlschlagen. Diese Regel verlässt sich auf einen von Apple bereitgestellten Barrierefreiheitstest, der den Testlauf stoppt, wenn er auf Prozentzeichen trifft. Um Ihre Tests fortsetzen zu können, überspringt unsere Regel die Überprüfung für diesen Bildschirm und meldet unvollständige Ergebnisse für jedes Element, das ein Prozentzeichen enthält. Alle anderen Regeln laufen normal auf dem Bildschirm, und andere Bildschirme sind nicht betroffen.

Es ist keine Aktion erforderlich, da Ihr Scan dennoch abgeschlossen wird. Um die Unterstützung für dynamische Schriftarten auf diesen Bildschirmen zu überprüfen, erhöhen Sie die Schriftgröße auf Ihrem Gerät unter **Einstellungen** > **Barrierefreiheit** > **Anzeige & Textgröße** > **Großer Text**, und bestätigen Sie, dass der Text auf dem Bildschirm entsprechend skaliert. Dieses Problem wurde an Apple gemeldet. (#2985)

Die Farbkontrastregel verwendet Apples Vision-Framework (Optical Character Recognition, oder OCR), um Text innerhalb der Grenzen eines Elements zu lesen. OCR kann gelegentlich kleine symbolsähnliche Glyphen - wie Rückpfeil-Chevrons (<), Aufzählungszeichen, dekorative Symbole - fälschlicherweise als Text erkennen. Wenn das passiert, wird die Farbkontrastregel auf ein Element angewendet, das keinen lesbaren Text enthält, was zu einem Ergebnis für einen Symbol-Button führen kann. Da OCR-Ausgaben nicht deterministisch über Scans hinweg sind, kann dasselbe Element in einem Scan in den Ergebnissen für den Farbkontrast erscheinen und im nächsten als „NICHT ANWENDBAR“ gemeldet werden. Dies ist ein bekanntes Merkmal 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.

Flutter ordnet AppBar.title nicht 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 Plattform-Einschränkung von Flutter, die in flutter/flutter#185894zu finden sind.

Bei der Durchführung von Barrierefreiheitsprüfungen auf kleineren Bildschirmgrößen oder mit kleineren Schriftgrößen kann die Farbkontrastregel falsch positive Ergebnisse für Farbverlaufshintergründe melden. In solchen Fällen kann sie nicht die Vordergrundfarbe bestimmen und stattdessen die 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 sich 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, auch wenn die Webansicht von nativen Overlays (wie modalen Ansichten, Warnungen oder anderen nativen UI-Elementen) überlagert wird. Dies tritt auf, weil das Barrierefreiheitssystem überprüft, ob der WKWebView-Container selbst sichtbar ist, anstatt ob seine Webinhalte tatsächlich nicht verdeckt und für den Benutzer wahrnehmbar sind.

iOS 26 enthält einen Barrierefreiheit Bug, bei dem Standardschritt-Schaltflächen von unterstützenden Technologien nicht als "gedimmt" angekündigt werden, um anzuzeigen, dass sie nicht aktiviert sind. Infolgedessen sehen auch die iOS-Regeln diese Schaltflächen als aktiviert, obwohl sie es nicht sind. Ein Fehlerbericht wurde bei Apple eingereicht, aber bis dies behoben ist, können die folgenden Regeln Ergebnisse auf deaktivierten Stepper-Tasten melden: AssociatedText, InaccessibleAction, und ColorContrastzu finden sind.

Bis Apple diesen Fehler behebt, wird die Lösung darin bestehen, [die Regeln zu ignorieren](ios-ignore-rule). Die Standardschritt-Schaltflächen tragen die Bezeichnungen "Decrement" und "Increment" und können bei Bedarf nach 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 fälschlicherweise positiv melden mit LabelInName und LabelAtFront aufgrund einer falschen associatedText Eigenschaft, die gefunden wird (#1622)

Während wir eine Verbesserung für unsere Regeln untersuchten, stellten wir fest, dass in XCTest verschachtelte Bedienelemente 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 von Apple zur Überprüfung der Fokussierbarkeit verwenden, können ungenau sein, wenn ein `accessibilityIdentifier` für das Bild festgelegt ist. Aufgrund dieses unerwarteten Verhaltens werden Ergebnisse für ImageView Namensprobleme in UIKit-Apps als „Überprüfung erforderlich“ gemeldet. Ein Fehlerbericht wurde bei Apple eingereicht. (#1633)

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

In Scroll View
Text innerhalb von bannerartig verhaltenden Elementen, klebrigen Kopf- und Fußzeilen, Floating-Action-Buttons und benutzerdefinierten Tab-Ansichten kann mit einer "Überprüfung erforderlich"- oder "Fehlgeschlagen"-Meldung markiert werden. Um diese Elemente für Benutzer verfügbar zu machen, die größere Texte benötigen, verwenden Sie UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Wenn ein UIImageView ein accessibilityIdentifier festgelegt hat, aber von VoiceOver nicht fokussierbar ist und es fokussierbare Bedienelemente innerhalb davon gibt, kann Active Control Name fälschlicherweise auf dem UIImageView gemeldet werden. Das Entfernen des accessibilityIdentifier behebt das Problem. Ein Fehler wurde bei Apple gemeldet. (#1633)

Label In Name and Label At Front
Diese beiden Regeln suchen nach einem sichtbaren Label eines Steuerelements unter den nahegelegenen Elementen, um den Regelstatus zu bestimmen. In einigen Ansichts-Hierarchien kann der falsche nahegelegene Text erkannt werden, was dazu führt, dass diese Regeln fehlschlagen. (#1622)

Die Label at Front-Regel überprüft, dass das sichtbare Label eines Elements am Anfang seines angesagten Textes steht. Ein Regelverstoß kann auftreten, wenn der sichtbare Text eines interaktiven Elements eine Abkürzung (z. B. „GB“, „km“) oder einen verdeckten / abgeschnittenen Bezeichner enthält und die Barrierefreiheitsankündigung aus den dargestellten Wörtern besteht (z. B. „Gigabytes“, „Kilometer“), obwohl dies das empfohlene Muster ist, um abgekürzte oder abgeschnittene Inhalte screenreaderfreundlich zu machen.

Wenn der erste Teil des sichtbaren Labels eines interaktiven Elements mit dem Anfang der Screenreader-Ankündigung übereinstimmt und nur der abgekürzte / verdeckte Teil unterschiedlich ist, kann das markierte Ergebnis sicher ignoriert werden. Überprüfen Sie mit einem Screenreader, dass die vollständige Ankündigung wie beabsichtigt lautet.

Wenn Sie dekorativen Text in Ansichten wie „Kontakt-Symbole“ verwenden, ist es möglich, ein Barrierefreiheitsproblem einzuführen. Wenn Sie eine Textansicht verwenden, um Buchstaben anzuzeigen, anstatt Bilder mit den gewünschten Buchstaben als Vektoren zu erstellen, und Sie dann diese Textansicht 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 versehentlich viele Ein-Wort-Tasten in verschiedenen Sprachen ignorieren (z. B. „OK“, „No“, „Sí“). Um diese Probleme zu vermeiden, sollten Sie die gewünschten Buchstaben aus dem Wort greifen, das Sie im Symbol darstellen möchten, und die Buchstaben als Teil des Bildes erstellen, anstatt als separate Textansichten. `FocusableText` wird dann nicht auf diesen Ansichten ausgeführt.

Flutter ordnet AppBar.title nicht der nativen Bildschirmtitel-Eigenschaft 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 Plattform-Einschränkung von Flutter, die in flutter/flutter#185894zu finden sind.

In einigen Fällen verlässt sich assistive Technologie auf AccessibilityEvent Beschreibungen des Android-Systems, um dem Nutzer Informationen bereitzustellen, 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. Dadurch kann TalkBack die Informationen von der Ansicht abrufen, die unser Tool dann erkennen kann.

Unsere Farbkontrastregel hängt von maschinellem Lernen ab, um Text zu erkennen, was sicherstellt, dass der gescannte Text für Benutzer Ihrer Anwendung sichtbar ist. In Fällen, in denen der Text in einer Ansicht dieselbe Farbe wie der Hintergrund hat, kann unser maschineller Lernalgorithmus nicht erkennen, ob überhaupt Text vorhanden ist, sodass die Farbkontrastregel nicht auf dieser Ansicht ausgeführt wird.

Apps, die mit XML geschrieben wurden und das Hinweistext-Feature verwenden, könnten Fehlalarme bei der EditTextName -Regel sehen. Der Hinweistext wurde erst mit Android 8 (SDK 26) eingeführt. Die Verwendung dieses Elements in Ihrer XML-App weist dem Text-Eingabefeld den Wert des Hinweistextes zu. Neuere Versionen von Android sind besser ausgestattet, um diese Erfahrung zugänglich zu machen.

Um dieses Problem zu überwinden, ist unsere erste Empfehlung, Ihre Tests auf neueren Android-Versionen durchzuführen. Wenn es jedoch wichtig ist, dass die App auf älteren Android-Versionen zugänglich ist, sollten Sie erwägen, die Verwendung des hintText -Features zu vermeiden, da es nicht offiziell unterstützt wird.

Sie könnten Ergebnisse für Ansichten sehen, die sich hinter anderen Ansichten auf dem Bildschirm verbergen. Diese versteckten Ansichten sind für assistive 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 zu gewährleisten.

Die ML Kit-Texterkennung ist in vielen 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 erfolgt der automatische Import jedoch nicht, und Sie sehen den folgenden Fehler im Logcat:

Die Regel zum Touch-Zielabstand wird derzeit bei keinen Schiebereglern, die in Jetpack Compose erstellt wurden, überprüft. Derzeit sind keine Maßnahmen erforderlich. Es kommt jedoch bald eine Lösung!

Unter Android API 30 tritt ein Berechtigungsfehler an einem der Orte 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 Sie den Code im folgenden Block auskommentieren:

In einigen Hybrid- und plattformübergreifenden Apps können unerwartete Ergebnisse auftreten, wenn sich Elemente in einer Scroll-View teilweise außerhalb des Bildschirms befinden. 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 diese Funktion wegen der Sicherheitsverbesserungen nutzen möchten, empfehlen wir, sie für interne Test-Builds deaktiviert zu lassen, bei denen Sie sicher Testdaten verwenden und Sicherheitsbedenken auf diese Weise 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) auf den betroffenen Aktivitätsfenstern. setHideOverlayWindows(false)

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 an für die Aktivierung von Screenshots in Android-Apps.

Wenn Sie Ihren Build minimieren, wird ein Absturz mit einem Fehlerprotokoll gemeldet, das angibt, dass ein Adapter nicht gefunden wurde, als versucht wurde, die Axe DevTools-Bibliothek zu laden. Deaktivieren Sie das Minifizieren für Ihre Debug-Builds mit implementierten Axe DevTools. (#729)

Ein Build mit aktiviertem r8 könnte versuchen, die axeDevTools-Bibliothek zu minimieren, was zu einem Fehler führt, der wie folgt aussieht:

Die Compose-APIs sind veraltet, bitte verwenden Sie die layout-agnostischen APIs, um weiterhin Updates zu erhalten. Wenn Sie die Compose-APIs weiter nutzen und auf einen Fehler stoßen, der in der Richtung von `Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)` oder `No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?` geht, beachten Sie bitte die Compose setTestTag APIzu finden sind.

Aufgrund von Einschränkungen der MAUI-App-Architektur im Android-Ökosystem wird die Regel für den Textnamen als „Überprüfung erforderlich“ im Dashboard 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 Steuerelemente nicht erweitern, können Ergebnisse für Ansichten hinter dem Modalfenster auftreten. In diesem Fall empfehlen wir, unser Tool nicht gegen diese benutzerdefinierten Modals oder Dialoge auszuführen und stattdessen diese manuell zu überprüfen, um sicherzustellen, dass sie wie gewünscht mit assistiver Technologie funktionieren.

Wenn der Screenshot auf der Scan-Detailseite fehlt, könnte Ihre App verhindern, dass Screenshots aufgenommen werden. Oft geschieht dies aus Sicherheitsgründen in Ihrer Produktionsanwendung. Erwägen Sie, 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-Scannamen, die standardmäßig auf den Bildschirmtitel gesetzt sind, werden als vollständiger Klassenname einschließlich des Bundle-Identifiers angezeigt. In einer zukünftigen Version wird dies behoben, sodass der Bildschirmtitel in einen lesbareren Namen formatiert wird. Als Workaround können Sie den Scannamen vom Dashboard oder über Frameworks festlegen. (#1643)