Drücke "Enter", um den Text zu überspringen.

Automatische Prüftools für Barrierefreiheit: Was sie können und was nicht

Bisher spielen automatische Prüf-Tools für die digitale Barrierefreiheit eine untergeordnete Rolle. Doch was genau können diese Tools leisten, und wo stoßen sie an ihre Grenzen?

Gefahren und Probleme der Automatisierung

Lassen Sie mich zuerst mit einem Misverständnis aufräumen. Es geht nicht um Mensch oder Automatisierung. Es geht darum, die Automatisierung und meinetwegen KI dort einzusetzen, wo sie sehr gut funktioniert, sie dort kritisch einzusetzen, wo sie noch fehlerhaft ist und sie dort nicht einzusetzen, wo Human Power gefragt ist. Mit den Ansätzen, die wir bisher in der Barrierefreiheit verwendet haben kommen wir im Schnecken-Tempo voran.

Es besteht die Gefahr, dass Kunden und Dienstleister bzw. andere Beteiligte sich allein auf das Tool konzentrieren oder gar dafür optimieren. Davor sollte man als Beraterin stets warnen. Allerdings beruht der Widerstand vieler Consultants wohl eher auf der Furcht davor, dass sie ihren Job durch Automatisierung verlieren. Die Gefahr halte ich aktuell für sehr gering. Kein Tool kann die Erfahrung und Kontext-Analyse ersetzen.

Allerdings ist es tatsächlich sinnvoll, dafür zu sorgen, dass man in den Prüf-Tools grün ist: Viele Massen-Abmahner nutzen etwa Wave, um Klage-Schriften zu erstellen. Mit dem European Accessibility Act wird diese Masche auch in die EU kommen, die Abmahner wetzen bereits ihre digitalen Messer. So unsympathisch nicht-barrierefreie Websites sind, Massenabmahner sind noch einmal ein paar Stufen darunter. Da geht es nicht um die berechtigten Klagen von Individuen oder Interessens-Verbänden.

Automatische Prüf-Tools sind der Anfang. Sie ersetzen weder Know How noch eine gründliche manuelle Prüfung. Aber sie sind ebenso notwendig wie Know How und manuelle Prüfung.

Axe als Basis

Die meisten automatischen Prüf-Tools basieren auf der freien axe-Bibliotehk, nicht zu verwechseln mit dem Tool axe-core, dass von Deque angeboten wird. Die jeweiligen Anbieter können natürlich noch Erweiterungen einbauen, aber axe ist oft die Basis.

Logische und Kontext-Fehler

Automatische Prüf-Tools können ideal logische Fehler finden. Mit logischen Fehlern sind hier Fehler im Code gemeint. Ein logischer Fehler sind fehlende Beschriftungen oder Events, die nur auf Maus-Klick basieren. Ein logischer Fehler ist auch, wenn bei Einsatz von ARIA Attribute gesezt werden, die nicht zum eingesetzten ARIA-Element gehören. Es ist kein logischer Fehler, wenn ich falsche ARIA-Rollen setze, weil die Software nicht erkennen kann, ob die Rolle Link oder Button für das spezifische Element korrekt wäre. Menschen sind eher schlecht darin, logische Fehler zu finden.

Solche Probleme nennen wir Kontext-Fehler, also Fehler, die nur im Kontext gefunden werden können. Ist der Alternativtext, die Überschrift, das Label oder dieses ARIA in diesem Zusammenhang korrekt oder nicht? Das kann aktuell nur ein Mensch herausfinden. Darin sind Menschen den Maschinen deutlich überlegen.

Automatische Prüftools können logischeBarrierefreiheitsprobleme schnell identifizieren. Dazu gehören fehlende Alt-Texte für Bilder, unzureichende Farbkontraste, nicht beschriftete Formularelemente und fehlende ARIA-Attribute.

Die Tools bieten eine schnelle Möglichkeit, eine erste Analyse einer Webseite durchzuführen. Dadurch können Entwickler und Designer sofortige Rückmeldungen erhalten und grundlegende Probleme schnell beheben.

Automatische Tools können regelmäßig eingesetzt werden, um Webseiten kontinuierlich auf Barrierefreiheit zu überprüfen, das sogenannte Monitoring. Dies ist besonders nützlich, um sicherzustellen, dass neue Inhalte und Updates die Barrierefreiheit nicht beeinträchtigen.

Die meisten automatischen Prüftools bieten detaillierte Berichte und Empfehlungen, die Entwicklern helfen, die gefundenen Probleme zu verstehen und zu beheben.

Einsatz-Bereiche für automatische Prüf-Tools

Für das Web sind automatische Prüftools für alle Bereiche von der Konzeption über Design, Entwicklung bis QS und Redaktion vorhanden. Alle verbreiteten Tools wie Figma, Entwicklungs-Umgebungen und Content-Management-Systeme können entsprechend erweitert werden.

Auch ein Bookmarklet ist in gewisser Weise ein automatisches Prüf-Tool, da es Aspekte sichtbar macht, die ansonsten aufwendig im Quellcode oder mit einem Screenreader gesucht werden müssten.

Was automatische Prüf-Tools prüfen können

Es wird gesagt, dass ca. 35 Prozent der WCAG-Kriterien automatisch geprüft werden können. Eine Studie von Deque besagt, dass ca. 57 Prozent der WCAG-Issues gefunden werden können. 78 Prozent der Issues gingen auf nur fünf Kriterien zurück. die folgenden Kriterien seien für 80 Prozent aller Issues verantwortlich:

3.1.1 Language of Page
4.1.1 Parsing
1.4.3 Contrast (Minimum)
2.4.1 Bypass Blocks
1.1.1 Non-Text Content
4.1.2 Name, Role, Value
1.3.1 Info and Relationships
Quelle

Wobei mansagen muss, dass Bypass blocks und Language of parts ziemlich überflüssig sind und Kontraste eine der Schwachstellen der automatischen Prüf-Tools darstellen. Es werden viele falsch-positive und falsch-negative Ergebnisse zu Kontrasten produziert. 4.1.1 ist durch die WCAG 2.2 obsolet. 1.3.1 und 4.1.2 gehören zu den komplexesten WCAG-Kriterien, es ist also nicht verwunderlich, dass hier die meisten Issues auftreten. Deque als führender Anbieter solcher Tools hat natürlich ein Interesse daran, die Prüf-Tools sehr positiv darzustellen.

Denken Sie an die oben gemachte Aussage: Logische Fehler wie eine fehlende Beschriftung oder eine falsch referenzierte ARIA-ID lassen sich leicht finden. Die Maschine erkennt aber noch nicht, wenn das Element eigentlich ein Akkordeon ist und eine falsche ARIA-Rolle gesetzt wurde.

Automatische Tools können zuverlässig überprüfen, ob Bilder auf einer Webseite mit Alt-Texten versehen sind. Alt-Texte sind wichtig, um sicherzustellen, dass Screenreader-Nutzer den Inhalt von Bildern verstehen können.

Diese Tools können die Farbkontraste zwischen Text und Hintergrund analysieren, um sicherzustellen, dass sie den Barrierefreiheitsstandards entsprechen.

Automatische Prüf-Tools können die Struktur des HTML-Codes überprüfen, um sicherzustellen, dass er den Barrierefreiheitsrichtlinien entspricht. Dies umfasst die Überprüfung von Überschriftenhierarchien, Listenstrukturen und anderen semantischen Elementen.

Formularelemente wie Eingabefelder, Dropdown-Menüs und Schaltflächen müssen korrekt beschriftet sein, damit sie von Screenreadern erkannt und interpretiert werden können. Automatische Tools können fehlende oder fehlerhafte Beschriftungen zuverlässig identifizieren.

ARIA Attribute helfen dabei, die Barrierefreiheit von dynamischen Webinhalten zu verbessern. Automatische Tools können überprüfen, ob ARIA-Attribute korrekt verwendet werden und ob sie den Richtlinien entsprechen.

Solche Tools sollten auch immer helfen, den Fehler zu beheben. Das war früher kritisch, da die Fehler sehr kryptisch dargestellt wurden. Einige Tools wie Siteimprove oder Silktide bieten aber teils ausführliche Erklärungen und Hilfen. Der nächste Schritt wäre natürlich, dass Fehler, wenn möglich automatisch repariert werden oder das Vorschläge für richtigen Code gemacht werden, die mit geringem Aufwand übernommen werden können.

Was Automatische Prüftools bisher nicht können

Automatische Tools können die Qualität und Benutzerfreundlichkeit komplexer Interaktionen nicht bewerten. Sie können nicht beurteilen, ob eine Webseite für Nutzer von Screenreadern intuitiv und leicht navigierbar ist oder ob interaktive Elemente wie Dropdown-Menüs und modale Dialoge korrekt funktionieren.

Automatische Prüf-Tools können sowohl falsch-positive als auch falsch-negative Ergebnisse liefern. Das bedeutet, dass sie möglicherweise Probleme identifizieren, die keine sind, oder echte Probleme übersehen. Dies kann zu einer falschen Einschätzung der Barrierefreiheit führen.

Automatische Tools haben Schwierigkeiten, Inhalte im Kontext zu analysieren. Sie können nicht beurteilen, ob ein Video ohne Untertitel für den spezifischen Kontext der Webseite akzeptabel ist oder ob alternative Zugangswege angeboten werden. Kontextbezogene Inhalte erfordern menschliches Urteilsvermögen und Verständnis. In einem konkreten Fall wurde das ARIA-Markup für ein Akkordeon verwendet, korrekt wäre aber das Markup für einen Tool-Tipp gewesen. Eine automatische Prüfung des heutigen Standes könnte nur prüfen, ob das Markup formal korrekt ist, aber nicht, ob es in dem Kontext sinnvoll ist.

Was bringt die Zukunft

Automatische Prüftools zur Barrierefreiheit haben bereits große Fortschritte gemacht, aber es gibt noch viele Möglichkeiten für Weiterentwicklungen. Hier sind einige potenzielle Entwicklungen, die in naher Zukunft erwartet werden könnten:

Durch den Einsatz von fortschrittlicher Künstlicher Intelligenz (KI) und maschinellem Lernen könnten automatische Prüftools in der Lage sein, komplexere Barrierefreiheitsprobleme zu erkennen und zu bewerten. Dies könnte beispielsweise die Erkennung von Mustern und Kontext in Inhalten umfassen, um genauere Bewertungen zu ermöglichen.

Zukünftige Tools könnten fortschrittliche semantische Analysen nutzen, um den Kontext und die Bedeutung von Inhalten besser zu verstehen. Dies könnte ihnen helfen, nicht nur technische, sondern auch inhaltliche und sprachliche Barrieren zu identifizieren und zu bewerten.

Durch die Analyse von Benutzerverhalten und Interaktionsmustern könnten automatische Tools besser verstehen, wie echte Nutzer mit einer Webseite interagieren. Dies könnte ihnen helfen, Probleme zu identifizieren, die durch rein technische Analysen nicht entdeckt werden können.

Fortschritte bei der Simulation von Nutzerinteraktionen könnten es automatischen Tools ermöglichen, realistischere Tests durchzuführen. Dies könnte die Simulation von Screenreader-Nutzern, Nutzern mit motorischen Einschränkungen oder Nutzern, die alternative Eingabemethoden verwenden, umfassen.

Zukünftige Prüftools könnten nahtloser in bestehende Entwicklungsumgebungen und Workflows integriert werden. Dies könnte durch erweiterte APIs, Plugins für gängige Entwicklungsumgebungen und bessere Zusammenarbeitstools erreicht werden, um Barrierefreiheitstests zu einem integralen Bestandteil des Entwicklungsprozesses zu machen.

Neben der Identifizierung von Problemen könnten zukünftige Tools auch automatisierte Korrekturen und konkrete Handlungsvorschläge bieten. Dies könnte Entwicklern helfen, Barrierefreiheitsprobleme schneller und effizienter zu beheben.

Fortschritte in der Personalisierung könnten es ermöglichen, dass Prüftools Tests an die spezifischen Bedürfnisse und Fähigkeiten der Nutzer anpassen. Dies könnte durch die Erstellung von Nutzerprofilen und die Anpassung der Testmethoden an verschiedene Benutzergruppen erreicht werden.

Zukünftige Tools könnten eine Echtzeit-Überwachung und -Berichterstattung bieten, um sicherzustellen, dass Webseiten und Anwendungen kontinuierlich barrierefrei bleiben. Dies könnte durch die Integration von Überwachungstools und Dashboards erreicht werden, die Entwicklern und Designern sofortige Rückmeldungen geben.

Zum Weiterlesen