Axe DevTools Mobile Versionshinweise August 5, 2026

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 Dynamic Type“ als unvollständig gemeldet werden, anstatt bestanden oder fehlgeschlagen anzuzeigen. Diese Regel stützt sich auf einen von Apple bereitgestellten Barrierefreiheitstest, und dieser Test unterbricht den Testlauf, wenn er auf Prozentzeichen trifft. Um Ihre Tests weiterlaufen zu lassen, überspringt unsere Regel die Überprüfung für diesen Bildschirm und meldet unvollständig für jedes Element mit einem Prozentzeichen. Alle anderen Regeln laufen normal auf dem Bildschirm, und andere Bildschirme sind nicht betroffen.

Es ist keine Aktion erforderlich, da Ihr Scan weiterhin abgeschlossen wird. Um die Unterstützung von Dynamic Type für diese Bildschirme zu überprüfen, vergrößern 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 Farbkontrastrege verwendet Apples Vision-Framework (Optical Character Recognition, oder OCR), um Text innerhalb der Grenzen eines Elements zu lesen. OCR kann gelegentlich kleine zeichenähnliche Symbole - wie etwa Pfeilzeichen (<), Aufzählungspunkte, dekorative Symbole - fälschlicherweise als Text erkennen. Wenn das passiert, wird die Farbkontrastrege auf ein Element angewendet, das keinen lesbaren Text enthält, was zu einem Ergebnis für eine Symbol-Button führen kann. Da die OCR-Ausgabe bei jedem Scan nicht deterministisch ist, kann dasselbe Element in einem Scan in den Ergebnissen der Farbkontrastrege 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 AppBar.title nicht der nativen Eigenschaft für Bildschirmtitel zu - UIViewController.title, was dazu führt, dass die Bildschirmitten-Regel 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#185894verfolgt wird.

Beim Ausführen von Barrierefreiheitsprüfungen auf kleineren Bildschirmen oder mit kleineren Schriftgrößen kann die Farbkontrastrege falsche Positive für Farbverlaufs-Hintergründe melden. In solchen Fällen kann es vorkommen, 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 die Regel in Ihren Tests ignorieren und den Farbkontrast für diese Ansichten manuell überprüfen.

Apples Barrierefreiheits-APIs können Web-Inhalte innerhalb von WKWebView fälschlicherweise als "isVisible" melden, selbst wenn die Webansicht von nativen Überlagerungen (wie modale Ansichten, Warnungen oder andere native UI-Elemente) verdeckt ist. Dies geschieht, weil das Barrierefreiheits-System überprüft, ob der WKWebView-Container selbst sichtbar ist, anstatt ob dessen Webinhalte tatsächlich ungehindert und für den Benutzer wahrnehmbar sind.

iOS 26 enthält einen Barrierefreiheitsfehler, bei dem standardmäßige Schrittschalter-Buttons nicht von Assistive Technology als „abgedunkelt“ angekündigt werden, um anzuzeigen, dass sie nicht aktiviert sind. Dadurch 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 gelöst ist, können die folgenden Regeln Ergebnisse für deaktivierte Schrittschalter-Buttons melden: AssociatedText, InaccessibleAction, und ColorContrast.

Bis Apple diesen Fehler behebt, wird die Lösung darin bestehen, die [Regeln zu ignorieren](ios-ignore-rule). Die Standard-Schaltflächen für Schrittschalter haben 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 aufgrund einer falsch gefundenen associatedText Eigenschaft (#1622) Falschmeldungen mit LabelInName und LabelAtFront verursachen.

Während wir unsere Regeln verbessern, haben wir festgestellt, dass in XCTest verschachtelte Steuerelemente nicht im Barrierefreiheitsbaum zurückgegeben werden. Ein Fehlerbericht 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 verwenden, um die Fokussierbarkeit von Apple zu überprüfen, können ungenau sein, wenn ein `accessibilityIdentifier` auf dem Bild festgelegt ist. Aufgrund dieses unerwarteten Verhaltens werden Ergebnisse für ImageView-Name-Probleme in UIKit-Apps als Überprüfung benötigt 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 sind.

In Scroll View
Text innerhalb von banner-ähnlichen Elementen, Sticky-Headers/Footers, schwebenden Aktionsschaltflächen und benutzerdefinierten Registerkartenansichten kann mit einer „Überprüfung benötigt“ oder „Fehlgeschlagen“ Nachricht markiert werden. Um diese Elemente für diejenigen verfügbar zu machen, die größere Textmengen benötigen, verwenden Sie UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Wenn ein UIImageView ein accessibilityIdentifier zugewiesen ist, aber nicht von VoiceOver fokussierbar ist und fokussierbare Steuerelemente innerhalb davon verschachtelt sind, könnte Active Control Name auf dem UIImageView fälschlicherweise positiv melden. Entfernen Sie den accessibilityIdentifier , um das Problem zu lösen. Ein Fehler wurde bei Apple eingereicht. (#1633)

Label In Name and Label At Front
Diese beiden Regeln suchen nach dem sichtbaren Label einer Steuerung in seiner Nähe, um den Status der Regel zu bestimmen. In einigen Ansichts-Hierarchien kann der falsche nahe Text erkannt werden, was dazu führt, dass diese Regeln fehlschlagen. (#1622)

Die Label-at-Front-Regel prüft, ob das sichtbare Label eines Elements am Anfang des verkündeten 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 vollständigen Wörtern (z.B. „Gigabytes“, „Kilometer“) besteht, obwohl dies das empfohlene Muster ist, um abgekürzten oder abgeschnittenen Inhalt bildschirmlesefreundlich zu gestalten.

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 abweicht, kann das markierte Ergebnis sicher ignoriert werden. Überprüfen Sie mit einem Screenreader, dass die vollständige Ankündigung wie beabsichtigt gelesen wird.

Beim Verwenden von dekorativen Texten in Ansichten wie „Kontakt-Icons“ 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 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 so bearbeiten, dass er zwei oder weniger Zeichen ignoriert, ignorieren Sie möglicherweise versehentlich viele einwortige Schaltflächen in verschiedenen Sprachen (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 statt als separate Textansichten generieren. `FocusableText` wird dann nicht auf diesen Ansichten ausgeführt.

Flutter ordnet nicht AppBar.title der nativen Bildschirmeigenschaft für Titel 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#185894verfolgt wird.

In einigen Fällen verlässt sich unterstützende Technologie auf AccessibilityEvent Beschreibungen des Android-Systems, um dem Benutzer Informationen anzukündigen, 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 die Barrierefreiheit markiert sind. Dies ermöglicht es Talkback, die Informationen aus der Ansicht abzurufen, die unser Tool dann erkennen kann.

Unsere Regel für Kontrast 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 die gleiche Farbe wie der Hintergrund hat, kann unser maschinelles Lernalgorithmus nicht feststellen, ob Text vorhanden ist, sodass die Kontrastregel in dieser Ansicht nicht ausgeführt wird.

Apps, die mit XML geschrieben sind und die Hinttext-Funktion nutzen, können Falschmeldungen mit der EditTextName Regel sehen. Der Hinttext wurde erst mit Android 8 (SDK 26) eingeführt. Die Verwendung dieses Elements in Ihrer XML-App weist dem Textfeld den Wert des Hinttexts zu. Neuere Versionen von Android sind besser darauf vorbereitet, diese Erfahrung zugänglicher 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 auch auf früheren Android-Versionen zugänglich ist, sollten Sie die Nutzung der hintText Funktion in Betracht ziehen, da sie nicht offiziell unterstützt wird.

Sie könnten Ergebnisse für Ansichten sehen, die hinter anderen Ansichten auf dem Bildschirm verborgen sind. Diese versteckten Ansichten sind für unterstützende Technologie nicht verfügbar, aber Axe DevTools Mobile meldet sie trotzdem 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 Behebung, um die Barrierefreiheit zu gewährleisten.

Die ML Kit Text Detection ist in vielen der Axe DevTools Mobile-Regeln erforderlich, um die Genauigkeit der Ergebnisse sicherzustellen. Die ML Kit-Bibliothek sollte beim Referenzieren von Axe DevTools Mobile in Ihren automatisierten Espresso- oder UIAutomator-Tests automatisch importiert werden. In einigen Fällen erfolgt der automatische Import jedoch nicht und Sie sehen den folgenden Fehler im Logcat:

Die Touch-Ziel-Abstandsregel wird derzeit nicht auf Schiebereglerkomponenten ausgeführt, die mit Jetpack Compose geschrieben wurden. Derzeit kann keine Maßnahme ergriffen werden. Eine Lösung ist jedoch bald verfügbar!

Auf Android API 30 gibt es bei einem der Orte, an dem wir versuchen, Ergebnisse lokal zu speichern, einen Berechtigungsfehler. Das Ergebnis wird dennoch 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 Elemente in einer Scroll-Ansicht teilweise vom Bildschirm 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 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 ausgeschaltet zu lassen, bei denen Sie Testdaten sicher nutzen und auf diese Weise 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) zu setHideOverlayWindows(false) auf den betroffenen Aktivitätsfenstern.

Um die volle Funktionalität von Axe DevTools for Mobile freizuschalten, stellen Sie sicher, dass Screenshots aktiviert sind. Wir empfehlen, Screenshots in einer Debug- oder Testversion Ihrer App zu aktivieren, die Testdaten verwendet, um Sicherheitsbedenken zu vermeiden. Sehen Sie sich unseren Leitfaden zu Aktivierung von Screenshots in Android-Apps an.

Wenn Sie Ihre Build-Version verkleinern, sehen Sie einen Absturz mit einem Fehlerprotokoll, das meldet, dass ein Adapter nicht gefunden werden konnte, wenn versucht wird, sich bei der Axe DevTools-Bibliothek anzumelden. Deaktivieren Sie die Verkleinerung für Ihre Debug-Builds mit implementiertem Axe DevTools. (#729)

Ein Build mit aktiviertem r8 könnte versuchen, die axeDevTools-Bibliothek zu verkleinern, was zu einem ähnlichen Fehler führen kann:

Die Compose-APIs sind veraltet, bitte nutzen Sie die layout-agnostischen APIs , um weiterhin Updates zu erhalten. Wenn Sie die Compose-APIs weiterhin verwenden und auf einen Fehler stoßen, der lautet wie „Genau '1' Knoten erwartet, aber '2' Knoten gefunden, die übereinstimmen: (isRoot)“ oder „Kein View initialisiert, haben Sie AxeDevToolsCompose.setComposeTestRule() aufgerufen?“, verweisen Sie bitte auf die Compose setTestTag API.

Aufgrund von Einschränkungen der MAUI-App-Architektur beim Rendern im Android-Ökosystem wird die Regel für Edit-Text-Name im Dashboard als Überprüfung erforderlich 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 Fenster implementieren, die nicht die nativen Steuerelemente erweitern, können Ergebnisse für Ansichten hinter dem modalen Fenster angezeigt werden. In diesem Fall empfehlen wir, unser Tool nicht gegen diese benutzerdefinierten modalen Fenster oder Dialoge auszuführen, 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, könnte Ihre App das Aufnehmen von Screenshots verhindern. Oft geschieht dies aus Sicherheitsgründen in Ihrer Produktionsanwendung. Ziehen Sie in Betracht, diese Anforderung für Ihren Test-Build 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 sind, erscheinen als vollständiger Klassenname inklusive Paketbezeichner. 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 festlegen. (#1643)