Axe DevTools Mobile – Veröffentlichungshinweise 8. September 2026

Dieser Status ist veraltet und wird im Oktober 2026 entfernt. Zu diesem Zeitpunkt werden ignorierte Regeln bei der Iteration übersprungen und es wird kein Ergebnis mehr zurückgegeben.

Beachten Sie, dass AxeDevTools itself nicht veraltet ist. Die folgenden Methoden werden in der Oktober 2026-Veröffentlichung ersetzt oder vollständig entfernt.

• ignoreByViewIdResourceName(viewIdResourceName: String, ruleList: List) (Wird ersetzt durch ignoreRulesOnElementWithId(id: String, vararg rules: AxeRuleName))
• ignoreRules(rulesToIgnore: List)
• resetIgnoredRules()
• tagScansAs(tag: TagSet)
• deleteResult(axeDevToolsResultKey: AxeDevToolsResultKey)
• getResult(axeDevToolsResultKey: AxeDevToolsResultKey)

• getResult()
• postResult()
• deleteResult()
• tag()
• setScanName()
• getUserInfo()
• getResultSync()
• postResultSync()
• deleteResultSync()
• tagSync()
• setScanNameSync()
• getSessionId()
• BASE_FRONTEND_URL
• DB_DEFAULT_URL
• DB_QA_URL
• DB_DEV_URL

Das Konzept der experimentellen Regeln wird in der Oktober-Veröffentlichung vollständig entfernt. Dasselbe gilt für Tags - sie werden mit der Stilllegung des Mobile Dashboards verschwinden.

Diese Regeln waren experimentell und werden nicht gefördert. Sie wurden aus unserer Regeliteration entfernt.

• AxeDevToolsResultKey
• AxeDevToolsResultSummaryResponse
• ConnectionConfig - Dies wird ersetzt durch dbUrl Einzelargument-Konstruktor
• class TagsSet()
• Experimentelle Regeln werden gefördert oder entfernt

Das Axe DevTools SDK verwendet Apples Vision-Framework, um Text auf dem Bildschirm für mehrere Barrierefreiheitsregeln zu lesen (z. B. Farbkontrast, sich überlappende Ansichten, jede Regel, die auf Vision-erkannten Text angewiesen ist).

Vision liefert nicht immer den gleichen erkannten Text zwischen zwei Durchläufen des gleichen Bildschirms. Wenn Vision den Text bei einem Steuerelement verpasst, werden die auf diesen Text angewiesenen Regeln bei diesem Element in diesem Scan nicht ausgeführt. Die Ergebnisse können zwischen zwei Scans des gleichen Bildschirms inkonsistent erscheinen - ein Problem, das bei einem Scan fehlschlägt, kann beim nächsten fehlen.

Wenn eine auf Vision-basierte Regel einen Fehler meldet, ist der Fehler selbst genau. 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 auf Vision-basierte Regel bei einem Steuerelement übersprungen wurde, erfasst ein weiterer Scan desselben Bildschirms sie oft.
• Behandeln Sie jeden Fehler einer auf Vision-basierenden Regel als valide - wenn Farbkontrast bei einem Steuerelement ein Problem meldet, ist das Kontrastproblem real und sollte behoben werden.
• Verwenden Sie für eine manuelle Überprüfung das Deque University-Referenzdokument für das relevante WCAG-Erfolgskriterium. (Links finden Sie unten auf jeder Regel-Seite.)

Auf iOS 26 und später, wenn ein Bildschirm Text mit einem Prozentzeichen enthält (z. B. ein Textlabel mit der Aufschrift „50% Rabatt“), kann die Regel Unterstützt Dynamische Schriftgröße als unvollständig statt als bestanden oder fehlgeschlagen gemeldet werden. Diese Regel verlässt sich auf ein Barrierefreiheitsaudit, das von Apple bereitgestellt wird, und dieses Audit stoppt die Testdurchführung, wenn es auf Prozentzeichen stößt. Um Ihre Tests weiterzufü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 werden auf dem Bildschirm normal ausgeführt, und andere Bildschirme sind nicht betroffen.

Es sind keine Maßnahmen erforderlich, da Ihr Scan dennoch abgeschlossen wird. Um den Dynamischen Schriftartensupport 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 wird. Dieses Problem wurde an Apple gemeldet. (#2985)

Die Farbkontrastregel verwendet Apples Vision-Framework (Optical Character Recognition, oder OCR), um Texte innerhalb der Grenzen eines Elements zu lesen. OCR kann gelegentlich kleine symbolartige Glyphen - wie Zurück-Pfeil-Chevrons (<), Aufzählungszeichen, dekorative Symbole - fälschlicherweise als Text erkennen. Wenn dies geschieht, wird die Farbkontrastregel auf ein Element angewendet, das keinen lesbaren Text enthält, was ein Ergebnis für eine nur mit Symbolen versehene Schaltfläche erzeugen kann. Weil OCR-Ausgaben nicht deterministisch über Scans hinweg sind, kann dasselbe Element in einem Scan in den Ergebnissen für Farbkontrast erscheinen und im nächsten als „NICHT ANWENDBAR“ gemeldet werden. Dies ist eine bekannte Eigenschaft 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 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.

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

Bei der Durchführung von Barrierefreiheitsprüfungen bei kleineren Bildschirmgrößen oder mit kleineren Schriftgrößen kann die Farbkontrastregel bei Verlaufs-Hintergründen Falschmeldungen ausgeben. In solchen Fällen kann es sein, dass die Vordergrundfarbe nicht bestimmt werden kann und stattdessen die Hintergrundfarben miteinander verglichen werden, was zu einem Fehler führt.

Um dieses Problem zu umgehen, versuchen Sie, die Barrierefreiheitsprüfungen auf größeren Geräten durchzuführen. Alternativ können Sie in Ihren Tests die Regel ignorieren und den Farbkontrast manuell für diese Ansichten ü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) überlagert wird. Dies geschieht, weil das Barrierefreiheitssystem prüft, ob der WKWebView-Container selbst sichtbar ist, anstatt ob der Webinhalt tatsächlich ungehindert und für den Benutzer wahrnehmbar ist.

iOS 26 enthält einen Barrierefreiheitsfehler, bei dem Standardschaltflächen der Stepper von unterstützender Technologie nicht als „gedimmt“ angekündigt werden, um anzuzeigen, dass sie nicht aktiviert sind. Aufgrund dessen sehen die iOS-Regeln diese Schaltflächen auch als aktiviert an, selbst wenn sie es nicht sind. Ein Fehlerbericht wurde bei Apple eingereicht, aber bis dieser behoben ist, können die folgenden Regeln Ergebnisse für deaktivierte Stepper-Schaltflächen melden: AssociatedText, InaccessibleAction, und ColorContrast.

Bis Apple diesen Fehler behebt, ist die Lösung, die [Regeln zu ignorieren](ios-ignore-rule). Die Standardschaltflächen der Stepper 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 Falschmeldungen mit LabelInName und LabelAtFront aufgrund einer inkorrekt gefundenen associatedText-Eigenschaft melden (#1622)

Bei der Betrachtung einer Verbesserung für unsere Regeln haben wir festgestellt, dass in XCTest geschachtelte Steuerungen nicht im Barrierefreiheitsbaum zurückgegeben werden. Ein Fehler wurde bei Apple eingereicht. (#1110)

In UIKit-Apps ist ein Bild ohne `accessibilityLabel` standardmäßig nicht mit unterstützender Technologie fokussierbar.
Die Eigenschaften, die wir von Apple verwenden, um die Fokussierbarkeit zu überprüfen, können ungenau sein, wenn ein `accessibilityIdentifier` auf dem Bild 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 Korrekturen für die folgenden Falschmeldungen und werden diese Liste aktualisieren, sobald Korrekturen veröffentlicht werden.

In Scroll View
Text innerhalb von bannenverhaltenden Elementen, Sticky-Headern/-Fußzeilen, schwebenden Aktionsschaltflächen und benutzerdefinierten Tab-Ansichten kann mit einer „Überprüfung erforderlich“- oder „Fehlermeldung“ markiert werden. Um diese Elemente denjenigen zugänglich zu machen, die größere Texte benötigen, verwenden Sie UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Wenn eine UIImageView ein accessibilityIdentifier gesetzt hat, aber nicht durch VoiceOver fokussierbar ist, und es fokussierbare Steuerelemente innerhalb hat, kann Active Control Name eine Falschmeldung auf der UIImageView melden. Entfernen des accessibilityIdentifier löst das Problem. Ein Fehler wurde bei Apple eingereicht. (#1633)

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

Die Regel Label vorne überprüft, ob das sichtbare Label eines Elements am Anfang 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 / abgeschnittenen Bezeichner enthält und die Barrierefreiheitsansage die dargestellten Wörter (z. B. „Gigabytes“, „Kilometer“) umfasst, obwohl dies für die Bildschirmleserfreundlichkeit von abgekürztem oder abgeschnittenem Inhalt das empfohlene Muster ist.

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

Bei der Verwendung von dekorativem Text in Ansichten wie „Kontaktsymbole“ 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 generieren, und Sie diese Textansicht dann als nicht wichtig für Barrierefreiheit deklarieren, können wir nicht zuverlässig feststellen, ob Sie eine Verletzung der Barrierefreiheit eingeführt haben.

Wenn Sie fokussierbaren Text bearbeiten, um zwei oder weniger Zeichen zu ignorieren, können Sie versehentlich 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 Symbol darstellen möchten, und die Buchstaben als Teil des Bildes und nicht als separate Textansichten generieren. `FocusableText` wird dann nicht auf diesen 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.

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

In einigen Fällen verlässt sich unterstützende Technologie auf AccessibilityEvent Beschreibungen aus dem Android-System, um Informationen an den Benutzer zu übermitteln, wenn keine andere Ankündigung verfügbar ist. Da AccessibilityEventdurch Benutzeraktionen ausgelöst werden, können wir nicht auf die korrekte Beschreibung zugreifen, wenn diese Informationen nicht bereitgestellt werden.

Um dieses Problem zu vermeiden, stellen Sie sicher, dass alle relevanten Ansichten als wichtig für Barrierefreiheit markiert sind. Dadurch kann Talkback die Informationen aus der Ansicht abrufen, die unser Tool dann erkennen kann.

Unsere Farbkontrastregel beruht auf maschinellem Lernen, um Text zu erkennen, was sicherstellt, dass der gescannte Text für die Benutzer Ihrer Anwendung sichtbar ist. In Fällen, in denen der im View enthaltene Text die gleiche Farbe wie der Hintergrund hat, kann unser maschinelles Lernalgorithmus nicht erkennen, ob Text vorhanden ist, sodass die Farbkontrastregel für diesen View nicht ausgeführt wird.

Apps, die mit XML geschrieben wurden und die Hinweistextfunktion nutzen, können Falschmeldungen mit der EditTextName Regel sehen. Der 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 darauf vorbereitet, diese Erfahrung barrierefrei zu machen.

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 die Verwendung der Funktion vermeiden, da sie nicht offiziell unterstützt wird. hintText Funktion, da sie nicht offiziell unterstützt wird.

Sie können Ergebnisse für Ansichten sehen, die hinter anderen Ansichten auf dem Bildschirm versteckt sind. Diese versteckten Ansichten sind für unterstützende Technologien nicht verfügbar, aber Axe DevTools Mobile meldet sie immer noch 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 Korrektur, um Barrierefreiheit sicherzustellen.

Die ML Kit Texterkennung wird in vielen der Axe DevTools Mobile-Regeln benötigt, 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 Regel für Touch Target-Abstände wird derzeit bei keinem der Slider-Komponenten ausgeführt, die in Jetpack Compose geschrieben wurden. Derzeit können keine Maßnahmen ergriffen werden. Ein Fix ist jedoch bald verfügbar!

Auf Android API 30 gibt es einen Berechtigungsfehler an einem der Speicherorte, an dem wir versuchen, Ergebnisse lokal zu speichern. Das Ergebnis wird dennoch als JSON-Datei gespeichert, auch wenn 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 Elemente in einer Scroll-Ansicht teilweise außerhalb des Bildschirms liegen. Um ein Element auf Barrierefreiheit zu testen, stellen Sie sicher, dass es vollständig auf dem Bildschirm angezeigt wird, bevor Sie den Scan durchführen.

Mit API 31 (Android 12) wurde die Möglichkeit eingeführt, nicht-systemübergreifende Overlays zu verbergen. Um die Axe Analyzer-App nutzen zu können, stellen Sie 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 Test-Builds deaktiviert zu lassen, bei denen Sie sicher mit Testdaten arbeiten können und so Sicherheitsbedenken 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 setHideOverlayWindows(false) in den betroffenen Aktivitätsfenstern.

Um die volle Funktionalität der Axe DevTools für Mobile freizuschalten, sorgen Sie dafür, dass Screenshots aktiviert sind. Wir empfehlen, Screenshots in einer Debug- oder Test-Version Ihrer App zu aktivieren, die mit Mock-Daten arbeitet, um Sicherheitsbedenken zu vermeiden. Sehen Sie sich unser Handbuch für das Aktivieren von Screenshots in Android-Apps

Wenn Sie Ihren Build minifizieren, sehen Sie einen Absturz mit einer Fehlermeldung, dass ein Adapter nicht gefunden werden konnte, wenn Sie versuchen, sich in die Axe DevTools-Bibliothek einzuloggen. Deaktivieren Sie das Minifizieren für Ihre Debug-Builds mit implementierten Axe DevTools. (#729)

Ein Build mit aktiviertem r8 versucht möglicherweise, die axeDevTools-Bibliothek zu minifizieren, was zu einem Fehler ähnlich dem folgenden führt:

Die Compose APIs sind veraltet, bitte verwenden Sie die layouts-agnostischen APIs , um weiterhin Updates zu erhalten. Wenn Sie die Compose APIs weiterhin verwenden und auf einen Fehler stoßen, der etwa lautet: `Genau '1' Knoten erwartet, aber '2' Knoten gefunden, die die Bedingung: (isRoot) erfüllen` 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 im Android-Ökosystem wird die Edit Text Name-Regel 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 keine nativen Steuerelemente erweitern, können Ergebnisse für Ansichten hinter dem Modal angezeigt werden. In diesem Fall empfehlen wir, unser Tool nicht gegen diese benutzerdefinierten Modale oder Dialoge laufen zu lassen und stattdessen manuell zu überprüfen, ob sie mit unterstützender Technologie wie gewünscht funktionieren.

Wenn der Screenshot auf der Scan-Detailseite fehlt, könnte Ihre App das Aufnehmen von Screenshots verhindern. Dies geschieht oft aus Sicherheitsgründen in Ihrer Produktionsanwendung. Erwägen Sie, diese Anforderung für Ihren 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, werden als vollständiger Klassenname einschließlich der Bundle-ID angezeigt. 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 aus den Frameworks heraus setzen. (#1643)