Direkt zum Inhalt

Barrierefreiheitstests – automatisiert, manuell, egal?

Tests auf Barrierefreiheit kommen in allen Formen und Farben. Aber nicht jede Art zu testen ist umfassend genug, um die Zugänglichkeit eines Webauftritts einschätzen zu können.

Ob aus Überzeugung oder aufgrund von gesetzlichen Vorgaben – das Thema Barrierefreiheit ist zur Zeit in aller Munde, und dieser Effekt wird sich bis mindestens 2025 noch verschärfen. Ab dann sind unter anderem der Banken und E-Commerce-Sektor durch das „Barrierefreiheitsstärkungsgesetz“ verpflichtet, ihre Inhalte und Funktionen zugänglich bereitzustellen. Viele Unternehmen und Mitglieder des öffentlichen und privaten Sektors schauen sich spätestens dann das Thema zum ersten Mal oder zum ersten intensiven Mal an.

Wenn sie über das Wort „Barrierefreiheit“ stolpern, dann finden sie zumindest im deutsprachigen Raum ein Absolutum vor, nämlich einen Zustand der vollkommenen Abwesenheit (oder eben Freiheit) von Barrieren. Dieser Begriff kann deswegen für mehr Bauchgegrummel sorgen als es unbedingt nötig ist. Etwas schwächer sollte das etwaige Angstgefühl dann ausfallen, wenn man bemerkt, dass der Begriff in vielen anderen Sprachen mit - in etwa - Zugänglichkeit übersetzt ist.

Aber unabhängig von genauen Begrifflichkeiten stellt sich die Frage, wie Barrierefreiheit (oder Zugänglichkeit) eigentlich zu messen ist. Wann kann man sicherstellen, dass beispielsweise eine Website mit keinerlei Barrieren für niemanden aufwartet - ungeachtet seiner oder ihrer Fertigkeiten, Nutzungsstrategien oder Hilfstechnologien?

Die Antwort ist: man kann es nicht sicherstellen. Das soll aber niemanden davon abhalten, es zu versuchen! Und das soll ebenfalls niemanden davon abhalten, eine „Baseline“ zu erreichen: einen gewissen Stand an Barrierefreiheit oder einen gewissen Grad der Abwesenheit von immer wieder auftauchenden typischen Barrieren. Diese Baseline findet sich zum Beispiel in Jahrzehnten gereiften technischen Standards zur Web-Barrierefreiheit wie den Web Content Accessibility Guidelines (WCAG).

Aber noch einmal zurück zur Frage, dieses Mal angepasst: wie ist denn wenigstens diese Baseline sicherzustellen? Die Antwort: In dem man den technischen Standard zur Barrierefreiheit (faktisch die WCAG) intensiv betrachtet. Dann wird man feststellen, dass sie in Form von einzeln überprüfbaren Testschritten, den sogenannten Erfolgskriterien, formuliert ist. Daraus folgt, dass beim Erfüllen all dieser Testschritte eine Konformität mit dem technischen Standard attestiert werden kann. Webauftritte mit einem technischen Standard abzugleichen nennt sich „Konformitätstest“.

Noch besser als ein Konformitätstest ist natürlich, sowohl gegen Standards als auch mit menschlichen Teilnehmern zu testen, um mehr über ihr Benutzungserlebnis zu erfahren und das Bild abzurunden. Im Idealfall sind dies typische Nutzerinnen und Nutzer des Webprojektes, mit und ohne Behinderungen. Und im Idealfall ergänzt eine solche sogenannte heuristische Testreihe bereits durchgeführte Konformitätstests und tilgt weitere Barrieren.

Daneben gibt es eine weitere Art zu testen, die in den letzten Jahren immer besser, bekannter und - ja - zugänglicher geworden ist: das sogenannte automatische Testen von Barrierefreiheit. Entweder in Form einer Browsererweiterung oder durch Ausführen eines Skripts in der Konsole des Rechners. Auf jeden Fall aber programmcode-basiert und deswegen mit allen Vorteilen einer automatisierten Lösung gesegnet: In Sachen Geschwindigkeit, Gründlichkeit und Komfort schlägt die Maschine den Mensch um Längen.

Ergibt sich daraus, dass man Konformitätstest also automatisiert durchführen sollte? Die Antwort ist ein beherztes: Jein. Während automatisierte Tests neben den bereits genannten Vorteilen vor allen niedrigschwellig und für Erstanalysen oder automatisierte Testinfrastrukturen auf jeden Fall hilfreich sind, reichen sie aber nicht aus, um eine abschließende Aussage zu treffen, ob ein Webprojekt barrierefrei (oder genauer: mit einem technischen Standard konform) ist. Und das liegt an folgenden Gründen:

Automatisierte Tests sind per Definition limitiert, da ein Teil der Prüfschritte menschliches Urteilsvermögen erfordert. Manchmal geht es in WCAG-Prüfschritten nicht nur darum zu kontrollieren, ob eine Eigenschaft existiert oder nicht (das ist ein perfekter Job für eine Maschine). Häufig sollen sich Tester*innen auch die Frage stellen, ob Inhalte verständlich, hilfreich oder adäquat sind. Kurz: es wird ein Urteil verlangt, dass menschliche Betrachtung erfordert, Nuancen erkennt und den Kontext berücksichtigen muss. Hier ein paar weitere Beispiele:

  • Ob Überschriften und Beschriftungen in einem Dokument existieren kann automatisiert überprüft werden. Ein Urteil darüber fällen, wie sinnvoll diese Bezeichner sind, kann eine Maschine nicht. Es benötigt einen Menschen, um festzustellen, ob diese Texte letztendlich anderen Menschen beim Verständnis des Webdokuments helfen oder nicht (Mehr Informationen zum Prüfschritt).
  • Auch „sinnvolle Reihenfolgen“ – sei es der Inhalte oder z. B. der Tastaturreihenfolge – lassen sich nicht abschließend maschinengestützt beurteilen. Eine durch Hilfsprogramme bessere Visualisierung von beispielsweise Tab-Reihenfolgen ist dennoch eine Erleichterung beim manuellen Testen. Aber hier ist die Maschine mehr das Stützrad, das jedoch das gesamte Fahrrad nicht ersetzen kann.
  • Thema „sinnvolle Alternativtexte“: ein Check auf die alleinige Existenz von Alternativtexten allein genügt im entsprechenden Prüfschritt nicht. WCAG 1.1.1 verlangt einen äquivalenten Alternativinhalt für Inhalte, die kein Text sind. Diese Einschätzung kann ein Automat nicht vornehmen, zumal die Nuancen selbst unter menschlichen Expert*innen für Diskussionen sorgen.
  • Der aktuellen Technik fehlt ein Textverständnis, sodass sie nicht erkennen kann, ob in Text auf sensorische Eigenschaften verwiesen wurden. Ein Satz wie „klicken sie den runden grünen Schalter oben rechts“ hilft nicht jedem Nutzenden weiter. Menschen mit Sehbehinderungen sind bei solchen Verweisen häufig ausgeschlossen, sodass es einen eigenen Prüfschritt gibt, der auf diesen Sachverhalt zielt (1.3.3)
  • Bei „sinnvollen Fehlertexten“ verhält es sich ähnlich wie bei WCAG 1.1.1 (den Alternativtexten). Es ließe sich mit automatischen Mitteln zwar prüfen, ob es eine Fehlerbehandlung bei Formularen gibt - allerdings nicht, wie hilfreich etwaig erscheinende Fehlertexte sind. Den Macher*innen der WCAG war diese potentielle Hürde bzw. Hilfestellung Prüfschritt 3.3.3 wert.

Es ist sowohl Konsens unter Web-Barrierefreiheits-Spezialist*sinnen als auch das Ergebnis einer entsprechenden Studie, dass automatisierte Tests nur etwa 30% bis 40% der für WCAG-Konformität nötigen Tests überhaupt durchführen kann. Ihr Testergebnis, in Ampelfarben oder Punktesystemen zusammengefasst, hat also eine gewisse Aussagekraft, kann aber auch bei "grünem Licht" und „attestierter Fehlerfreiheit“ keine Konformität mit der WCAG belegen.

Ein Problem ist nun, dass diese Arten von Testungen für unkundige Kundinnen und Kunden nicht (schnell) zu unterscheiden ist, denn alle heißen – korrekterweise – „Web-Barrierefreiheitstests“. Darüber hinaus hat die aktuelle Version der WCAG die Eigenschaft, dass bei Nichterfüllen nur eines der Testschritte eine Standard-Konformität des Webauftritts nicht mehr attestiert werden kann. Und in oben stehender Liste sehen Sie gleich mehrere Sachverhalte, die gar nicht automatisch geprüft werden können.

Wenn Anbietende also etwaig unwissenden Kundinnen und Kunden für unverhältnismäßig viel Geld einen Barrierefreiheitstest berechnen, der aber „nur“ aus automatisierten Tests besteht, besteht beim Erfüllen aller Testschritte die Gefahr, dass sich die auftraggebende Stelle in falscher Sicherheit wiegt. Dass nämlich ein Bestehen einer Untermenge von Erfolgskritierien (nämlich denen, die automatisiert getestet werden können) mit dem Bestehen des technischen Standards verwechselt wird.

Was können Sie aus diesem Text mitnehmen?

Wenn also ein Barrierefreiheitspezialist auf Sie zukommt und einen Barrierefreiheits-Test anbietet, ist dies zu begrüßen. Wie schon eingangs beschrieben ist mehr Aufmerksamkeit für das Thema grundsätzlich ein gutes Zeichen. Erkundigen Sie sich aber, was Sie für Ihr Investment in diesem Test bekommen. Fragen Sie nach – seriöse Anbieter*innen haben kein Problem, Ihnen wahrheitsgemäße und transparente Antworten zu geben. Zentral ist die Frage nach der Testart. Zahlen Sie für…

  • einen rein automatisierten Test?
  • einen Test auf WCAG-Erfolgskritierien (somit also einen menschlich geführten Test)?
  • eine Kombination aus einem Konformitätstest und ausdrücklicher Einbeziehung von Menschen mit Behinderung?

Damit wir uns nicht missverstehen: keiner dieser Testarten ist schlecht. Kritisch wird es aber, wenn auf Anbieterseite Ettikettenschwindel betrieben wird, um auf der Barrierefreiheitswelle zu surfen und um sich eine goldene Nase zu verdienen.

Erlauben Sie mir zum Abschluss einen leider noch aktuellen Vergleich: Wenn sie bei einer nicht-staatlichen Teststation einen PCR-Test zahlen und versprochen bekommen, aber nur ein Schnelltest (Antigentest) gemacht wird, fühlen Sie sich ja auch zurecht über's Ohr gehauen.

Aktualisierung 21.06.2022

Wolfgang Wiese war auf Twitter so nett, ein paar sinnvolle Ergänzungen zu diesem Artikel vorzuschlagen. Er sprach zwei wichtige Aspekte an, auf die ich ursprünglich nicht eingegangen bin – die aber zu einer Betrachtung des Themas gehören:

  1. Die Qualifikation des Prüfenden: Ist man daran interessiert, eine möglichst neutrale Aussage über den Stand der Barrierefreiheit zu bekommen, muss man sicherstellen das er oder sie überhaupt das notwendige Know-How mitbringt. Das Thema „Zertifikate“, insbesondere im Zusammenhang mit dem Berufsverband IAAP ist besonders in 2022 ein heikles, und ein Wimpel als „Web Accessibility Specialist“ bescheinigt zunächst einmal nur, dass man eine Prüfung bestanden hat. Eine recht anspruchsvolle Prüfung allerdings. Nur für Deutschland gesprochen ist der Status als BIK BITV-Prüfstelle (die mit dem BITV-Test, unter anderem) sicherlich ein gewisses Qualitätsmerkmal, da das BIK-Team u. a. durch einen Qualifizierungsprozess sicherstellt, dass die anfragende Person fachlich in den Prüfverbund passt.
  2. Automatisierte Test haben den Vorteil einer Dauerüberwachung einer Vielzahl von Seiten und sogar PDFs. Als manuell Prüfende(r) muss man sich aus logistischen Gründen auf eine Seitenauswahl beschränken – die aber nicht subjektiv ausgewählt sein sollte. Die Qualitätssicherung des BIK BITV-Tests stellt dies zum Beispiel sicher. Und auch die WCAG-EM (Website Accessibility Conformance Evaluation Methodology, https://www.w3.org/TR/WCAG-EM/) erfordert in Schritt 3 ein „Representative Sample“.
  3. Die Gefahr von Gefälligkeitsgutachten. Aber hier hat Wolfgang Recht: Das ist eigentlich ein Artikel für sich.

Das kann ich (u.a.) für Sie tun

Interesse geweckt?

Sie haben ein Projekt, bei dem ich weiterhelfen kann?

Stellen Sie hier eine unverbindliche Preisanfrage