Verwendung dynamischer Selektoren

Beim Testen von Seiten, die bei jedem Seitenaufruf dynamische Element-IDs oder Klassennamen generieren, kann es für Axe Watcher schwierig sein, festzustellen, ob Barrierefreiheitsprobleme über mehrere Testläufe hinweg Duplikate sind. Dieser Artikel erklärt, wie Sie Watcher konfigurieren, um diese Szenarien korrekt zu handhaben. Eine dynamische URL verursacht das gleiche Symptom aus einem anderen Grund und erfordert eine andere Lösung, die unten in Dynamische URLs behandelt wird.

Das Problem mit dynamischen Selektoren

Standardmäßig verwendet Axe Watcher CSS-Selektoren, die Element-IDs und Klassen enthalten, um festzustellen, wo Barrierefreiheitsprobleme auftreten. Zum Beispiel könnte ein Problem bei gemeldet werden:

iframe#main-iframe

Dieser Ansatz funktioniert gut, wenn die IDs und Klassen Ihrer Seite zwischen den Seitenaufrufen konsistent bleiben. Viele moderne Webanwendungen generieren jedoch dynamische Bezeichner, die sich bei jedem Seitenaufruf ändern, wie zum Beispiel:

• #component-a1b2c3d4
• .form-field-xyz789

Axe Watcher sendet auch ein XPath für jedes Element, und im Axe Developer Hub wird ein Treffer bei einem der beiden Selektoren als dasselbe Element behandelt. Da ein XPath niemals Klassennamen enthält, wird eine Seite, deren Klassennamen alleine dynamisch sind, oft korrekt ohne weitere Konfiguration verfolgt. Ein XPath enthält jedoch die ID eines Elements, wenn diese ID auf der Seite eindeutig ist, und erzeugt einen Pfad wie //div[@id='component-a1b2c3d4']. Eine dynamische ID ändert daher den CSS-Selektor und den XPath zusammen, sodass es nichts Stabiles gibt, worauf man sich beziehen kann.

Wenn sich Identifikatoren zwischen den Testläufen auf diese Weise ändern, kann Axe Watcher nicht feststellen, ob ein Problem ein Duplikat eines zuvor erkannten Problems oder ein neuer Vorfall ist. Dies kann führen zu:

• Dass dasselbe Problem bei jedem Testlauf sowohl als „neu“ als auch als „gelöst“ gemeldet wird
• Ungenaues Verfolgen Ihres Fortschritts bei der Barrierefreiheit im Laufe der Zeit
• Schwierigkeiten zu erkennen, welche Probleme tatsächlich behoben wurden

Die Lösung: Aktivieren der Ancestry-Verfolgung

Um mit dynamischen Selektoren umzugehen, setzen Sie die Option ancestry in Ihrer runOptions-Konfiguration auf true. Wenn aktiviert, verwendet Axe Watcher die Position des Elements innerhalb des DOM-Baums, anstatt sich auf IDs und Klassen zu verlassen, um Elemente zwischen Testläufen zu lokalisieren.

Mit aktiviertem ancestry sieht ein Selektor, der zuvor so aussah:

iframe#main-iframe

Wird stattdessen den vollständigen Pfad vom Wurzelelement aus enthalten:

html > body > div:nth-child(20) > div:nth-child(1) > div > div > ul > li:nth-child(1) > div > span > iframe

Dieser Positionsselektor bleibt über Seitenladungen hinweg konsistent, selbst wenn sich IDs und Klassen ändern, was es Axe Watcher ermöglicht, Duplikatprobleme genau zu verfolgen.

Konfigurationsbeispiele

JavaScript und TypeScript

Fügen Sie die Option ancestry zu Ihrem runOptions-Objekt in der Axe-Konfiguration hinzu:

const config = {
  axe: {
    apiKey: process.env.ACCESSIBILITY_API_KEY,
    projectId: process.env.PROJECT_ID,
    runOptions: {
      ancestry: true
    }
  }
}

Java

Verwenden Sie die Methode setAncestry() auf Ihrem AxeRunOptions-Objekt:

AxeRunOptions runOptions = new AxeRunOptions()
    .setAncestry(true);

AxeWatcherOptions options = new AxeWatcherOptions()
    .setApiKey(System.getenv("ACCESSIBILITY_API_KEY"))
    .setProjectId(System.getenv("PROJECT_ID"))
    .setRunOptions(runOptions);

AxeWatcher watcher = new AxeWatcher(options);

Wann Ancestry-Verfolgung verwenden

Aktivieren Sie ancestry: true, wenn Ihre Anwendung:

• Frameworks verwendet, die dynamische Komponenten-IDs generieren (React, Vue, Angular)
• CSS-in-JS-Bibliotheken verwendet, die einzigartige Klassennamen generieren
• Formularfelder oder interaktive Elemente mit automatisch generierten Bezeichnern hat
• Inkonsequente Zählungen von „neuen Problemen“ und „gelösten Problemen“ zwischen Testläufen für anscheinend dieselben Probleme anzeigt

Zu berücksichtigende Abwägungen

Obwohl die Ancestry-Verfolgung das Problem der dynamischen Selektoren löst, gibt es einige Überlegungen:

• Lesbarkeit der Selektoren: Positionsselektoren sind länger und können schwerer zu lesen sein, wenn man Probleme im Axe Developer Hub überprüft.
• Empfindlichkeit gegenüber der DOM-Struktur: Wenn sich die DOM-Struktur Ihrer Seite zwischen den Renderings erheblich ändert (nicht nur die IDs/Klassen), können sich auch die Positionsselektoren ändern.
• Entwicklung: Beim Untersuchen eines Problems können Sie feststellen, dass es einfacher ist, ein Element über eine aussagekräftige ID als über seine Position im DOM-Baum zu finden.

Für die meisten Anwendungen mit dynamischen Bezeichnern überwiegen die Vorteile der genauen Problemverfolgung diese Kompromisse.

Dynamische URLs

Elementselektoren sind nur ein Teil davon, wie Axe Developer Hub ein Problem identifiziert. Auch die URL der Seite wird vollständig verglichen, einschließlich aller Abfragezeichenfolgen. Das Aktivieren von ancestry hat keinen Einfluss auf diesen Vergleich.

Eine URL, die sich zwischen den Testläufen ändert, erzeugt daher die gleichen Symptome wie ein dynamischer Selektor und tut dies noch aggressiver: Wenn eine URL zuvor nicht gesehen wurde, wird jedes darauf gefundene Problem als neu gemeldet, ohne dass die Elementselektoren überhaupt berücksichtigt werden. Häufige Ursachen sind:

• Session-IDs oder Authentifizierungstoken, die in der Abfragezeichenfolge enthalten sind
• Zeitstempel oder Cache-Busting-Parameter, wie ?v=1738012800
• Randomisierte IDs im Pfad, wie /orders/8f3c1b2a/summary
• Test-Fixierungsobjekte, die bei jedem Durchlauf einen neuen Datensatz erzeugen und somit eine neue URL

Es gibt keine Konfigurationsoption, die URLs normalisiert, bevor sie verglichen werden. Daher muss dies in Ihrer Testsuite gelöst werden: Navigieren Sie zu deterministischen URLs, sodass dieselbe Seite bei jedem Durchlauf dieselbe URL erzeugt. In der Praxis bedeutet dies in der Regel, dass Sie feste Testdaten verwenden, anstatt bei jedem Durchlauf neue Datensätze zu generieren, und flüchtige Abfrageparameter entfernen oder fixieren, bevor die Seite gescannt wird.

Wenn eine URL tatsächlich nicht stabilisiert werden kann, können Sie sie mit excludeUrlPatterns vollständig aus Ihren Ergebnissen ausschließen, obwohl dies bedeutet, dass die Seite überhaupt nicht gescannt, sondern nicht korrekt verfolgt wird. Einzelheiten dazu finden Sie in URLs von der Analyse ausschließen.

Siehe auch

• API-Referenz für JavaScript und TypeScript Vollständige Dokumentation für runOptions und andere Konfigurationsoptionen
• AxeRunOptions Klasse Java API-Referenz für Laufzeitoptionen
• Glossar: Duplikat Verstehen, wie der Axe Developer Hub doppelte Probleme identifiziert