Axe DevTools Mobile August 2026 Release Notes

Auf iOS 26 und später kann die Regel „Unterstützt Dynamischen Text“ als unvollständig gemeldet werden, wenn ein Bildschirm Text mit einem Prozentzeichen enthält (z. B. ein Textetikett mit der Aufschrift „50 % Rabatt“). Diese Regel hängt von einem Barrierefähigkeitstest ab, der von Apple bereitgestellt wird, und dieser Test stoppt den Testlauf, wenn er Prozentzeichen erkennt. 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 auf dem Bildschirm laufen normal und andere Bildschirme sind nicht betroffen.

Es ist keine Aktion erforderlich, da Ihr Scan dennoch abgeschlossen wird. Um die Unterstützung für dynamische Textgröße auf diesen Bildschirmen zu überprüfen, erhöhen 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 korrekt skaliert. Dieses Problem wurde an Apple gemeldet. (#2985)

Die Farbkontrastregel verwendet Apples Vision-Framework (Optische Zeichenerkennung, oder OCR), um Text innerhalb der Grenzen eines Elements zu lesen. OCR kann gelegentlich kleine ikonartig Symbole, wie Rückwärtspfeilspitzen (<), Aufzählungspunkte, dekorative Symbole, fälschlicherweise als Text erkennen. Geschieht dies, wird die Farbkontrastregel auf ein Element angewendet, das keinen lesbaren Text enthält, was zu einem Ergebnis für eine nur ikonische Schaltfläche führen kann. Da der OCR-Output nicht immer identisch ist, kann dasselbe Element in einem Scan unter Farbkontrasergebnissen 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 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 in flutter/flutter#185894verfolgt wird.

Beim Ausführen von Barrierefreiheitstests auf kleineren Bildschirmgrößen oder mit kleineren Schriftgrößen kann die Farbkontrastregel fälschlicherweise positive Ergebnisse für Farbverlaufshintergründe melden. In solchen Fällen kann sie die Vordergrundfarbe nicht bestimmen und statt dessen Hintergrundfarben miteinander vergleichen, was zu einem Fehlschlag führt.

Um dieses Problem zu umgehen, versuchen Sie, Barrierefreiheitstests 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.

Die Barrierefreiheits-APIs von Apple können Webinhalte innerhalb von WKWebView fälschlicherweise als „isVisible“ melden, selbst wenn die Webansicht von nativen Overlays (wie z.B. modale Ansichten, Warnungen oder andere native UI-Elemente) überdeckt wird. Dies geschieht, weil das Barrierefreiheitssystem überprüft, ob der WKWebView-Container selbst sichtbar ist und nicht, ob seine Webinhalte tatsächlich ungehindert und für den Benutzer wahrnehmbar sind.

In iOS 26 gibt es einen Barrierefreiheits-Bug, bei dem die Standard-Schrittsteuerungsschaltflächen nicht von der unterstützenden Technologie mit „gedimmt“ angekündigt werden, um anzuzeigen, dass sie nicht aktiviert sind. Dadurch sehen auch die iOS-Regeln diese Schaltflächen als aktiviert, selbst wenn sie es nicht sind. Ein Fehlerbericht wurde bei Apple eingereicht, aber bis dies behoben ist, könnten die folgenden Regeln Ergebnisse zu deaktivierten Schrittsteuerungsschaltflächen melden: AssociatedText, InaccessibleActionund ColorContrast.

Bis Apple diesen Fehler behebt, besteht die Lösung darin, [die Regeln zu ignorieren](ios-ignore-rule). Die Standard-Schrittsteuerungsschaltflächen haben die Bezeichnungen „Decrement“ und „Increment“ und können bei Bedarf anhand der 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 Fehlalarme mit LabelInName und LabelAtFront aufgrund einer falsch gefundenen associatedText-Eigenschaft anzeigen (#1622)

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

In UIKit-Apps ist ein Bild ohne ein `accessibilityLabel` standardmäßig nicht mit unterstützender Technologie fokussierbar.
Die von uns verwendeten Eigenschaften zur Überprüfung der Fokussierbarkeit von Apple können ungenau sein, 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 Fehlalarme und werden diese Liste aktualisieren, sobald Korrekturen veröffentlicht werden.

In Scroll View
Text in banner-ähnlichen Elementen, festen Kopf-/Fußzeilen, schwebenden Aktionsschaltflächen und benutzerdefinierten Tab-Ansichten kann mit einer „Überprüfung erforderlich“ oder „Fehler“-Nachricht markiert werden. Verwenden Sie UILargeContentViewer. (#622, #2077)

v2.11.0 Image View Name & Active Control Name
Wenn ein UIImageView ein accessibilityIdentifier gesetzt hat, aber nicht von VoiceOver fokussiert werden kann und es fokussierbare Steuerungen darin gibt, kann Active Control Name ein falsch positives Ergebnis auf dem UIImageView melden. Das Entfernen des accessibilityIdentifier löst das Problem. Ein Fehlerbericht wurde bei Apple eingereicht. (#1633)

Label In Name and Label At Front
Diese beiden Regeln suchen nach einem sichtbaren Label einer Steuerung unter den umliegenden Elementen, um den Regelstatus zu bestimmen. In einigen Ansichts-Hierarchien kann der falsche nahegelegene 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 einen verdeckten/verstümmelten Bezeichner enthält, und die Barrierefreiheitsansage aus den dargestellten Wörtern (z.B. „Gigabyte“, „Kilometer“) besteht, obwohl dies das empfohlene Muster ist, um abgekürzten oder verstümmelten Inhalt für Screenreader freundlich zu gestalten.

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

Bei der Verwendung von dekorativem Text in Ansichten wie „Kontakticons“ 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 barrierefrei wichtig deklarieren, können wir nicht zuverlässig feststellen, ob Sie einen Barrierefreiheitsverstoß eingeführt haben.

Wenn Sie fokussierbaren Text bearbeiten, um zwei oder weniger Zeichen zu ignorieren, könnten 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, das Sie im Icon darstellen möchten, entnehmen und die Buchstaben als Teil des Bildes generieren, anstatt als separate Textansichten. `FocusableText` wird dann auf 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 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 in flutter/flutter#185894nachverfolgt 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. Dadurch kann Talkback die Informationen aus der Ansicht nutzen, 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. Wenn der Text in einer Ansicht die gleiche Farbe wie der Hintergrund hat, kann unser maschinelles Lernalgorithmus 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 Hinweistexte verwenden, können falsch positive Ergebnisse mit der EditTextName -Regel sehen. Hinweistext wurde erst in Android 8 (SDK 26) eingeführt. Die Verwendung dieses Elements in Ihrer XML-App weist den Hinweistext dem Wert des Texteinabefelds zu. Neuere Versionen von Android sind besser gerüstet, um dieses Erlebnis barrierefrei zu machen.

Um dieses Problem zu lösen, empfehlen wir als erstes, Ihre Tests auf neueren Versionen von Android auszuführen. Wenn es jedoch wichtig ist, dass die App auch auf älteren Android-Versionen zugänglich ist, sollten Sie die Verwendung der hintText Funktion vermeiden, 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 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 Behebung, um die Zugänglichkeit sicherzustellen.

Für viele der Regeln von Axe DevTools Mobile ist die ML Kit Texterkennung 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 werden den folgenden Fehler in Logcat sehen:

Die Regel für den Touch-Zielabstand wird derzeit nicht auf Schiebereglerkomponenten angewandt, die in Jetpack Compose geschrieben wurden. Derzeit kann keine Maßnahme ergriffen werden. Eine Lösung ist jedoch bald verfügbar!

Auf Android API 30 tritt ein Berechtigungsfehler auf, wenn wir versuchen, Ergebnisse lokal zu speichern. Die Ergebnisse werden dennoch als JSON-Datei gespeichert, obwohl dieser Fehler angezeigt wird. Der Fehler kann unterdrückt werden, indem Sie den folgenden Codeblock auskommentieren:

In einigen Hybrid- und plattformübergreifenden Apps können wir unerwartete Ergebnisse erhalten, wenn Elemente in einer Bildlaufansicht teilweise vom Bildschirm verschwinden. Um ein Element auf Barrierefreiheit zu testen, stellen Sie sicher, dass es vollständig sichtbar 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 aus Sicherheitsgründen für die Nutzung dieser Funktion entschieden haben, empfehlen wir Ihnen, sie für interne Testversionen deaktiviert zu lassen, bei denen Sie sicher mit Testdaten arbeiten 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 den betroffenen Aktivitätsfenstern. setHideOverlayWindows(false) Screenshot fehlt (Schwarzer Kasten) im Dashboard

Aktivieren von Screenshots in Android-Apps an. Absturz, wenn

Builds mit aktivierter r8 werfen einen Fehler

Um diesen Fehler zu beheben, fügen Sie die folgende Zeile in Ihre ProGuard-Datei ein, um axeDevTools-Klassen zu behalten:

layout-unabhängigen APIs , um weiterhin Updates zu erhalten. Wenn Sie die Compose-APIs weiter verwenden und auf einen Fehler wie „Expected exactly '1' node but found '2' nodes that satisfy: (isRoot)“ oder „No View initialized, did you call AxeDevToolsCompose.setComposeTestRule()?“ stoßen, beziehen Sie sich bitte auf die Compose setTestTag API .MAUI: Regel für Edit Text Name

Native Android: Benutzerdefinierte Dialoge/Modale

Web-Dashboard

Android - FLAG_SECURE

• Einige Android-Scan-Namen sind unformatiert

Some Android scan names that are defaulted to the screen title will appear as the full class name including the bundle identifier. In a future release, this will be resolved so that the screen title is formatted into a more readable name. As a workaround, you can set the scan name from the dashboard or frameworks. (#1643)