Axe DevTools Mobile Release Notes vom 16. September 2026

Wenn Sie Xcode 27 verwenden und eine Mobile Analyzer Desktop-App betreiben, die älter als 2.0.0 ist, kann die App den iOS-Simulator nicht öffnen. Es tritt ein Fehler auf, wenn /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app Sie können einen simulatorbasierten Scan nicht starten, bis dies behoben ist.

Um Scans mit einem Simulator auf Xcode 27 auszuführen, aktualisieren Sie den Desktop Analyzer auf Version 2.0.0+. Beachten Sie bei diesem Update, dass die Barrierefreiheitsergebnisse jetzt in 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, kollidierende Ansichten, jede Regel, die von Vision-erkanntem Text abhängt).

Vision liefert nicht immer den gleichen erkannten Text zwischen Durchläufen desselben Bildschirms. Wenn Vision den Text auf einem Steuerelement nicht erkennt, laufen Regeln, die auf diesen Text angewiesen sind, bei diesem Scan für dieses Element nicht. Die Ergebnisse können zwischen zwei Scans desselben Bildschirms inkonsistent erscheinen - ein Problem, das bei einem Scan gefunden wird, kann beim nächsten fehlen.

Wenn eine Vision-basierte Regel eine 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:

• Führen Sie den Scan erneut durch. Wenn eine Vision-basierte Regel für ein Steuerelement übersprungen wurde, wird sie oft bei einem weiteren Scan desselben Bildschirms erkannt.
• Behandeln Sie jeden Fehler einer Vision-basierten Regel als gültig - wenn Farbkontrast ein Steuerelement markiert, ist das Kontrastproblem real und sollte behoben werden.
• Verwenden Sie zur manuellen Überprüfung die Deque University Referenz für das relevante WCAG-Erfolgskriterium. (Links finden sich am Ende der jeweiligen Regel-Seiten.)

Auf iOS 26 und später, wenn ein Bildschirm Text mit einem Prozentzeichen enthält (z. B. ein Textetikett mit der Aufschrift „50% Rabatt“), kann die Supports Dynamic Type-Regel als Unvollständig statt als bestanden oder fehlgeschlagen gemeldet werden. Diese Regel stützt sich auf ein Barrierefreiheitsaudit von Apple, und dieses Audit stoppt den Testlauf, wenn es auf Prozentzeichen stößt. Um Ihre Tests fortzusetzen, ü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 sind keine Maßnahmen erforderlich, da Ihr Scan dennoch abgeschlossen wird. Um die Unterstützung für dynamische Typen auf diesen Bildschirmen zu überprüfen, vergrößern Sie die Textgröße auf Ihrem Gerät unter **Einstellungen** > **Barrierefreiheit** > **Anzeige & Textgröße** > **Großer Text** und bestätigen Sie, dass der Text auf dem Bildschirm sich entsprechend skaliert. Dieses Problem wurde Apple gemeldet. (#2985)

Die Farbkontrast-Regel verwendet Apples Vision-Framework (Optische Zeichenerkennung, oder OCR), um Text innerhalb der Grenzen eines Elements zu lesen. OCR kann gelegentlich kleine ikonische Glyphen - wie Zick-Zack-Pfeile (<), Aufzählungszeichen, dekorative Symbole - fälschlicherweise als Text identifizieren. Wenn das passiert, läuft die Farbkontrast-Regel auf einem Element, das keinen lesbaren Text enthält, was ein Ergebnis für eine nur aus Symbolen bestehende Schaltfläche erzeugen kann. Da OCR-Ausgaben über Scans hinweg nicht deterministisch sind, 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, 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 den Bildschirmtitel 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 Einschränkung der Flutter-Plattform, die verfolgt wird 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 Farbverlaufshintergründe melden. In solchen Fällen ist es möglicherweise nicht in der Lage, die Vordergrundfarbe zu bestimmen, und vergleicht stattdessen die Hintergrundfarben miteinander, was zu einem Fehler führt.

Um dieses Problem zu lösen, versuchen Sie, Barrierefreiheitsprüfungen auf größeren Geräten durchzuführen. Alternativ können Sie die Regel in Ihren Tests ignorieren und den Farbkontrast manuell für diese Ansichten überprüfen.

Apples Barrierefreiheits-APIs können Webinhalte innerhalb der WKWebView fälschlicherweise als „isVisible“ berichten, selbst wenn die Webansicht von nativen Overlay-Elementen (wie modalen Ansichten, Warnungen oder anderen nativen UI-Elementen) überdeckt wird. Dies liegt daran, dass das Barrierefreiheitssystem prüft, ob der WKWebView-Container selbst sichtbar ist, anstatt ob seine Webinhalte tatsächlich ungehindert und für den Benutzer wahrnehmbar sind.

iOS 26 enthält einen Barrierefreiheitsfehler, bei dem standardmäßige Schrittschaltflächen nicht als „gedimmt“ von der Assistenztechnologie gemeldet werden, um anzuzeigen, dass sie nicht aktiviert sind. Infolgedessen sehen auch die iOS-Regeln diese Schaltflächen als aktiviert an, selbst wenn sie es nicht sind. Bei Apple wurde ein Fehlerbericht eingereicht, bis dies behoben wird, können die folgenden Regeln Ergebnisse für deaktivierte Schrittschaltflächen melden: AssociatedText, InaccessibleAction, und ColorContrast.

Bis Apple diesen Fehler behebt, besteht die Lösung darin, [die Regeln zu ignorieren](ios-ignore-rule). Die Standard-Schrittschaltflächen haben die Kennungen „Verringern“ und „Erhöhen“ 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 mit LabelInName und LabelAtFront fälschlicherweise positive Ergebnisse aufgrund einer fehlerhaft gefundenen associatedText-Eigenschaft melden (#1622)

Während wir eine Verbesserung unserer Regeln betrachteten, stellten wir fest, dass in XCTest verschachtelte Steuerelemente 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 Assistenztechnologie fokussierbar.
Die Eigenschaften, die wir verwenden, um die Fokussierbarkeit von Apple zu überprüfen, können ungenau sein, wenn eine `accessibilityIdentifier` auf dem Bild gesetzt ist. Aufgrund dieses unerwarteten Verhaltens werden Ergebnisse für Probleme mit ImageView-Namen in UIKit-Apps als „Erforderliche Überprüfung“ 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 bannerverhaltenen Elementen, festen Kopf-/Fußzeilen, schwebenden Aktionsschaltflächen und benutzerdefinierten Registerkartenansichten kann mit einer „Erforderlichen Überprüfung“ oder „Fehler“-Meldung markiert werden. Um diese Elemente für diejenigen, die größere Texte benötigen, zugänglich zu machen, verwenden Sie UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Wenn ein UIImageView eine accessibilityIdentifier gesetzt hat, aber von VoiceOver nicht fokussierbar ist und es fokussierbare Steuerelemente innerhalb hat, kann Active Control Name ein falsch-positives Ergebnis für das UIImageView melden. Entfernen Sie die accessibilityIdentifier behebt das Problem. Ein Fehler wurde bei Apple gemeldet. (#1633)

Label In Name and Label At Front
Diese beiden Regeln suchen das sichtbare Label eines Steuerelements in der Nähe befindlicher Elemente, um den Status der Regeln zu bestimmen. In einigen Ansichts-Hierarchien kann ein falscher nahegelegener Text erkannt werden, was dazu führt, dass diese Regeln fehlschlagen. (#1622)

Die Regel „Label am Anfang“ überprüft, ob das sichtbare Label eines Elements am Anfang des angekündigten Textes steht. Ein Regelverstoß kann auftreten, wenn der sichtbare Text eines interaktiven Elements eine Abkürzung (z.B. „GB“, „km“) oder eine verdeckte/abgeschnittene Kennung enthält und die Barrierefreiheitsansage aus den dargestellten Wörtern besteht (z.B. „Gigabyte“, „Kilometer“), obwohl dies das empfohlene Muster zur Verbesserung der Bildschirmleserfreundlichkeit von abgekürzten oder abgeschnittenen Inhalten ist.

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

Bei der Verwendung dekorativen Texts in Ansichten wie „Kontaktsymbole“ kann ein Problem mit der Barrierefreiheit auftreten. Wenn Sie eine Textansicht verwenden, um Buchstaben anzuzeigen, anstatt Bilder mit den gewünschten Buchstaben als Vektoren zu erzeugen, und dann die Textansicht als für die Barrierefreiheit nicht wichtig deklarieren, können wir nicht zuverlässig feststellen, ob Sie einen Verstoß gegen die Barrierefreiheit eingeführt haben.

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

Flutter ordnet AppBar.title nicht der nativen Eigenschaft für den Bildschirmtitel 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 Einschränkung der Flutter-Plattform, die verfolgt wird in flutter/flutter#185894.

In einigen Fällen verlässt sich die Unterstützungstechnologie auf AccessibilityEvent Beschreibungen vom Android-System, um Informationen an den Benutzer zu übermitteln, wenn keine andere Ansage verfügbar ist. Da AccessibilityEvents durch 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 zu erfassen, 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 in einer Ansicht enthaltene Text dieselbe Farbe wie der Hintergrund hat, kann unser maschinelles Lernalgorithmus nicht erkennen, ob Text vorhanden ist, sodass die Farbkontrastregel nicht auf diese Ansicht angewendet wird.

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

Um dieses Problem zu beheben, empfehlen wir als erstes, Ihre Tests auf neueren Versionen von Android durchzuführen. Wenn es jedoch wichtig ist, dass die App auf älteren Android-Versionen zugänglich ist, sollten Sie in Erwägung ziehen, auf die Nutzung des hintText Features zu verzichten, da es nicht offiziell unterstützt wird.

Möglicherweise sehen Sie Ergebnisse für Ansichten, die hinter anderen Ansichten auf dem Bildschirm verborgen sind. Diese versteckten Ansichten sind für Unterstützungstechnologie 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. Es ist keine Behebung erforderlich, um die Barrierefreiheit sicherzustellen.

Die ML Kit Texterkennung ist in vielen Regeln der Axe DevTools Mobile erforderlich, 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 einbinden. In einigen Fällen erfolgt der automatische Import jedoch nicht und Sie sehen den folgenden Fehler im Logcat:

Die Regel zum Berührungszielabstand wird derzeit auf keine Slider-Komponenten angewendet, die in Jetpack Compose geschrieben wurden. Derzeit können keine Maßnahmen ergriffen werden. Eine Lösung kommt jedoch bald!

Unter Android API 30 gibt es einen Berechtigungsfehler an einem der Orte, an denen 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 der folgende Codeblock auskommentiert wird:

In einigen Hybrid- und plattformübergreifenden Apps können wir unerwartete Ergebnisse zurückgeben, 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 ist, bevor Sie den Scan durchführen.

Mit API 31 (Android 12) wurde die Möglichkeit eingeführt, nicht-systembezogene 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 aufgrund ihrer Sicherheitsverbesserungen zu nutzen, empfehlen wir, sie für interne Test-Builds ausgeschaltet zu lassen, in denen Sie sicher Testdaten verwenden und Sicherheitsbedenken auf diese Weise beseitigen 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 verwenden, aktualisieren Sie alle Aufrufe der Methode setHideOverlayWindows(true) auf den betroffenen Aktivitätsfenstern. setHideOverlayWindows(false) auf den betroffenen Aktivitätsfenstern.

Um den vollen Funktionsumfang 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 Mock-Daten verwendet, um Sicherheitsbedenken zu vermeiden. Lesen Sie unseren Leitfaden zum Aktivieren von Screenshots in Android-Apps.

Wenn Sie Ihren Build minimieren, sehen Sie einen Absturz mit einem Fehlerprotokoll, das meldet, dass ein Adapter nicht gefunden werden konnte, wenn versucht wird, sich in die Axe DevTools-Bibliothek einzuloggen. Deaktivieren Sie die Minifizierung für Ihre Debug-Builds mit implementierten Axe DevTools. (#729)

Ein Build mit aktiviertem r8 kann versuchen, die axeDevTools-Bibliothek zu minimieren, was zu einem Fehler ähnelt:

Die Compose-APIs sind veraltet. Bitte verwenden Sie die layout-unabhängigen APIs , um weiterhin Updates zu erhalten. Wenn Sie die Compose-APIs weiter nutzen und auf einen Fehler stoßen, der in etwa lautet: `Es wurde genau '1' Knoten erwartet, aber '2' Knoten gefunden, die folgenden Kriterien entsprechen: (isRoot)` oder `Kein View initialisiert, haben Sie AxeDevToolsCompose.setComposeTestRule() aufgerufen?`, beziehen Sie sich bitte auf die Compose setTestTag API.

Aufgrund von Einschränkungen der MAUI-App-Architektur beim Rendering im Android-Ökosystem wird die Bearbeiten-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 in diesem Fall das korrekte Verhalten manuell.

Wenn Sie benutzerdefinierte Dialoge oder Modale implementieren, die nicht die nativen Steuerelemente 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 laufen zu lassen und stattdessen manuell zu überprüfen, ob sie sich mit unterstützender Technologie wie gewünscht verhalten.

Wenn der Screenshot auf der Scan-Detailseite fehlt, kann es sein, dass Ihre App verhindert, dass Screenshots gemacht 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 dem Bildschirmtitel entsprechen, werden als voller Klassenname einschließlich der Bundle-Identifikatoren angezeigt. In einer zukünftigen Version wird dies behoben, sodass der Bildschirmtitel in einen leichter lesbaren Namen formatiert wird. Als Workaround können Sie den Scannamen über das Dashboard oder Frameworks festlegen. (#1643)