Axe DevTools Mobile Versionshinweise vom 23. Oktober 2026

Beim Scannen eines Bildschirms mit großen oder komplexen Ansichtshierarchien kann der axeScan Befehl länger als 60 Sekunden dauern. Appiums WebDriverAgent (WDA) Proxy wendet bei unbekannten Befehlen ein Standard-Timeout von 60 Sekunden an, und axeScan fällt in diese Kategorie. Wenn der Scan innerhalb dieser Zeit nicht abgeschlossen wird, storniert WDA die Anforderung und der Test wirft einen Timeout-Fehler.

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 Version 2.0.0 ausführen, kann die App den iOS-Simulator nicht öffnen. Es schlägt fehl, wenn es versucht, /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app zu starten. Sie können keinen simulatorbasierten Scan durchführen, 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 jetzt im Axe Developer Hub.

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

Vision liefert nicht immer den gleichen erkannten Text bei wiederholten Durchläufen des gleichen Bildschirms. Wenn Vision den Text auf einem Steuerelement nicht erkennt, werden Regeln, die auf diesem Text basieren, bei diesem Scan nicht für das Element ausgeführt. Die Ergebnisse können zwischen zwei Scans des gleichen Bildschirms inkonsistent erscheinen – ein Problem, das bei einem Scan auftritt, kann beim nächsten fehlen.

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

• Wiederholen Sie den Scan. Wenn eine Vision-basierte Regel für ein Steuerelement übersprungen wurde, wird sie bei einem weiteren Scan des gleichen Bildschirms häufig erkannt.
• Behandeln Sie jeden Vision-basierten Regelverstoß als gültig - wenn der Farbkontrast ein Steuerelement 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 Sie unten auf jeder Regelseite.)

Auf 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 Unterstützt-Dynamische-Schriftart-Regel als unvollständig gemeldet werden, anstatt bestanden oder fehlgeschlagen. Diese Regel hängt von einem Barrierefreiheits-Audit ab, das von Apple bereitgestellt wird, und dieses Audit unterbricht den testrun, wenn es auf Prozentzeichen trifft. Um Ihre Tests fortzusetzen, ü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 werden normal auf dem Bildschirm ausgeführt, und andere Bildschirme sind nicht betroffen.

Es sind keine Maßnahmen erforderlich, da Ihr Scan dennoch abgeschlossen wird. Um die Unterstützung dynamischer Schriftarten für diese Bildschirme zu überprüfen, erhöhen Sie die Textgröße auf Ihrem Gerät unter **Einstellungen** > **Bedienungshilfen** > **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 symbolähnliche Glyphen - wie Rückwärtspfeil-Chevrons (<), Aufzählungszeichen, dekorative Symbole - fälschlicherweise als Text erkennen. Wenn das passiert, läuft die Farbkontrastregel auf einem Element, das keinen lesbaren Text enthält, was ein Ergebnis für einen nur aus Symbolen bestehenden Button liefern kann. Da die OCR-Ausgabe zwischen Scans nicht deterministisch ist, kann dasselbe Element in den Farbkontrastergebnissen eines Scans 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.

Flutter ordnet nicht AppBar.title 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 oder nicht.

Dies ist eine bekannte Plattformbeschränkung von Flutter, die verfolgt wird unter flutter/flutter#185894.

Bei der Durchführung von Barrierefreiheitstests auf kleineren Bildschirmgrößen oder mit kleineren Schriftgrößen kann die Farbkontrastregel falsch positive Ergebnisse für Verlaufs-Hintergründe melden. In solchen Fällen kann es sein, dass sie die Vordergrundfarbe nicht bestimmen kann und stattdessen Hintergrundfarben miteinander vergleicht, was zu einem Fehler führt.

Um dieses Problem zu umgehen, versuchen Sie, Barrierefreiheitstests 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 in WKWebView möglicherweise fälschlicherweise als "isVisible" melden, selbst wenn die Webansicht durch native Überlagerungen (wie modale Ansichten, Warnungen oder andere native UI-Elemente) verdeckt wird. Dies geschieht, weil das Barrierefreiheitssystem überprüft, ob der WKWebView-Container selbst sichtbar ist, und nicht, ob sein Webinhalt tatsächlich ungehindert und für den Benutzer wahrnehmbar ist.

iOS 26 enthält einen Barrierefreiheitsfehler, bei dem standardmäßige Schrittmacher-Tasten nicht "abgedunkelt" von unterstützender Technologie ankündigen, um anzuzeigen, dass sie nicht aktiviert sind. Infolgedessen sehen auch die iOS-Regeln diese Tasten als aktiviert, selbst 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 Schrittmacher-Tasten 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 Schrittmacher-Tasten haben die Kennungen "Decrement" und "Increment" und können bei Bedarf nach Kennung 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 Meldungen mit LabelInName und LabelAtFront aufgrund einer falschen associatedText Eigenschaft gemeldet werden (#1622)

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

In UIKit-Apps ist ein Bild ohne `accessibilityLabel` standardmäßig nicht mit assistiven Technologien fokussierbar.
Die von uns verwendeten Eigenschaften zur Überprüfung der Fokussierbarkeit von Apple sind möglicherweise ungenau, 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 Lösungen für die folgenden falsch positiven Meldungen und werden diese Liste aktualisieren, sobald Lösungen veröffentlicht werden.

In Scroll View
Text innerhalb von bannerverhaltenden Elementen, festen Kopf- und Fußzeilen, schwebenden Aktionsbuttons und benutzerdefinierten Tab-Ansichten kann mit einer Nachricht "Überprüfung erforderlich" oder "Fehlgeschlagen" 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
Wenn ein UIImageView ein accessibilityIdentifier gesetzt hat, aber nicht durch VoiceOver fokussierbar ist und fokussierbare Steuerelemente darin verschachtelt sind, kann der Active Control Name unter Umständen einen falsch-positiven Bericht für das UIImageView liefern. 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 Label eines Steuerelements unter nahegelegenen Elementen, um den Status der Regel zu ermitteln. In einigen Ansichts-Hierarchien kann der falsche nahegelegene Text erkannt werden, was zu Fehlern bei diesen Regeln führen kann. (#1622)

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

Beachten Sie, dass dies rein ein Talkback-Fehler ist, der es nicht erlaubte, FABs, die in Accessibility-Overlays gerendert wurden, durch Wischen den Fokus zu gewinnen oder zu verlieren. Das jüngste Upgrade unserer Accessibility Analyzer App ermöglicht das Scannen von mehr Arten von Apps; daher können Sie dieses Problem möglicherweise jetzt erst bemerken.

Dieses Problem kann behoben werden, indem Talkback auf Version 16.2 oder höher aktualisiert wird.

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

Wenn der erste Teil des sichtbaren Labels eines interaktiven Elements mit dem Beginn der Screenreader-Ansage übereinstimmt und nur der abgekürzte/verdeckte Teil abweicht, kann das markierte Ergebnis sicher ignoriert werden. Überprüfen Sie mit einem Screenreader, dass die vollständige Ansage wie beabsichtigt vorgelesen wird.

Bei der Verwendung von dekorativem Text in Ansichten wie „Kontakt-Icons“ kann ein Barrierefreiheitsproblem auftreten. Wenn Sie eine Textansicht verwenden, um Buchstaben anzuzeigen, anstatt Bilder mit den gewünschten Buchstaben als Vektoren zu generieren, und Sie dann erklären, dass diese Textansicht für Barrierefreiheit nicht wichtig ist, 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 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 entnehmen, das Sie im Icon darstellen möchten, und die Buchstaben als Teil des Bildes generieren, anstatt als separate Textansichten. `FocusableText` wird dann nicht auf diese Ansichten ausgeführt.

Flutter ordnet nicht AppBar.title 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 oder nicht.

Dies ist eine bekannte Plattformbeschränkung von Flutter, die verfolgt wird unter flutter/flutter#185894.

In einigen Fällen verlassen sich unterstützende Technologien auf AccessibilityEvent Beschreibungen des Android-Systems, um Informationen an den Benutzer anzukündigen, wenn keine andere Ansage verfügbar ist. Da AccessibilityEvente durch Benutzeraktionen ausgelöst werden, können wir die richtige Beschreibung nicht erhalten, 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 aus der Ansicht abrufen, die unser Tool dann erkennen kann.

Unsere Farbkontrastregel ist von maschinellem Lernen abhängig, um Text zu erkennen, was sicherstellt, dass der gescannte Text für die Nutzer Ihrer Anwendung sichtbar ist. In Fällen, in denen der in einer Ansicht enthaltene Text die gleiche Farbe wie der Hintergrund hat, kann unser maschinelles Lernalgorithmen nicht erkennen, ob überhaupt Text vorhanden ist, sodass die Farbkontrastregel für diese Ansicht nicht ausgeführt wird.

Apps, die mit XML geschrieben wurden und die Hinweistextfunktion nutzen, können Fehlalarme mit der EditTextName -Regel sehen. 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 Versionen von Android sind besser ausgestattet, um dieses Erlebnis barrierefrei zu gestalten.

Um dieses Problem zu überwinden, ist unsere erste Empfehlung, Ihre Tests auf neueren Versionen von Android auszuführen. Wenn es jedoch wichtig ist, dass die App auf älteren Android-Versionen barrierefrei ist, sollten Sie in Betracht ziehen, die Verwendung der hintText -Funktion zu vermeiden, da sie nicht offiziell unterstützt wird.

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

Die ML Kit Texterkennung wird in vielen der von Axe DevTools Mobile verwendeten Regeln benötigt, um die Genauigkeit der Ergebnisse sicherzustellen. Die ML Kit-Bibliothek sollte automatisch importiert werden, wenn Sie Axe DevTools Mobile in Ihre automatisierten Espresso- oder UIAutomator-Tests integrieren. In einigen Fällen jedoch erfolgt der automatische Import nicht und Sie sehen den folgenden Fehler im Logcat:

Die Touch-Target-Abstandsregel wird derzeit nicht auf Slider-Komponenten angewendet, die in Jetpack Compose geschrieben wurden. Derzeit sind keine Maßnahmen erforderlich. Eine Lösung ist jedoch bald verfügbar!

Unter Android API 30 gibt es einen Berechtigungsfehler bei einem der Speicherorte, an dem 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 auftreten, 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 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 bitte sicher, dass diese Einstellung nicht aktiviert ist. Wenn Sie sich entschieden haben, diese Funktion aufgrund ihrer Sicherheitsverbesserungen zu nutzen, empfehlen wir, sie für interne Testbuilds deaktiviert zu lassen, in denen Sie sicher Testdaten verwenden können und Sicherheitsbedenken auf diese Weise 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 nutzen, aktualisieren Sie alle Aufrufe der Methode setHideOverlayWindows(true) auf den betroffenen Aktivitätsfenstern. setHideOverlayWindows(false) Screenshot fehlt (schwarzes Feld) im Dashboard

Aktivierung von Screenshots in Android-Apps an. enabling screenshots in Android apps.

Wenn Sie Ihr Build minimieren, sehen Sie einen Absturz mit einem Fehlerprotokoll, das berichtet, dass ein Adapter nicht gefunden werden konnte, als versucht wurde, sich bei der Axe DevTools-Bibliothek anzumelden. Deaktivieren Sie die Minimierung 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 ähnlich dem folgenden führt:

Die Compose APIs sind veraltet, bitte verwenden Sie die layoutsagnostischen APIs , um weiterhin Updates zu erhalten. Wenn Sie weiterhin die Compose APIs verwenden und auf einen Fehler stoßen, der etwa so lautet: `Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)` oder `No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?`, beziehen Sie sich bitte auf Compose setTestTag API.

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

Wenn Sie benutzerdefinierte 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 benutzerdefinierten Modale oder Dialoge auszuführen, sondern sie stattdessen manuell zu überprüfen, um sicherzustellen, dass sie mit unterstützender Technologie wie gewünscht arbeiten.

Wenn der Screenshot auf der Scan-Detailseite fehlt, kann es sein, dass Ihre App verhindert, dass Screenshots gemacht werden. Häufig geschieht dies aus Sicherheitsgründen in Ihrer Produktionsanwendung. Überlegen Sie, diese Anforderung in Ihrem Test-Build 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 auf den Bildschirmtitel gesetzt sind, erscheinen als vollständiger Klassenname einschließlich des Paketbezeichners. In einer zukünftigen Version wird dies behoben, sodass der Bildschirmtitel in einen besser lesbaren Namen formatiert wird. Als Umgehungslösung können Sie den Scan-Namen vom Dashboard oder aus den Frameworks einstellen. (#1643)