Bekannte Probleme

Die Farbkontrastrege verwendet das Vision-Framework von Apple (Optical Character Recognition oder OCR), um Text innerhalb der Grenzen eines Elements zu lesen. OCR kann gelegentlich kleine, ikonenartige Glyphen - wie Pfeilspitzen (<), Aufzählungszeichen, dekorative Symbole - fälschlicherweise als Text erkennen. In solchen Fällen wird die Farbkontrastrege auf ein Element angewendet, das keinen lesbaren Text enthält, was zu einem Ergebnis für ein Icon-Button führen kann. Da die Ausgabe von OCR nicht deterministisch über Scans hinweg 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 AppBar.title nicht der nativen Bildschirmitteleigenschaft zu - UIViewController.title, was dazu führt, dass die Bildschirmtitelseite in 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#185894.

Beim Ausführen von Barrierefreiheitstests auf kleineren Bildschirmgrößen oder mit kleineren Schriftgrößen kann die Farbkontrastrege falsch positive Ergebnisse für Farbverlauf-Hintergründe melden. In solchen Fällen kann es nicht möglich sein, die Vordergrundfarbe zu bestimmen, und stattdessen werden die Hintergrundfarben miteinander verglichen, 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 Farbkontrast manuell für diese Ansichten zu überprüfen.

Die Barrierefreiheits-APIs von Apple können Webinhalte innerhalb von WKWebView fälschlicherweise als "anzeigen,isVisible" selbst wenn die Webansicht von nativen Überlagerungen (wie Modalansichten, Warnungen oder anderen nativen UI-Elementen) 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 Schrittnummern-Tasten nicht von unterstützender Technologie als „abgedunkelt“ angekündigt werden, um anzuzeigen, dass sie nicht aktiviert sind. Dadurch sehen auch die iOS-Regeln diese Tasten als aktiviert, auch wenn sie es nicht sind. Ein Fehlerbericht wurde bei Apple eingereicht, aber bis dies behoben ist, können die folgenden Regeln Ergebnisse auf deaktivierten Schrittnummern-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 Schrittnummern-Tasten haben die Bezeichnungen „Decrement“ und „Increment“ und können bei Bedarf anhand des Identifikators 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 Ergebnisse mit LabelInName und LabelAtFront melden, da eine falsche associatedText-Eigenschaft gefunden wurde (#1622)

Es gibt ein Problem, das den iPhone 15 Pro-Simulator betrifft und verhindert, dass die Unterstützung für dynamischen Typ-Regel ausgeführt wird. Wenn Sie an der Unterstützung für die dynamische Typ-Regel teilnehmen, können Sie diese mit einem iPhone 15 Pro-Simulator nicht testen. Ein Fehler wurde bei Apple gemeldet.

Während wir an einer Verbesserung unserer Regeln arbeiten, haben wir festgestellt, dass in XCTest verschachtelte Steuerungen 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 assistiver Technologie fokussierbar.
Die von uns verwendeten Eigenschaften zur Überprüfung der Fokussierbarkeit von Apple können ungenau sein, wenn ein `accessibilityIdentifier` auf das Bild festgelegt ist. Aufgrund dieses unerwarteten Verhaltens werden Ergebnisse für ImageView-Name-Probleme in UIKit-Apps als „Muss überprüft werden“ gemeldet. Ein Fehlerbericht wurde bei Apple eingereicht. (#1633)

Wir arbeiten aktiv an der Behebung der folgenden falsch positiven Ergebnisse und werden diese Liste aktualisieren, sobald Korrekturen veröffentlicht werden.

In Scroll View
Text innerhalb von Banner-verhaltenden Elementen, Sticky-Headern/-Footern, schwebenden Aktionsschaltflächen und benutzerdefinierten Registeransichten kann mit einer Nachricht „Überprüfung erforderlich“ oder „Fehler“ markiert werden. Um diese Elemente für Personen zugänglich zu machen, die größere Text 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 von VoiceOver fokussierbar ist und fokussierbare Steuerelemente innerhalb davon verschachtelt sind, kann Active Control Name ein falsch positives Ergebnis für das UIImageView melden. 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 Etikett eines Steuerungselements unter den nahegelegenen Elementen, um den Status der Regel zu bestimmen. In einigen Ansichtenhierarchien kann der falsche nahegelegene Text erkannt werden, was zum Versagen dieser Regeln führen kann. (#1622)

Die Regel „Label at Front“ ü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/gekürzten Identifikator enthält und die Barrierefreiheitsankündigung aus den dargestellten Worten (z. B. „Gigabytes“, „Kilometer“) besteht, obwohl dies das empfohlene Muster ist, um abgekürzte oder gekürzte Inhalte für Bildschirmleser zugänglicher zu machen.

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

Bei der Verwendung von dekorativem Text in Ansichten wie „Kontakt-Icons“ kann es möglich sein, ein Barrierefreiheitsproblem einzuführen. Wenn Sie ein Textfeld verwenden, um Buchstaben anstelle von Bildern mit den gewünschten Buchstaben als Vektoren anzuzeigen, und dieses Textfeld dann als nicht wichtig für die Barrierefreiheit 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 unabsichtlich viele einwortige Schaltflächen in verschiedenen Sprachen (z. B. „OK“, „No“, „Sí“) ignorieren. Um solche Probleme zu vermeiden, sollten Sie die gewünschten Buchstaben aus dem Wort, das Sie im Icon darstellen möchten, greifen und die Buchstaben als Teil des Bildes anstelle von separaten Textansichten generieren. `FocusableText` wird dann nicht auf diesen Ansichten ausgeführt.

Flutter ordnet AppBar.title nicht der nativen Bildschirmitteleigenschaft zu - Activity.setTitle, was dazu führt, dass die Bildschirmtitelseite in 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#185894.

In einigen Fällen hängt unterstützende Technologie von AccessibilityEvent -Beschreibungen des Android-Systems ab, 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 richtige 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 abrufen, die unser Tool dann erkennen kann.

Unsere Farbkontrastregel basiert auf maschinellem Lernen zur Texterkennung, um sicherzustellen, 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 Lernalgorithmus nicht feststellen, ob Text vorhanden ist, sodass die Farbkontrastregel für diese Ansicht nicht ausgeführt wird.

Apps, die mit XML geschrieben wurden und die Feature "Hinweistext" nutzen, können falsche Alarme 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 Android-Versionen sind besser in der Lage, diese Erfahrung barrierefrei zu gestalten.

Um dieses Problem zu überwinden, empfehlen wir, Ihre Tests auf neueren Android-Versionen durchzuführen. Wenn es jedoch wichtig ist, dass die App auf älteren Android-Versionen barrierefrei ist, sollten Sie möglicherweise darauf verzichten, das hintText Feature zu verwenden, 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 verborgenen Ansichten sind für unterstützende Technologien nicht verfügbar, aber Axe DevTools Mobile meldet sie dennoch als Problem.

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 sicherzustellen.

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

Die Touch-Target-Abstandsregel wird derzeit nicht auf Schiebereglerkomponenten angewendet, die in Jetpack Compose geschrieben wurden. Derzeit kann keine Aktion unternommen werden. Es ist jedoch bald eine Lösung in Sicht!

Unter Android API 30 hat eine der Speicherorte, an denen 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 zurückgegeben werden, wenn Elemente in einem Scroll-Bereich teilweise außerhalb des Bildschirms liegen. Um ein Element auf Barrierefreiheit zu testen, stellen Sie sicher, dass es vollständig auf dem Bildschirm sichtbar ist, bevor Sie den Scan durchführen.

Mit API 31 (Android 12) wurde die Möglichkeit eingeführt, nicht-systemeigene Overlays auszublenden. Um die Axe Analyzer App nutzen zu können, stellen Sie bitte sicher, dass diese Einstellung nicht aktiviert ist. Wenn Sie beschlossen haben, diese Funktion aufgrund ihrer Sicherheitsverbesserungen zu nutzen, empfehlen wir, sie für interne Testbuilds deaktiviert zu lassen, bei denen Sie sicher Testdaten verwenden und so Sicherheitsbedenken eliminieren 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) .

Um die volle Funktionalität der Axe DevTools für Mobile freizuschalten, stellen Sie sicher, dass Screenshots aktiviert sind. Wir empfehlen, Screenshots in einer Debug- oder Testversion Ihrer App zu aktivieren, die mit Mock-Daten arbeitet, um Sicherheitsbedenken zu vermeiden. Schauen Sie sich unseren Leitfaden für Aktivieren von Screenshots in Android-Apps.

Wenn Sie Ihr Build minimieren, sehen Sie möglicherweise einen Absturz mit einem Fehlerprotokoll, in dem gemeldet wird, dass ein Adapter nicht gefunden werden konnte, wenn versucht wird, sich bei der Axe DevTools-Bibliothek anzumelden. Deaktivieren Sie die Minifizierung für Ihre Debug-Builds mit implementiertem Axe DevTools. (#729)

Ein Build mit aktiviertem r8 kann versuchen, die axeDevTools-Bibliothek zu verkleinern, was zu einem Fehler wie dem folgenden führt:

Die Compose-APIs sind veraltet. Bitte verwenden Sie die layout-agnostischen APIs , um weiterhin Updates zu erhalten. Wenn Sie die Compose-APIs weiterhin verwenden und auf einen Fehler stoßen, der etwa lautet: `Erwartet genau '1' Knoten, aber '2' Knoten gefunden, die übereinstimmen: (isRoot)` oder `Keine Ansicht initialisiert, haben Sie AxeDevToolsCompose.setComposeTestRule() aufgerufen?`, beachten Sie bitte Compose setTestTag API.

Aufgrund von Einschränkungen der MAUI-App-Architektur im Android-Ökosystem wird die Regel für Edit Text Name 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 die nativen Steuerelemente nicht 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 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 Scandetailseite fehlt, verhindert Ihre App möglicherweise, dass Screenshots gemacht werden. Oft ist dies aus Sicherheitsgründen in Ihrer Produktionsanwendung der Fall. Erwägen Sie, diese Anforderung für Ihr Test-Build zu entfernen, um die volle Funktionalität im Axe DevTools Mobile Dashboard zu ermöglichen.

• Android - FLAG_SECURE

Einige Android-Scannamen, die standardmäßig auf den Bildschirmtitel gesetzt sind, werden als voller Klassenname angezeigt, einschließlich des Bundle-Identifier. 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 Scannamen über das Dashboard oder die Frameworks festlegen. (#1643)