Das „ Deque “-Labs-Team hat intensiv an einigen Aktualisierungen der JavaScript-Testbibliothek „aXe-Core “ für Version 3.0 gearbeitet, darunter die Unterstützung von Shadow DOM und Webkomponenten, Leistungsverbesserungen sowie einige neue Regeln: sowohl experimentelle Regeln als auch Best Practices – und nach Version 3.0 werden noch weitere folgen.
Damit Sie mit aXe 3.0 sofort loslegen können, werden wir uns ansehen, wie diese API-Änderungen funktionieren, welche Auswirkungen sie auf unsere Browser-Erweiterungen und andere Integrationen haben und wie sie sich auf unsere Attest-Produktreihe auswirken. So erfahren Sie, was aXe 3.0 zu bieten hat, wie Sie sofort loslegen können und wie Sie von einer noch leistungsfähigeren Suite von Tools für Barrierefreiheitstests profitieren. Lassen Sie uns beginnen.
Axe 3.0 & Shadow DOM
Um über die Neuerungen in aXe 3.0 zu sprechen, müssen wir zunächst auf die Neuerungen in der JavaScript-Bibliothek „ aXe-Core “ eingehen. Dabei handelt es sich um das zugrunde liegende JavaScript, das unsere Browser-Erweiterungen und APIs für Barrierefreiheitstests unterstützt.
Die größte Neuerung in „ aXe-Core “ 3.0 ist die Unterstützung von Shadow DOM. Das klingt vielleicht etwas unheimlich, ist aber ein Standard, der Teil der Web-Component-Spezifikationen ist und es ermöglicht, Teile von Webseiten zu kapseln. Man kann sich Web-Components als die jQuery-Plugins der Zukunft vorstellen, und Shadow DOM ist der Teil davon, der verhindert, dass Ihre Stile und Skripte nach innen oder außen „auslaufen“.
Beispiel: „ aXe-core “ 3.0 im Shadow DOM
Um euch zu zeigen, wie das in der Praxis funktioniert, habe ich diese kleine Demo-App zur Planung von Skiausflügen, die ich mit React JS erstellt habe, und ich werde sie mir nun im DOM-Inspector von Chrome genauer ansehen, um zu prüfen, was dort vor sich geht.
Wenn ich ein wenig heranzoome, könnt ihr sehen, dass diese Routenplaner-Komponente im Inneren eine Kapselung mit einem offenen Schatten-Root aufweist. Ein offener – im Gegensatz zu einem geschlossenen – Schatten-Root kapselt diese Seiten, ermöglicht es Tools wie „ aXe-Core “ jedoch weiterhin, in sie hineinzuzoomen. Es gibt also einige bekannte Barrierefreiheitsprobleme in dieser Komponente, die wir mit „ aXe-Core “ 3.0 erkennen können sollten.
aXe-Coconut-Erweiterung und Shadow DOM
Um Ihnen zu zeigen, wie das funktioniert, werde ich unsere aXe-Coconut-Vorabversion öffnen, mit der bisher „ aXe-Core “ 3.0 in dieser Vorabumgebung getestet wurde. Diese Änderungen werden schließlich in unsere stabilen aXe-DevTools-Erweiterungen für Chrome und Firefox einfließen, sodass Sie mit der normalen Erweiterung innerhalb des Shadow-DOM testen können.
Aber vorerst können wir uns das in aXe-Coconut ansehen und feststellen, dass es tatsächlich in das Shadow DOM vordringt; es hat festgestellt, dass uns einige Formular-Labels fehlten und dass es innerhalb dieses Shadow Roots sogar Probleme mit dem Farbkontrast gab. Von aXe-Coconut aus kann ich den Knoten untersuchen und feststellen, dass „ aXe-Core “ dieses Problem tatsächlich innerhalb unseres offenen Shadow Roots gefunden hat. aXe überspringt diese gesamten Seitenbereiche nicht mehr, wenn Sie tatsächlich das offene Shadow DOM verwenden.
Fehler in Axe-Coconut melden
Eine weitere coole Funktion, auf die ich bei der neuen aXe-Coconut-Erweiterung hinweisen möchte, ist diese kleine Schaltfläche zum Melden von Fehlern. Über diese Schaltfläche kannst du direkt aus der Browser-Erweiterung heraus ein Problem bezüglich einer experimentellen Regel oder eines Shadow-DOM-Fehlers melden.
Im Gegensatz zu unserer regulären Chrome-Erweiterung, die keine Schaltfläche zum Melden von Fehlern enthält, soll aXe-Coconut Ihnen die Möglichkeit bieten, Fehler frühzeitig zu melden, noch bevor diese Änderungen für alle Nutzer verfügbar sind. Die Unterstützung für Shadow DOM wird in Kürze in unseren aXe-Erweiterungen für Chrome und Firefox verfügbar sein und ist bereits in „ aXe-Core “ 3.0 enthalten.
Axe 3.0 in Ihrer automatisierten Testsuite
Bisher haben wir uns auf die Browser-Erweiterungen und den eher manuellen Prozess des Barrierefreiheitstests konzentriert. Sie können aXe 3.0 jedoch auch in Ihrer automatisierten Testsuite einsetzen. Dazu wechseln wir nun zu meinem Texteditor, in dem ich einige Integrationstests für unsere kleine Demo-App geschrieben habe, die mit React erstellt wurde.
In der Datei „package.json“ habe ich hier ein Skript für die Integration hinterlegt. Es führt das Mocha-Test-Framework aus und anschließend unsere beliebige Datei „integration/a11y.js“. Außerdem binde ich eine spezielle Version von aXe-WebdriverJS ein. Dies wird nun in unserer stabilen Version 2.0 von aXe-WebdriverJS zum Standard werden, aber bisher konntet ihr in dieser Version 2.0.0-alpha.1 noch aXe 3.0 verwenden. Das wird sehr bald zum Mainstream werden, aber vorerst kann ich diese Alpha.1-Version zusammen mit dem aXe-WebdriverJS-Tool nutzen, um tatsächlich mit einem automatisierten Test innerhalb des Shadow-DOM zu testen.
In unserer Datei „integration/a11y.js“ verwende ich Selenium WebDriver und aXe-WebdriverJS, um eine echte Browser-Instanz auszuführen und die Barrierefreiheit über die Befehlszeile zu testen. Ich nehme hier einige Einstellungen vor; da ich diese bereits in anderen Videos behandelt habe, werde ich jetzt nicht allzu sehr ins Detail gehen, sondern euch lediglich die eigentlichen Tests zeigen. Der erste Test sieht vor, dass auf der Startseite keine Verstöße gefunden werden sollten; er sucht ein Element auf dieser Seite und führt diesen axeBuilder aus.
So führen Sie axeBuilder aus
Genau wie bei einem normalen Barrierefreiheitstest erwarten wir, dass keine Verstöße gegen die Barrierefreiheit vorliegen. Und um sicherzustellen, dass wir alle verschiedenen Bereiche dieser Anwendung testen, gibt es in dieser App ein modales Fenster. Deshalb öffnen wir das modale Fenster programmgesteuert mit der Eingabetaste und führen anschließend axeBuilder erneut aus, um sicherzustellen, dass keine Verstöße vorliegen. Nun habe ich das Beispiel absichtlich mit Barrierefreiheitsverstößen erstellt, sodass wir eine ganze Reihe davon sehen sollten, und sie sollten so aussehen, wie wir es bereits in aXe-Coconut gesehen haben.
In meinem Terminal werde ich Folgendes ausführen: npm run integration um dieses npm-Skript auszuführen. Es öffnet im Hintergrund jeweils eine Browser-Instanz; wir können sehen, dass sich diese bei jedem Test einmal öffnet, und wenn ich nach oben scrolle – ja, leider gibt es hier einige Probleme mit der Barrierefreiheit, aber genau das war das Ziel. Wir wollten sehen, wie aXe-WebdriverJS uns diese Probleme melden würde.
Also, in dieser App scrolle ich jetzt einfach hier ganz nach oben – ich sehe, dass tatsächlich dieselben Probleme mit den Beschriftungen gefunden werden, die wir bereits in aXe-Coconut gesehen haben. Die App ruft diesen Reiseplaner auf und weist uns darauf hin, dass wir einige Beschriftungen vergessen haben. Das ist also ein Problem, das wir beheben könnten. Wir könnten weitere Probleme aufdecken, indem wir entweder die Browser-Erweiterungen nutzen oder unsere automatisierten Tests einsetzen. Anschließend könnt ihr all diese Probleme beheben und versuchen, die App so zu gestalten, dass sie keine Barrierefreiheitsprobleme mehr aufweist.
Zusammenfassung
In diesem Format könntet ihr verhindern, dass Barrierefreiheitsprobleme in die Produktion gelangen, oder einen Build vielleicht schon vor der Freigabe in einem Pull-Request zum Scheitern bringen. Es hängt wirklich davon ab, wie euer Team arbeiten möchte und welche Tools ihr bevorzugt: Bevorzugt ihr Browser-Erweiterungen oder automatisierte Tools oder eine Kombination aus beidem? Das ist normalerweise meine Vorgehensweise. Aber mit aXe 3.0 könnt ihr euren Workflow wirklich modernisieren, sodass das Tool direkt in das Shadow DOM eingreift und die Überprüfung so schnell wie möglich durchführt. Es gibt viele Randfälle, an denen wir noch arbeiten. Wenn ihr also Probleme entdeckt – etwa Fehlalarme oder versäumte Fehler –, lasst es uns bitte unbedingt wissen, entweder auf GitHub oder auf Twitter. Wir würden uns sehr über euer Feedback freuen. Vielen Dank.
