Wie ich im letzten Beitrag kurz angerissen habe, gibt es Berührungspunkte von Benutzerfreundlichkeit und Barrierefreiheit. Die Begriffe sind aber alles andere als deckungsgleich. Eine Seite, die für einen Blinden wunderbar zu benutzen ist, kann für einen Sehenden unbenutzbar sein, Eine Flash-Site hingegen ist für einen Blinden nicht zu gebrauchen und für den Sehenden meistens ein Greuel, obwohl er sie wahrscheinlich benutzen kann.
Machbarkeit
Im Prinzip spricht nichts dagegen, mit Menschen mit Behinderungen Usability-Tests durchzuführen. Den Schwerpunkt würde ich dabei auf Menschen mit geringer oder mittlerer Internet-Affinität legen, denn die anderen können auch in schwierigen Situationen zurechtkommen. Wenn die internet-afinnen Personen nicht mit der Seite arbeiten können, kann die Seite hingegen als unbenutzbar für die ganze Gruppe gelten.
Die Barrierefreiheit legt einen starken Schwerpunkt auf die Verbesserung der Benutzbarkeit und weniger auf die Benutzerfreundlichkeit. Alle Testverfahren, ob automatisch oder durch menschliche Tester durchgeführt, prüfen daher nach formalen Kriterien. Wenn diese Kriterien erfüllt sind, kann man den Grad der Barrierefreiheit bewerten. Aspekte der Benutzerfreundlichkeit ließen sich auch in diese Tests aufnehmen, sie spielen aber zumindest in den mir bekannten Testverfahren keine Rolle.
Usability-Probleme
Nehmen wir als Beispiel ein Formular. Ein Formular kann neben dem Label auch eine Vorbelegung haben. Es kann dem Screenreader-Nutzer passieren, dass er drei Mal vorgelesen bekommt, was in das Formular einzutragen ist, einmal der Text vor dem Feld, eimmal das Label und einmal die Vorbelegung. Ich habe sogar ein Formular gesehen, wo statt einem Label ein Alternativtext für die Formularelemente vergeben wurde. Ob das von der HTML-4-Spezifikation gedeckt ist?
Das ist keine Barriere, aber nervtötend. Ein anderes Beispiel sind die Sprunganker, die ermöglichen sollen, einzelne Bereiche der Website direkt anzuspringen, aber mancher übertreibt es und gibt jedem Pixel auf der Website einen Sprunganker. Weitere Beispiele werde ich später nachtragen.
Testen mit den Schwächsten
Ein Problem bei Usability-Tests sind die unterschiedlichen technischen Fähigkeiten der Nutzer. Manche wissen nicht einmal, wie sie Lesezeichen in ihrem Browser ablegen können. Dazu kommt bei Menschen mit Behinderungen die sehr unterschiedliche Kenntnis der Hilfsmittel und deren Möglichkeiten. Wir haben also zwei Dimensionen von Problembereichen statt nur einem.
Personen mit geringen technischen Kompetenzen sind daher ideal für Usability-Tests geeignet, denn für sie ist die Barrierefreiheit wirklich unverzichtbar. Ich unterscheide hier zwischen Benutzbarkeit und Barrierefreiheit. Eine Seite kann auch dann nutzbar sein, wenn sie als unstrukturiertes HTML daher kommt, barrierefrei ist sie trotzdem nicht. Den Unterschied verstehen viele nicht.
Die gesamte Spannbreite verschiedener Behinderungen, Hilfstechniken und technischen Fähigkeiten wird man wohl nicht in einer Testgruppe abbilden können. Allein die Zahl der unterschiedlichen Sehbehinderungen läßt sich kaum mit annehmbaren Aufwand abbilden.
Der Testleiter ist gefordert
Aber auch vom Testleiter werden erweiterte Fähigkeiten erwartet. Er muss zum einen natürlich mit den Leuten kommunizieren können, also auch mit Gehörlosen oder Menschen mit Lernschwierrigkeiten. Zum anderen muss er aber auch ihre speziellen Arbeitsweisen mit dem Computer kennen, damit er Probleme erkennen kann, ohne nachzufragen oder einzugreifen. Schwieirig ist es zum Beispiel einem Sehbehinderten mit starker Vergrößerung bei seiner Arbeit am Computer zu folgen, zumindest wenn er geübt ist. Witzig ist die Kombination aus Screenreader und Vergrößerung. Man kann hier in zwei Bereichen gleichzeitig arbeiten: einmal kann man im auf dem Bildschirm sichtbaren Bereich Text lesen, zugleich kann man im Bereich des Screenreader-Fokus Text schreiben oder Befehle ausführen. Zudem kombiniert man die Vorteile einer Tastatursteuerung mit den Vorteilen einer Maussteuerung.
Ich bezweifle, dass irgend eine andere Person außer dem Sehbehinderten selbst versteht, was er da macht, aber dafür gibt es ja die Methode des lauten Denkens.
Ich denke, das macht den Unterschied zwischen Barrierefreiheit und Benutzerfreundlichkeit deutlich. Die Seite mag barrierefrei sein, ist aber nicht benutzerfreundlich. Es ist praktisch unmöglich, in angemessener Zeit in Inhaltsbereich der Seite zu erreichen. Offenbar wollte jede Abteilung ihren Platz auf der Startseite haben. Es kann aber auch sein, dass Screenreader-Nutzer hier mehr hören als Sehende sehen, weil einzelne Bereiche der Seite über CSS ausgeblendet sind, ich war zu faul, mir den Quelltext anzuschauen.
Die anderen Ministerien sind aber ähnlich schlecht.
Fazit
Es ist hoffentlich deutlich geworden, dass eine Website – auch wenn sie barrierefrei ist – von ihrer Nutzung abschrecken kann, wenn sie aus Sicht eines Behinderten benutzerunfreundlich ist. Prinzipiell sind Barrierefreiheits-Tests ausreichend, um eine Reihe feststehender Kriterien zu prüfen. Am Ende müssen aber die Nutzer mit einer Behinderung das Angebot testen und auf Schwierigkeiten bei der Nutzung hinweisen. Ob man das Praxistest, Usability-Check oder was auch immer nennt, spielt keine Rolle.
Lektüre
Rekrutierung und Screening
– Zielgruppe anhand realer Nutzungsszenarien definieren; Behinderungstypen nur insofern berücksichtigen, wie sie für das Nutzungskontext-Verständnis relevant sind.
– Keine medizinischen Details abfragen; stattdessen funktionale Nutzungseinschränkungen im Kontext des Produkts.
– Sicherstellen, dass Hilfsmittel oder persönliche Assistenz der Teilnehmenden berücksichtigt werden (Screening-Fragen: „Welche Technologien nutzen Sie typischerweise für …?“).
– Testpersonen ausreichend fit, nicht zu fortgschritten, nicht zu technik-unerfahren
Testdesign
– Aufgaben so formulieren, dass sie reale Nutzungsszenarien abbilden, nicht künstlich auf Barrierefreiheitskriterien zielen.
– Aufgabenlänge und -komplexität an individuelle Geschwindigkeit und Arbeitsweisen anpassen.
– Genug Zeitpuffer einplanen; nicht davon ausgehen, dass Testdauer für alle gleich ist.
– Flexiblen Methodeneinsatz planen (Think-Aloud optional, rücksichtsvolle Moderation).
– Neutralität wahren: nicht implizieren, dass Schwierigkeiten aus der Behinderung stammen; Fokus auf Produktinteraktion.
Testumgebung und Setup
-persönliche Anforderungen im Vorgespräch Anhand von Checkliste abklären: assistive Technologien, räumliche Gestaltung, Pausenbedarf, Belastbarkeit
-optimale Umgebung schaffen, z.B. ablenkungsfrei bei ADHS
– Teilnehmende mit ihren eigenen Hilfsmitteln testen lassen (Screenreader, Braillezeile, Vergrößerungssoftware, alternative Eingabegeräte, orthopädische Tools etc.).
– Stabile technische Umgebung sicherstellen (keine Hindernisse durch fremde Geräte, ungewohnte Tastenkombinationen usw.).
– Räumliche Zugänglichkeit sicherstellen, aber dies nicht zum Testfokus machen.
– Für Remote-Tests mögliche Assistenz bei Einwahl, Setup und Bildschirmfreigabe vorsehen.
Moderation
-keine defizitäre Sprache, Respektvoll und wertschäztend kommunizieren
– Respektvolle, produktorientierte Sprache nutzen: Fokus auf Nutzungsziele, nicht auf Behinderung.
– Offene Fragen stellen, um mentale Modelle und Strategien zu verstehen („Wie würden Sie normalerweise …?“).
– Pausen anbieten und Belastungssignale beachten.
– Nicht unterbrechen, wenn Assistenztechnologien sprechen (z. B. Screenreader-Ausgaben vollständig laufen lassen).
– Aktiv entlasten: Schwierigkeiten dem Produkt zuschreiben („Das System verhält sich hier so…“), nicht der Person.
Datenerhebung
– Kontextbezogene Verhaltensbeobachtungen dokumentieren, insbesondere Interaktion mit Hilfstechnologien.
– Typische Usability-Metriken (Effizienz, Fehlerraten, Zufriedenheit etc.) nutzen, ohne Behinderung als Erklärvariable zu werten.
– Technische Aufzeichnungen (Screenreader-Ausgabe, Eingabegeräte-Logs) prüfen, falls einwilligungsfähig und datenschutzkonform.
Nachbereitung
– Ergebnisse entlang von Usability-Heuristiken und Nutzungskontext berichten – keine Barrierefreiheitskonformität bewerten.
– Empfehlungen neutral und lösungsorientiert formulieren: Welche Usability-Probleme traten auf, warum, unter welchen Nutzungsmustern?
– Klarmachen, ob gefundene Probleme auf Interaktionen mit spezifischen Assistenztechnologien zurückzuführen sind – aber ohne pathologisierende Sprache.