Hauptinhalt

Barrierefreiheit prüfen, Barrierefreiheit messen – Web Accessibility Metrics

24. Oktober 2011 von Kerstin Probiesch in: Barrierefreiheit, BITV, Testverfahren, Web 2.0

Mit Fragen und Aspekten zum Messen der Barrierefreiheit beschäftigt sich am 5. Dezember 2011 ein Symposium des World Wide Consortiums (W3C). Abgehalten wird es in Form einer Telefonkonferenz.

Das “Messen bzw. Testen von Barrierefreiheit” geht weit über die oft zu Recht geschmähten “Checklisten” hinaus. Wer sich jemals mit Testtheorie und Gütekriterien für Testverfahren beschäftigt (hat), weiß: mit einer bloßen Checkliste ist es nicht getan. Leider werden Tests auf Barrierefreiheit oft allein aus pragmatischen Gesichtspunkten heraus betrachtet. Dazu gehören etwa “Praxistauglichkeit”, z.B. zeitliche Länge, oder und damit verbunden wie viel ein Kunde evtl. bereit wäre zu zahlen. Solche Kriterien sind zwar berechtigt, aber keine Hauptgütekriterien standardisierter Testverfahren. Sie zäumen quasi das Pferd von hinten auf; bedeutsam werden sie erst, wenn die folgenden drei Hauptgütekriterien von Testverfahren – zumindest wenn es um standardisierte Tests geht – erfüllt sind:

  • Objektivität: Das Testergebnis darf nicht von der Person des Testers abhängen. Entsprechend wird ein standardisierter Test z.B. Subjektivität und Interpretationen so weit es geht kontrollieren.
  • Reliabilität: Mehrere Tester kommen bei Verwendung des gleichen Tests unabhängig voneinander zum gleichen Ergebnis (deutsch: Zuverlässigkeit)
  • Validität: Der Test misst das, was er messen soll. Dies gilt auch für die einzelnen Items.

Diese drei Hauptkriterien lassen sich ihrerseits weiter unterteilen. So wird Objektivtät noch einmal unterteilt in u.a. “Durchführungsobjektivität” und “Interpretationsobjektivität”. Ist eines der drei Hauptkriterien nicht erfüllt, dann kann nicht mehr von einem standardisierten Testverfahren gesprochen werden.

Webentwickler kennen z.B. Validität eher im Zusammenhang mit validem Code als mit testtheoretischen Überlegungen. Deswegen ein Beispiel: Prüft man eine Webseite mit dem W3C-Validator als Testinstrument, dann misst dieser, ob der Quellcode der festgelegten Spezifikation der im DOCTYPE angegebenen HTML-Version folgt. Diese Spezifikation ist ein international gültiges, normatives Konzept. Stellt der Validator Fehler fest, dann ist der Quellcode und damit die Webseite nicht valide. So weit, so trivial.
Nun wäre es durchaus möglich, eine eigene – und damit subjektive – HTML-Version zu entwickeln und auf dieser Basis einen eigenen Validator. Würde man eine Webseite anhand nach dieser HTML-Version umsetzen und mit diesem Validator prüfen, dann würde dieser nicht “meckern”. Der Quellcode wäre valide – aber natürlich nur gegenüber der eigenen, subjektiven “Spezifikation”.

Würden weitere Webentwickler Webseiten nach dieser erfundenen HTML-Version umsetzen und mit diesem Validator prüfen, dann erhielten sie die gleichen Ergebnisse. Der Test und seine Ergebnisse wären zwar durchaus reliabel, aber nicht objektiv und valide gegenüber internationalen anerkannten Spezifikationen. Selbstverständlich prüft man als Webentwickler nicht eigene Spezifikationen sondern international gültige, normative Konzepte.

Auch für Barrierefreiheit gibt es normative Konzepte. Sie sind Teil der Web Content Accessibility Guidelines 2.0 (WCAG 2.0), zu ihnen gehören die Konformitätsbedingungen und die Erfolgskriterien. Nicht-normativ hingegen sind z.B. die Techniken (How to meet). Schaut man sich das Verhältnis von Erfolgskriterien und Techniken, dann geht es stets darum, ob ein Erfolgskriterium (normativ) erfüllt ist und nicht, ob eine bestimmte Technik (nicht-normativ) verwendet wurde.

Selbstverständlich sind die Techniken wichtig. Sie zeigen Webentwicklern sichere Techniken für die Erfüllung eines Erfolgskriteriums auf (Sufficient Techniques) und oft sind es mehrere Techniken mit denen ein Erfolgskriterium erfüllt werden kann. Je nach Vorliebe, Projekt, Nutzer- oder Kundenwunsch ist es möglich, eine bestimmte Technik vor einer anderen zu favorisieren – solange das Erfolgskriterium erfüllt ist.

Dieser pragmatische Ansatz ist jedoch streng vom Testen zu trennen. Denn: Würde man (favorisierte) Techniken testen, dann würde man nicht mehr messen, was gemessen werden soll (das normative Erfolgskriterium), sondern eben nur ob (die) Techniken verwendet wurden, die man selber favorisiert. Letztlich würde dies wohl dem obigen Beispiel entsprechen: dem Testen einer eigenen “Spezifikation”. Ob die Ergebnisse gemessen an den normativen Konzepten der Barrierefreiheit nach WCAG 2.0 noch valide und objektiv wären, selbst wenn sie reliabel wären, wäre mehr als fraglich.

Daraus lässt sich eine der wichtigsten Regeln für das Testen von Barrierefreiheit ableiten: Teste stets die normativen Erfolgskriterien (in der BITV 2.0 “Bedingungen”) und nicht die nicht-normativen Techniken!

Soweit ein mehr als kurzer Ausflug in die Testtheorie. Man darf gespannt auf das W3C-Symposium sein. Ich erhoffe mir nützliche Einsichten in dieses komplexe Thema und natürlich interessante Testansätze und Vorträge über Gütekriterien für Testverfahren im Lichte der normativen Erfolgskriterien und Konformitätsbedingungen der WCAG 2.0.

Weitere Informationen zum Online Symposium on Website Accessibility Metrics.

Kommentare und Pings sind derzeit nicht erlaubt.

2 Reaktionen zu “Barrierefreiheit prüfen, Barrierefreiheit messen – Web Accessibility Metrics”

  1. Diana Ruth-Janneck

    Danke für diese übersichtliche und prägnante Unterscheidung der Testtechniken und Kriterien und der zugehörigen Dokumente der WCAG 2.0. Diese Dinge sind enorm wichtig beim Testen auf Barrierefreiheit, werden aber leider immer wieder vernachlässigt.
    Im allgemeinen ist es halt doch meistens eine (automatische) Checkliste und alle (im Entwicklungsteam) sind glücklich über ein “pass”. (O-Ton: Wir lassen mal noch schnell nen Checker rüberlaufen. – Oh prima, bestanden. dann sind weitere Tests ja nicht notwendig…) Is halt leider noch nicht bei allen angekommen, was wirklich aussagekräftige Tests sind.
    Viele grüße
    Diana

  2. Markus Lemcke

    Ich habe mal begonnen eine Software zu entwickeln, die eine Webseite auf Barrierefreiheit prüft. Ob Bilder einen Alternativtext haben, läßt sich Software-Technisch lösen. Ob die Schriftart mit dem Font-Tag definiert wird oder per CSS läßt sich ebenfalls Software-Technisch lösen, die Verwendung von Frames auch, aber spätestens bei der Überprüfung auf einfache Sprache hört es auf!

    Die CSS-Datei müsste auch software-technisch überprüft werden um herauszufinden ob feste oder relative Schriftgrößen verwendet werden.

    Ich wäre dafür, dass Menschen mit Handicap als “qualifizierte” Testfachkräfte hierfür eingesetzt werden.

    Viele Grüße

    Markus Lemcke