|

Tools für Accessibility-Testing

Um das Thema Barrierefreiheit in Webapplikationen drehte sich das zweite Frontend Rhein-Neckar Meetup bei UEBERBIT am 25. Juli 2018. In dieser zusätzlichen Artikelserie wollen wir das Thema nochmal aufgreifen und umfassend betrachten.

Über die unterschiedlichen Formen von Barrieren hat mein Kollege Florian bereits in seinem Artikel "Barrierefreiheit im Web für alle!" geschrieben.

Im anschließenden Artikel "CASE Study: Barrierearmes mannheim.de" hat mein Kollege Alexander anhand von mannheim.de eine Case Study vorgestellt, bei der wir die Ergebnisse eines BITV-Test für die Optimierung genutzt haben.

In diesem Post werde ich zeigen, welche Tools wir bei Projekten verwenden, um die Barrierefreiheit zu prüfen und die meisten Probleme automatisiert zu diagnostizieren.

Browser, CLI, standalone

Die aktuellen Browser bringen von Haus aus bereits einige eingebaute Lösungen mit, womit man Webseiten auf Probleme bei der Barrierearmut testen kann.

Das bekannteste ist hier Lighthouse von Google, das unter anderem als eigenständiges Tool, Webservice sowie als Audit im Browser und als Browserextension verfügbar ist.

webhint (bislang bekannt als sonarwhal) ist eine alternative Lösung, die aktuell von der Community stark erweitert wird und für eigene Hints bzw. Regeln genutzt werden kann und die Überprüfung von Performance-Budgets einfacher macht.

aXe bietet eine Sammlung von Implementierungen zur Überprüfung der Barrierefreiheit und wird in Experten-Kreisen oft verwendet und empfohlen.

Eine weitere ähnliche Lösung ist WAVE, womit ebenfalls viele Sachen überprüft werden können und oft zusätzlich zu aXe verwendet wird.

Daneben gibt es noch viele weitere Lösungen wie Bookmark-Scripte und Libraries, darunter pa11y, Koa11y, a11y.css, revenge.css und tota11y, womit entdeckte Probleme visuell sichtbar gemacht werden.

Audits mit Lighthouse durchführen

Nachfolgend als konkretes Beispiel, wie man mit Yarn oder npm einfach Lighthouse installieren und verwenden kann.

Zuerst müssen wir Lighthouse global installieren:

yarn global add lighthouse
npm i -g lighthouse

Anschließend führen wir einen Audit mit den Standard-Einstellungen durch und wollen nach Abschluss direkt den generierten Report sehen:

lighthouse https://google.com --view

Man kann sehr viele verschiedene Sachen testen und es geht noch granularer als im Browser bzw. der Implementierung mit einer Oberfläche.

Die gesamte Liste der verfügbaren Audits können wir ganz einfach einsehen:

lighthouse --list-all-audits

Wollen wir zum Beispiel nur die Barrierefreiheit testen, können wir dies folgendermaßen durchführen:

lighthouse https://google.com --only-categories accessibility --view

Dies soll auch nur ein ganz kurzer Einstieg sein. Man kann über die Lighthouse-CLI sehr viele Optionen konfigurieren, Performance-Budgets definieren und diese für Audits verwenden, verschiedene Geräte und Netzwerk-Qualitäten simulieren und noch vieles mehr.

Folgende Guides können genutzt werden, um Barrierefreiheit anhand verständlicher Informationen bei Projekten anzuwenden:
http://a11y-style-guide.com/style-guide/
https://a11yproject.com/
https://www.accessibility-developer-guide.com/
https://developer.mozilla.org/en-US/docs/Web/Accessibility
https://developers.google.com/web/fundamentals/accessibility/
https://www.ibm.com/able/guidelines/web/ibm508wcag.html
https://webaim.org/standards/wcag/checklist
https://www.wuhcag.com/wcag-checklist/

Die offiziellen Standards und Referenzen sind oft auch sehr hilfreich und enthalten auch konkrete Code-Beispiele, die man direkt verwenden kann:
https://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixB.html
https://www.w3.org/TR/WAET/
https://www.w3.org/WAI/WCAG21/quickref/
https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0
https://www.w3.org/WAI/tutorials/
https://www.w3.org/standards/webdesign/accessibility

Und abschließend noch einige Listen und eine Sammlung von relevanten opensource Projekten:
https://github.com/brunopulis/awesome-a11y
https://github.com/ryanmagoon/awesome-a11y
https://github.com/collections/web-accessibility

Die Slides von meinem Talk gibt es hier.

Abschließend noch folgender Rat: kein Tool kann 100% der gesamten Standards prüfen und es ist oft hilfreich mehrere Tools zu verwenden. Noch besser als die Tools sind in der Praxis aber auf jeden Fall die eigene (gesammelte) Erfahrung und echte Personen als Tester.