Es gibt viele Möglichkeiten, eine Webseite auf Schwachstellen hinsichtlich der Barrierefreiheit zu untersuchen, unter anderem mit Plugins und Tools. Grundlage für viele Tools sind die WCAG, die Web Content Accessibility Guidelines. Im heutigen Beitrag geht es um Browser-Plugins, die einen Großteil der Fehler bezüglich der Barrierefreiheit auf Webseiten aufdecken können.
Diese Plugins prüfen den HTML-Code einer Webseite zum Teil automatisiert auf Schwachstellen. Doch warum der HTML-Code? Viele assistive Tools navigieren entlang des von der Webseite automatisch erzeugten Barrierefreiheitsbaum, in welchem grob formuliert die Struktur der Webseite bezüglich der Barrierefreiheit enthalten ist. Und wenn dort Fehler enthalten sind, dann führt dies zu Einschränkungen bei der Bedienung.
Neben mehreren Tools zur Analyse bestimmter Aspekte der Barrierefreiheit wie die Kontrastprüfung sind unter anderem die Axe Accessibility Testing Tools beliebt. Auch Google Lighthouse und Wave sind bekannte Tools. Zwei weitere Plugins, IBM Equal Access Accessibility Checker und Microsoft Accessibility Insights for Web, habe ich im Zuge meiner Projekttätigkeit verwendet. Und diese Tools möchte ich folgend näher beleuchten.
IBM Equal Access Accessibility Checker
Beginnen möchte ich mit dem IBM Equal Access Accessibility Checker, welches von mir im aktuellen Projektkontext am meisten verwendet wird. Dieses Browser-Plugin scannt die zu prüfende Seite und stellt gefundene Schwachstellen sowie manuell zu überprüfende Probleme übersichtlich in einer Tabelle dar. Zu jeder Meldung existiert auch eine ausführliche Erklärung, welche Einschränkungen in der Benutzung daraus resultieren, sowie ein Verweis auf die jeweilige Richtlinie. Auch bietet der IBM Equal Access Accessibility Checker ein erweitertes Regelwerk, was neben den WCAG weitere Richtlinien von IBM enthält.
Nicht jede Meldung ist eine Schwachstelle und erfordert daher eine manuelle Überprüfung. Zum Beispiel sollte geprüft werden, ob ein Element mit der Tastatur erreichbar und der sichtbare Fokus dabei klar erkennbar ist. Oder auch die Prüfung der Webseite mittels des Hoch-Kontrast-Modus wird oft als Empfehlung im Tool aufgelistet, da dieser Modus eine komfortable Verbesserung bei unterschiedlichsten Sichtschwierigkeiten bietet. Ohne diesen Hinweis wird dieser Modus des Betriebssystems unter Umständen beim Test auf Barrierefreiheit übersehen.
Im Falle von “false-positive”-Meldungen (gefundene Schwachstellen die keine sind) besteht die Möglichkeit, diese Elemente aus der Liste auszublenden. Dadurch bleibt die Übersicht auf die wahren Probleme bei der Auswertung gewährt. Diese Art von Meldungen sind aber die Ausnahme und zeigt, dass eine manuelle Prüfung der Schwachstellen erfolgen sollte, bevor die Behebung direkt startet.
Standardmäßig werden die Meldungen nach Element-Rollen gruppiert, was vor allem in Bezug auf die einzelnen HTML-Elemente sinnvoll für Entwickler sein kann. Doch ich bevorzuge eine Sortierung nach entweder Requirements oder Rules. Dadurch sehe ich die Art des Fehlers besser gruppiert (fehlender Alt-Text, Kontrast-Schwierigkeiten etc.) und kann dies besser an das ganze Team vermitteln, da jedes Teammitglied über unterschiedliche HTML-Kenntnisse verfügt.
Microsoft Accessibility Insights for Web
Ein anderes Produkt aus dem Bereich statistische Website-Überprüfung stammt von Microsoft und existiert als Browser-Plugin und als Stand-alone-Produkt für die Untersuchung von Apps. Im Folgenden beziehe ich mich nur auf das Browser-Plugin. Hier stehen verschiedene Durchführungsarten zur Verfügung, von einem kurzen Fast Pass hin zu einem längeren Assessment.
In jedem Verfahren erfolgt zunächst eine Analyse des HTML-Codes der Webseite. Daraus werden mehrere gefundene Fehler hinsichtlich der Barrierefreiheit aufgeführt, wie zum Beispiel Kontrastprobleme oder fehlerhafte Bezeichnungen von Eingabeelementen. Es ist vergleichbar mit dem Tool von IBM, nur in einer anderen Darstellung. Danach folgen verschiedene andere Prüfungen.
Im kurzen Fast Pass zum Beispiel folgt die Prüfung der Tastatursteuerung mittels Tab-Taste oder -Pfeiltasten. Hier existiert eine Checkliste, die teilweise automatisiert durch aktives Durchgehen der Webseite als Tester ausgefüllt werden soll. Dabei wird auch beim Durchgehen die Fokus-Reihenfolge auf der zu testenden Webseite visualisiert und dabei mancher Punkt der Checkliste automatisiert ausgefüllt. Sollte das Plugin dabei Fehler merken (Reihenfolge zum Beispiel nicht wie im DOM), werden auch automatisiert Fehler erfasst. Die Antwort in der Checkliste kann aber auch manuell korrigiert beziehungsweise zurückgesetzt werden.
Als letztes werden nochmal einige gefundene Meldungen zum Review vorgelegt, damit Tester/Entwickler entscheiden, welche Probleme angegangen werden müssen und welche nicht. Es sollte also in Ruhe und Konzentration jeder Schritt einzeln durchgegangen werden.
Das Plugin unterstützt den Test auf Barrierefreiheit durch eine gute Anleitung. Im Gegensatz zu anderen Tools wird bei der Evaluierung ein separates Browser-Fenster geöffnet. Dieses kann zum Beispiel auf einen zweiten Bildschirm gelegt werden. Aber es kann auch hinderlich sein, da bei den Checklisten der Blick immer hin und her wandern wird. Auch ist es möglich, aus den einzelnen gefunden Meldungen direkt im GitHub oder AzureBoard Issues anzulegen, was im Projektumfeld bei Verwendung dieser Tools hilfreich sein kann.
Im Allgemeinen
Jedes Tool zur Prüfung von Webseiten auf Barrierefreiheit, hat Vor- und Nachteile. Die Entscheidung für ein Tool ist abhängig vom Projektkontext, den Anforderungen und teilweise auch den eigenen Vorlieben. Zu beachten ist aber, dass manche Fehler im Vergleich bei einem Tool anders oder vielleicht gar nicht erkannt werden. Generell wurden die meisten Fehler von allen von mir erwähnten Tools gefunden.
Obwohl ein teilautomatisiertes Tool einen Großteil an Barrieren findet, sind zusätzliche manuelle Prüfungen notwendig. Diese sollten sich nicht nur auf die explizit als manuell zu prüfenden Aspekte begrenzen, sondern auch die automatisierten Meldungen einbeziehen. Und was auch wichtig ist: mögliche inhaltliche Fehler können nicht oder schlecht von einem Tool bewertet werden. Die Tools sind eine gute Unterstützung für Tester und Entwickler, um einen Großteil von Fehlern hinsichtlich der Barrierefreiheit aufzuzeigen, der manuelle Test bleibt aber nach wie vor notwendig.
Doch welche Tools, nutzt ihr? Seid ihr mit einem Tool besonders zufrieden und wollt dies teilen?
Schreib uns eine Mail – wir freuen uns auf deine Nachricht! hello@qualityminds.de oder auf LinkedIn