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.

// Ignore Color Contrast for a specific element by accessibility identifier
axeDevTools?.configuration.ignore(rulesFor: [
    "backButton": [AxeRuleId.ColorContrast.toString()]
])

Flutter ordnet AppBar.title nicht der nativen Bildschirmtitel-Eigenschaft zu - UIViewController.title, was dazu führt, dass die Bildschirm-Titel-Regel 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 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 in bannerartigen Elementen kann mit einer „Überprüfung erforderlich“-Nachricht markiert werden. Um diese Elemente für Personen zugänglich zu machen, die größere Texte benötigen, verwenden Sie UILargeContentViewer. (#622)

v2.11.0 Image View Name & Active Control Name
Wenn ein UIImageView eine `accessibilityIdentifier` gesetzt hat, aber nicht durch VoiceOver fokussierbar ist und es fokussierbare Steuerelemente darin gibt, kann ActiveControlName einen Fehlalarm auf dem UIImageView melden. Das Entfernen der `accessibilityIdentifier` behebt das Problem. Ein Fehlerbericht wurde an Apple gesendet. (#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)

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 versteckten Ansichten sind für unterstützende Technologie 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, wenn TalkBack diese Ansichten nicht erreichen kann, können Sie die entsprechenden Probleme ignorieren. Sie erfordern keine Behebung, um die Barrierefreiheit sicherzustellen.

Die ML Kit Texterkennung ist in vielen der axe DevTools Mobile-Regeln erforderlich, um die Genauigkeit der Ergebnisse zu gewährleisten. 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 jedoch erfolgt der automatische Import nicht, und Sie sehen den folgenden Fehler im Logcat:

Axe DevTools Android: Error while running mlKit Text Detection: MlKitContext has not been initialized.

Um dieses Problem zu lösen, sollten Sie die ML Kit-Bibliothek manuell in Ihr Projekt importieren. In der build.gradle -Datei Ihrer Anwendung fügen Sie Folgendes unter Abhängigkeiten hinzu:

debugImplementation 'com.google.mlkit:text-recognition:16.0.1'

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:

def clearDirectoryTask = task('clearDirectoryTask', type: Exec, group: 'reporting') {
	executable "${android.getAdbExecutable().toString()}"
	args 'shell', 'rm', '-r', '/storage/emulated/0/Documents/AxeTestCases'

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) wird 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 sich entschieden haben, diese Funktion aus Sicherheitsgründen zu nutzen, empfehlen wir, sie für interne Testbuilds, in denen Sie Testdaten gefahrlos verwenden können, deaktiviert zu lassen, um Sicherheitsbedenken auf diese Weise auszuräumen. 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 von 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 Mock-Daten verwendet, um Sicherheitsbedenken zu vermeiden. Sehen Sie sich unseren Leitfaden für Aktivieren von Screenshots in Android-Apps.

Wenn Sie Ihr Build verkleinern, sehen Sie möglicherweise 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 das Verkleinern für Ihre Debug-Builds mit implementierten axe DevTools. (#729)

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

Caused by: java.lang.NullPointerException: throw with null exception
at g.b.b.a$a.a(Unknown Source:1)
at g.b.b.a$a.a(Unknown Source:0)
at g.b.b.a.a(AccessToken.java:190)
	

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 Detailseite des Scans fehlt, verhindert Ihre App möglicherweise die Aufnahme von Screenshots. Dies geschieht oft aus Sicherheitsgründen in Ihrer Produktionsanwendung. Erwägen Sie, diese Anforderung für Ihr Test-Build zu entfernen, um 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)