Automatisierte Zugänglichkeitsprüfung
Es stehen zahlreiche automatisierte Tools zum Testen auf Barrierefreiheitsprobleme zur Verfügung. Bevor wir ins Detail gehen, lassen Sie uns eines ganz klar sagen: Automatisiertes Testen kann nur 30–40 % aller Barrierefreiheitsprobleme zuverlässig erkennen .
Automatisierte Tools sind nicht in der Lage festzustellen, wofür ein Bauteil eigentlich gedacht ist. Es kann keinen Menschen ersetzen, der eine Schnittstelle auf Zugänglichkeits- und Usability-Probleme testet. Es ist ratsam, immer manuell mit Hilfstechnologien zu testen und Usability-Testsitzungen mit Personen durchzuführen, die Hilfstechnologien verwenden und sich darauf verlassen.
Automatisierte Testwerkzeuge
Hier sind gängige Tools zum Testen. Diese können als Browsererweiterungen installiert und auf jeder Website ausgeführt werden, an der Sie arbeiten. Führen Sie häufig aus, um Probleme mit „niedrig hängenden Früchten“ zu identifizieren.
- Leuchtturm von Google
- aXe von Deque
- WAVE von WebAIM
- Einblicke in die Barrierefreiheit von Microsoft
Stellen Sie sicher, dass Sie mehr als ein Tool ausführen, da einige ein detaillierteres und genaueres Feedback liefern als andere.
Usability-Tests
Usability-Tests sollten nach der Entwicklung einer Komponente, aber vor der Einführung für die breite Öffentlichkeit durchgeführt werden. Auf diese Weise wird Feedback empfangen und Zeit zur Verfügung gestellt, um alle Usability-Probleme zu beheben.
Zu den empfohlenen Dienstleistungen gehören:
Unit-Tests
Es ist sehr gut möglich, Komponententests zu schreiben, um Ihren Code auf Barrierefreiheitsprobleme zu testen. Dies ist eine weitere großartige Möglichkeit, diese „einfachen Gewinne“ zu erfassen und zu verhindern, dass Regressionen stattfinden, wenn Code in die Produktion übertragen wird.
Das beliebteste Testframework ist die aXe-core- Bibliothek von Deque. Es ist in Lighthouse for Google Chrome, Sonarwhal vom Edge-Team von Microsoft, Ember A11y Testing und mehr integriert.
Hier ist beispielsweise ein Test, bei dem der gesamte Regelsatz für ein Dokument in einem Integrationstest auf Seitenebene ausgeführt wird:
var axe = require('axe-core'); describe('Some component', function() { it('should have no accessibility violations', function(done) { axe.run('.some-component', {}, function(error, results) { if (error) return error; expect(results.violations.length).toBe(0); }); }); });Das Ausführen von Tests führt dazu, dass ein JSON-Objekt mit allem, was Axe-Core gefunden hat, zurückgegeben wird: Arrays von Durchläufen, Verstößen und sogar einer Reihe von "unvollständigen" Elementen, die manuell überprüft werden müssen. Sie können Zusicherungen basierend auf der Anzahl der Verstöße schreiben, was hilfreich ist, um Builds lokal oder in Continuous Integration (CI) zu entsperren.
Sehen Sie sich dieses Beispiel zur Verwendung von ax mit dem Jasmine Unit Testing Framework von Marcy Sutton an.
CI-Umgebungen
Ein Testlauf in Ihrer CI-Umgebung ist eine weitere Methode zur Vermeidung von Regressionen und kann als „letzte Verteidigungslinie“ angesehen werden. Diese Tests werden automatisch ausgeführt, wenn eine Codeänderung aus einer Pull-Anfrage mit dem Master-Branch zusammengeführt werden soll.
Ein Tool, das Sie für diese Art von Tests verwenden können, ist pa11y-ci , das Barrierefreiheitstests für mehrere URLs durchführt und Probleme meldet.