Warum automatisierte Barrierefreiheitsprüfungen nicht genug sind

Wenn wir bei b13 Analysen auf Barrierefreiheit durchführen, liegt unser Hauptfokus auf manuellem testen. Natürlich nutzen wir auch automatische Test-Tools wie Axe oder Wave in unserem Workflow. Diese Tools sind super und helfen uns die häufigsten Verstöße gegen die WCAG-Kriterien schnell zu finden und ein Gefühl für die Barrierefreiheit der Webseite zu bekommen.

Automated tools for accessibility testing

Axe oder Wave sind gute Werkzeuge, um bestimmte Probleme wie 

• leere Links und Buttons
• fehlende Alt-Texte bei Bilder
• Elemente mit falschen oder fehlendem Fokus
• ungültige Formulare
• fehlende Formular-Labels
• zu geringen Farbkontrast 

zu finden. Kurz gesagt: Sie entdecken die häufigsten Probleme, die laut dem WebAIM Million Report auf fast 96 % aller Websites vorkommen.

Wenn Zeit und Budget eine Rolle spielen und man schnell etwas für die Barrierefreiheit einer Website tun will, sind automatisierte Test-Tools eine gute Lösung. Aber reicht das aus, um wirklich alle Barrierefreiheitsprobleme zu beheben? Wenn man diese Tools nutzt und die häufigsten Probleme behebst, ist man dann auf der sicheren Seite und braucht keine manuellen Tests mehr?

Leider nein. Automatisierte Tests decken je nach Quelle nur 20 bis 30 % aller WCAG-Probleme ab. Gen Herres hat eine Studie von Deque zusammengefasst (das Unternehmen hinter Axe), die zeigt, dass Axe nur 15 von 50 WCAG-Erfolgskriterien testen kann – also etwa 30 %.

Melwyn Joseph hat mehrere Studien analysiert und kommt zu einer ähnlichen Schlussfolgerung:

Adrian Roselli hat selbst eine Studie durchgeführt, in der er alle anwendbaren Erfolgskriterien manuell getestet und automatisierte Tools verwendet hat. Dabei kam er sogar auf noch niedrigere Zahlen. Aber er vermittelt auch eine wichtige Lektion:

Die Limits von automatisieren Tools:

Warum können automatisierte Tools nicht eine höhere Abdeckung erreichen? Das Hauptproblem bei Tools wie Axe oder Wave ist, dass ihnen der Kontext der Seite und der Nutzerinnen und Nutzer fehlt. Sie können nur den Code der aktuellen Seite prüfen, aber nicht, wie sich die Seite je nach Viewport, Orientierung oder Größe verändert.

1.1.1 Nicht-Text-Inhalt

• Automatisierte Tools sind super, wenn es darum geht, festzustellen, ob Bilder überhaupt einen Alt-Text haben – das wurde ja bereits erwähnt. Aber Alt-Text ist mehr als nur eine Ja-oder-Nein-Frage. Es geht nicht nur darum, ob ein Alt-Text existiert, sondern auch darum, ob er sinnvoll ist und sich im Kontext einfügt.
• Automatisierte Tools können nicht beurteilen, ob ein vorhandener Alt-Text tatsächlich sinnvoll ist. Sie erkennen zwar, dass ein Alt-Text existiert, aber nicht, ob er den Inhalt und die Bedeutung des Bildes richtig beschreibt.
• Ebenso können sie nicht feststellen, ob ein Bild rein dekorativ ist – in solchen Fällen wäre ein leerer alt=""-Text die korrekte Lösung. Ohne menschliches Verständnis für den Kontext bleibt diese Entscheidung außerhalb der Möglichkeiten automatisierter Tests.

1.2.2 Untertitel

• Untertitel sind für gehörlose Menschen essenziell, wenn sie ein Video anschauen. Automatisierte Tools können zwar erkennen, ob eine Videodatei eine Untertitelspur enthält, aber sie können nicht bewerten, ob diese Untertitel tatsächlich sinnvoll, hilfreich oder verständlich sind.

1.3.1 Info und Beziehungen

• Bei diesem Erfolgskriterium geht es um die korrekte Nutzung von HTML-Elementen. Es geht darum, Überschriften als Überschriften, Tabellen als Tabellen, Absätze als Absätze, Listen als Listen, Blockzitate als Blockzitate usw. zu kennzeichnen. Automatisierte Tools können nicht erkennen, ob bestimmte Informationen besser als Tabelle statt als Textblock dargestellt werden sollten oder ob ein Textblock besser als geordnete Liste angezeigt werden sollte. Menschen können das, weil sie den Kontext des Inhalts bewerten können.

1.4.3 Kontrast (Minimum)

• Automatisierte Tools können erkennen, ob der Farbkontrast eines Elements unzureichend ist.
• Aber sie haben immer noch große Probleme, dies bei halbtransparenten und verlaufenden Hintergründen korrekt zu bestimmen.

2.1.1 Tastatur(bedienung)

• Automatisierte Tools können möglicherweise erkennen, ob Elemente fokussierbar sind (2.4.7) und ob der Fokus für Nutzerinnen und Nutzer sichtbar ist.
• Aber sie können nicht feststellen, ob eine gesamte Website vollständig mit der Tastatur bedienbar ist. Das geht nur durch manuelle Überprüfung.

2.4.2 Seite mit Titel versehen

• Automatisierte Tools können überprüfen, ob eine Website einen Seitentitel hat.
• Aber bei diesem Kriterium geht es nicht nur darum, überhaupt einen Titel zu haben, sondern darum, dass der Titel auch aussagekräftig und sinnvoll ist.

2.4.3 Fokus-Reihenfolge

• Die Art und Weise, wie Nutzende mit einem Screenreader Inhalte lesen, kann sich von der Lesereihenfolge sehender Nutzerinnen und Nutzer unterscheiden. Automatisierte Tools können die korrekte Fokus-Reihenfolge nicht erkennen, da ihnen der Kontext fehlt.

3.2.1 Bei Fokus, 3.2.2 Bei Eingabe

• Diese Erfolgskriterien betreffen unerwartete Kontextwechsel. Wenn ein Element fokussiert oder eine Einstellung geändert wird, sollte sich der Kontext nicht verändern, es sei denn, die Nutzerinnen und Nutzer werden vorher klar über dieses Verhalten informiert. Solche unerwarteten Änderungen können zu einer hohen kognitiven Belastung und Verwirrung führen – etwas, das automatisierte Tools überhaupt nicht testen können.

3.3.3 Fehlerempfehlung

• Wenn man ein Formular ausfüllt und eine Fehlermeldung erscheint, sollte diese klar und verständlich sein, damit man seine Eingabe korrigieren kann. Wie sollen automatisierte Tools das testen? Es geht wieder um den Kontext – und diese Tools können nicht prüfen, ob Fehlermeldungen wirklich hilfreich sind oder nicht. Das können nur Menschen.

4.1.2 Name, Rolle, Wert

• Automatisierte Tools können überprüfen, ob Komponenten WAI-ARIA-Rollen und -Eigenschaften haben. Das hilft Screenreader-Nutzenden, die Elemente besser zu verstehen.
• Aber sie können nicht vollständig simulieren, wie ein echter Screenreader genutzt wird. Das bedeutet, dass das Hinzufügen der richtigen WAI-ARIA-Rolle zwar den Axe-Report zufriedenstellt, aber trotzdem möglich ist, dass Screenreader-Nutzeende diesen Teil der Website nicht bedienen können.

Das ist nur ein kleiner Ausschnitt der Erfolgskriterien, die automatisierte Tools nicht testen können. Leider ist die Liste noch viel länger. Das Wichtigste ist: Wenn etwas barrierefrei sein soll, aber dafür Sinnhaftigkeit oder den richtigen Kontext benötigt wird, sind automatisierte Tools dafür nicht geeignet – das kann nur manuelles Testen.

Was ist nun das Fazit?

Automatisierte Tests sind ein wertvolles Werkzeug – sie sind schnell, kostengünstig und helfen, häufige Barrierefreiheitsprobleme zu erkennen. Aber Barrierefreiheit zu verbessern ist keine einfache „Quick Fix“-Lösung.

Wie bereits gezeigt, können automatisierte Tests nicht alle WCAG-Verstöße erfassen und auch nicht sicherstellen, dass eine Website wirklich barrierefrei ist. Deshalb ist eine effektive Teststrategie eine Kombination aus automatisierten und manuellen Tests.

Beide Methoden ergänzen sich:

• Automatisierte Tests sind schnell, aber übersehen viele kritische Probleme.
• Manuelle Tests sind gründlich, aber teuer und zeitaufwendig.

Durch die Kombination beider Ansätze lassen sich genauere Testergebnisse erzielen und die meisten WCAG-Verstöße identifizieren.

Aber wir dürfen nicht vergessen: WCAG-Konformität ist nur das Minimum. Die Einhaltung der Richtlinien bedeutet nicht automatisch, dass eine Website für alle Menschen wirklich barrierefrei ist.