Axe DevTools Mobile Versionshinweise zum 23. Oktober 2026

Beim Scannen eines Bildschirms mit großen oder komplexen Ansichten kann der axeScan Befehl länger als 60 Sekunden zur Ausführung benötigen. Der WebDriverAgent (WDA) Proxy von Appium hat ein 60-Sekunden-Timeout für unbekannte Befehle, und axeScan fällt in diese Kategorie. Wenn der Scan innerhalb dieser Zeit nicht abgeschlossen ist, beendet WDA die Anforderung und der Test löst einen Timeout-Fehler aus

Um das Timeout pro Befehl für WDA-proxied Befehle wie axeScanzu überschreiben, empfehlen wir die folgenden Einstellungen in Ihren Appium-Fähigkeiten:

• 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 auf Xcode 27 sind und eine Mobile Analyzer Desktop-App älter als 2.0.0 ausführen, kann die App den iOS-Simulator nicht öffnen. Sie scheitert, wenn sie versucht zu starten /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app Sie können keinen simulatorbasierten Scan starten, bis dies gelöst 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 nun in Axe Developer Hub.

Das Axe DevTools SDK verwendet das Vision-Framework von Apple, um Text auf dem Bildschirm für mehrere Barrierefreiheitsregeln zu erfassen (z. B. Farbkontrast, sich überschneidende Ansichten, jede Regel, die von durch Vision erfasstem Text abhängt).

Vision liefert nicht immer denselben erkannten Text bei mehreren Durchläufen desselben Bildschirms. Wenn Vision den Text auf einem Steuerelement nicht erkennt, werden Regeln, die auf diesem Text basieren, bei diesem Element nicht ausgeführt. Die Ergebnisse können zwischen zwei Überprüfungen desselben Bildschirms inkonsistent erscheinen – ein Problem, das bei einer Überprüfung fehlschlägt, könnte bei der nächsten nicht vorhanden sein.

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

• Führen Sie die Überprüfung erneut durch. Wenn eine Vision-basierte Regel bei einem Steuerelement übersprungen wurde, wird sie bei einer weiteren Überprüfung desselben Bildschirms häufig erkannt.
• Betrachten Sie jeden Fehler einer Vision-basierten Regel als gültig – wenn der Farbkontrast ein Steuerelement markiert, ist das Kontrastproblem real und sollte behoben werden.
• Für eine manuelle Überprüfung verwenden Sie die Deque University-Referenz für das relevante WCAG-Erfolgskriterium. (Links finden Sie am Ende jeder Regelseite.)

Ab iOS 26 und höher, wenn ein Bildschirm Text mit einem Prozentzeichen enthält (z. B. ein Textlabel mit der Aufschrift „50 % Rabatt“), kann die Supports Dynamic Type-Regel als Unvollständig statt als bestanden oder fehlgeschlagen gemeldet werden. Diese Regel basiert auf einer von Apple bereitgestellten Barrierefreiheitsprüfung, und diese Prüfung stoppt den Testlauf, wenn sie auf Prozentzeichen stößt. Um Ihre Tests fortzuführen, überspringt unsere Regel die Überprüfung für diesen Bildschirm und meldet unvollständig für jedes Element, das ein Prozentzeichen enthält. Alle anderen Regeln laufen normal auf dem Bildschirm, und andere Bildschirme sind nicht betroffen.

Es sind keine Maßnahmen erforderlich, da Ihr Scan dennoch abgeschlossen wird. Um die Unterstützung für Dynamic Type auf diesen Bildschirmen zu überprüfen, vergrößern Sie die Textgröße auf Ihrem Gerät unter **Einstellungen** > **Bedienungshilfen** > **Anzeige & Textgröße** > **Textgröße** und bestätigen Sie, dass der Text auf dem Bildschirm entsprechend skaliert wird. Dieses Problem wurde Apple gemeldet. (#2985)

Die Farbkontrastregel verwendet das Vision-Framework von Apple (Optische Zeichenerkennung oder OCR), um Text innerhalb der Grenzen eines Elements zu erfassen. OCR kann gelegentlich kleine symbolartige Glyphen – wie zurückpfeilförmige Chevron-Symbole (<), Kennzeichen, dekorative Symbole – fälschlicherweise als Text identifizieren. Wenn dies passiert, wird die Farbkontrastregel auf einem Element ausgeführt, das keinen lesbaren Text enthält, was zu einem Ergebnis für eine Schaltfläche, die nur aus Symbolen besteht, führen kann. Da das OCR-Ergebnis bei mehreren Überprüfungen nicht deterministisch ist, kann dasselbe Element in einem Scan im Farbkontrastergebnis 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 die Farbkontrastergebnisse für die betroffenen Elemente zu unterdrücken.

Flutter ordnet AppBar.title nicht der nativen Eigenschaft für den Bildschirmtitel zu - UIViewController.title, was dazu führt, dass die Bildschirmtitelregel 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.

Bei der Durchführung von Barrierefreiheitsprüfungen auf kleineren Bildschirmgrößen oder mit kleineren Schriftgrößen kann die Farbkontrastregel falsch positive Ergebnisse für Verlaufsfarben melden. In solchen Fällen kann sie möglicherweise die Vordergrundfarbe nicht bestimmen und vergleicht stattdessen Hintergrundfarben miteinander, 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 Überlagerungen (wie modalen Ansichten, Warnmeldungen oder anderen nativen UI-Elementen) überdeckt wird. Dies geschieht, weil das Barrierefreiheitssystem überprüft, ob der WKWebView-Container selbst sichtbar ist, anstatt ob sein Webinhalt tatsächlich ungehindert und wahrnehmbar für den Benutzer ist.

iOS 26 enthält einen Barrierefreiheitsbug, bei dem Standardschieberegler-Schaltflächen nicht durch Assistive Technology als „gedimmt“ angekündigt werden, um anzuzeigen, dass sie nicht aktiviert sind. Daher 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 behoben ist, können die folgenden Regeln Ergebnisse auf deaktivierten Schieberegler-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 Standardschieberegler-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 falsch positive Ergebnisse mit LabelInName und LabelAtFront aufgrund einer falschen associatedText Property geliefert (#1622)

Während der Betrachtung einer Verbesserung unserer Regeln haben wir festgestellt, dass in XCTest verschachtelte Steuerelemente nicht im Barrierefreiheitsbaum zurückgegeben werden. Ein Fehlerbericht wurde bei Apple eingereicht. (#1110)

In UIKit-Apps kann ein Bild ohne `accessibilityLabel` standardmäßig nicht mit unterstützender Technologie fokussiert werden.
Die Eigenschaften, die wir von Apple verwenden, um die Fokussierbarkeit zu überprüfen, können ungenau sein, wenn ein `accessibilityIdentifier` auf das Bild gesetzt ist. Aufgrund dieses unerwarteten Verhaltens werden die Ergebnisse für ImageView-Namensprobleme in UIKit-Apps als "Muss geprüft werden" 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 bannerartigen Elementen, festen Kopf-/Fußzeilen, schwebenden Aktionsschaltflächen und benutzerdefinierten Tab-Ansichten kann mit einer "Muss geprüft werden"- oder "Fehler"-Meldung markiert werden. Um diese Elemente für diejenigen verfügbar zu machen, die größere Texte benötigen, verwenden Sie UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Falls eine UIImageView ein accessibilityIdentifier gesetzt hat, aber nicht durch VoiceOver fokussierbar ist und sie fokussierbare Steuerelemente enthält, die darin verschachtelt sind, kann der aktive Steuerungsname möglicherweise ein falsches Positiv auf der UIImageView melden. Das Entfernen des accessibilityIdentifier behebt das Problem. Ein Fehlerbericht wurde bei Apple eingereicht. (#1633)

Label In Name and Label At Front
Diese beiden Regeln suchen nach dem sichtbaren Etikett eines Steuerelements bei nahen Elementen, um den Status der Regel zu bestimmen. In einigen Ansichtenhierarchien kann der falsche nahe Text erkannt werden, wodurch diese Regeln fehlschlagen. (#1622)

Der Floating Action Button (FAB) des Android Accessibility Analyzers ist nicht kompatibel mit der Wischnavigation von Talkback in Talkback-Versionen älter als 16.2. Mit der Veröffentlichung von Version 16.2 hat Talkback einen Fehler in ihrem Code behoben, um den Wischfokus für Overlay-FABs zu erlauben.

Bitte beachten Sie, dass dies ein reiner Talkback-Fehler ist, der nicht erlaubte, dass FABs in Accessibility-Overlays durch Wischen Fokus erhalten oder verlieren. Das kürzliche Upgrade unserer Accessibility Analyzer App ermöglicht das Scannen weiterer App-Typen; daher könnte Ihnen dieses Problem erst jetzt auffallen.

Dieses Problem kann durch ein Update von Talkback auf Version 16.2 oder höher behoben werden.

Die Regel 'Label at Front' überprüft, ob das sichtbare Etikett eines Elements am Beginn seines angekündigten Textes steht. Ein Regelverstoß kann auftreten, wenn der sichtbare Text eines interaktiven Elements eine Abkürzung (z. B. „GB“, „km“) oder einen verdeckten/verkürzten Bezeichner enthält und die Barrierefreiheitsankündigung aus den dargestellten Wörtern (z. B. „Gigabytes“, „Kilometer“) besteht, obwohl dies das empfohlene Muster ist, um abgekürzte oder verkürzte Inhalte für Bildschirmleser benutzerfreundlich zu gestalten.

Wenn der erste Teil des sichtbaren Etiketts eines interaktiven Elements mit dem Beginn der Bildschirmleser-Ankündigung übereinstimmt und nur der abgekürzte/verdeckte Teil abweicht, kann das geflaggte Ergebnis sicher ignoriert werden. Verifizieren Sie mit einem Bildschirmleser, dass die vollständige Ankündigung wie beabsichtigt gelesen wird.

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

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

Flutter ordnet AppBar.title nicht der nativen Eigenschaft für den Bildschirmtitel zu - Activity.setTitle, was dazu führt, dass die Bildschirmtitelregel 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 vom Android-System, um Informationen an den Benutzer zu übermitteln, wenn keine andere Ankündigung verfügbar ist. Da AccessibilityEvente durch Benutzeraktionen ausgelöst werden, können wir auf die richtige Beschreibung nicht zugreifen, wenn diese Information nicht bereitgestellt wird.

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 die Benutzer Ihrer Anwendung sichtbar ist. In Fällen, in denen der Text in einer Ansicht dieselbe Farbe wie der Hintergrund hat, kann unser maschinelles Lernverfahren nicht erkennen, ob Text vorhanden ist, sodass die Farbkontrastregel für diese Ansicht nicht ausgeführt wird.

Apps, die mit XML geschrieben wurden und die Funktion für Hinweistexte nutzen, können falsch positive Ergebnisse mit der EditTextName Regel sehen. Hinweistexte wurden erst mit Android 8 (SDK 26) eingeführt. Die Verwendung dieses Elements in Ihrer XML-App weist dem Textinput-Feld den Wert des Hinweises zu. Neuere Android-Versionen sind besser gerüstet, um dieses Erlebnis barrierefrei zu gestalten.

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

Es können Ergebnisse für Ansichten angezeigt werden, die hinter anderen Ansichten auf dem Bildschirm verborgen sind. Diese versteckten Ansichten stehen unterstützenden Technologien nicht zur Verfügung, werden aber von Axe DevTools Mobile dennoch als Probleme berichtet.

Wir arbeiten an einer Lösung für dieses komplexe Problem. In der Zwischenzeit können Sie die entsprechenden Probleme ignorieren, wenn TalkBack diese Ansichten nicht erreichen kann. Sie müssen nicht behoben werden, um die Barrierefreiheit zu gewährleisten.

Die 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 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 Touch Target Abstandsregel wird derzeit auf keine Slider-Komponenten angewendet, die in Jetpack Compose geschrieben wurden. Derzeit kann keine Maßnahme ergriffen werden. Es ist jedoch bald eine Lösung in Sicht!

Auf Android API 30 besteht ein Berechtigungsfehler bei einem der Speicherorte, an denen wir versuchen, Ergebnisse lokal zu speichern. Das Ergebnis wird dennoch als JSON-Datei gespeichert, obwohl dieser Fehler angezeigt wird. Der Fehler kann unterdrückt werden, indem der Code im folgenden Block auskommentiert wird:

In einigen Hybrid- und plattformübergreifenden Apps können unerwartete Ergebnisse zurückgegeben werden, 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. Wenn Sie sich entschieden haben, diese Funktion aus Sicherheitsgründen zu nutzen, empfehlen wir, sie für interne Testversionen, in denen Sie sicher mit Testdaten arbeiten können, ausgeschaltet zu lassen, um Sicherheitsbedenken auf diese Weise auszuräumen. 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 Mobilgeräte freizuschalten, stellen Sie sicher, dass Screenshots aktiviert sind. Wir empfehlen, Screenshots auf 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, tritt ein Absturz mit einem Fehlerprotokoll auf, das meldet, dass ein Adapter beim Versuch, sich in die Axe DevTools-Bibliothek einzuloggen, nicht gefunden werden konnte. Deaktivieren Sie die Minimierung für Ihre Debug-Builds, in denen Axe DevTools implementiert ist. (#729)

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

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 stoßen wie `Erwartet genau '1' Knoten, aber '2' Knoten gefunden, die übereinstimmen: (isRoot)` oder `Keine View initialisiert, haben Sie AxeDevToolsCompose.setComposeTestRule() aufgerufen?`, beziehen Sie sich bitte auf Compose setTestTag API.

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

Wenn Sie benutzerdefinierte Dialoge oder Modals implementieren, die die nativen Steuerungen nicht erweitern, können Ergebnisse für Ansichten hinter dem Modal angezeigt werden. In diesem Fall empfehlen wir, unser Tool nicht für diese benutzerdefinierten Modals oder Dialoge einzusetzen, 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, kann es sein, dass Ihre App Screenshots verhindert. Oft geschieht dies aus Sicherheitsgründen in Ihrer Produktionsanwendung. Erwägen Sie, diese Anforderung für Ihre Testversion zu entfernen, um 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 werden, erscheinen als vollständiger Klassenname einschließlich des Paketbezeichners. In einer zukünftigen Version wird dies behoben, sodass der Bildschirmtitel in einen lesbareren Namen formatiert wird. Als Workaround können Sie den Scan-Namen aus dem Dashboard oder den Frameworks setzen. (#1643)