IT-Barrieren erkennen

Ursprünglich waren es Menschen mit Behinderungen selbst, die auf Barrieren in der IT aufmerksam machten. Bereits in den 1980er Jahren gab es Braillezeilen und Sprachausgaben für blinde und sehbehinderte Menschen. Damals waren es aber in der Regel Drittanbieter, die sich darum kümmerten, Software für Menschen mit Behinderungen zugänglich zu machen. Dass die Software selbst barrierefrei programmiert werden könnte, wurde weniger diskutiert. Mit dem Aufkommen grafischer Benutzeroberflächen und vor allem mit dem Erfolg von Windows 95 änderte sich das. Interessenverbände in den USA klagten erfolgreich ein, dass das Betriebssystem mit ihren Hilfsmitteln (in erster Linie Screenreader) kompatibel sein sollte. Die damals noch eher überschaubare Anzahl an Braille-Treibern und Sprachausgaben machte es Microsoft möglich, in relativ kurzer Zeit eine Software-Schnittstelle namens MSAA (Microsoft Active Accessibiltiy) zu schaffen, die einen Quasi-Standard für blinde und sehbehinderte Menschen für die Arbeit am PC darstellte. MSAA bot für das Erkennen von Barrieren zwei Neuerungen: einerseits waren damit automatisierte Tests möglich, andererseits konnten mit dem Screenreader Barrieren ermittelt werden, die automatisiert nicht prüfbar waren (z. B., ob der Name eines Bedienelements korrekt ist).

Mit dem in den 1990er Jahren schnell wachsenden Internet und dem damit verbundenen Auszeichnungsstandard HTML wurde noch einmal mehr offensichtlich, worauf es bei der barrierefreien Programmierung und Gestaltung im Wesentlichen ankommt: Struktur, ausreichende Kontraste und semantische Korrektheit. Damit war der Weg geebnet zum ersten für das Web verbindlichen Prüfkatalog zur Ermittlung des Grades der Barrierefreiheit: dem Standard WCAG 1.0 von 1998. Dieser bildete in der Folge die Basis für eine ganze Reihe von automatischen und manuellen Prüfverfahren. Vielen, die 2002 schon Barrierefreiheit im Web prüften, ist Bobby vielleicht noch ein Begriff. Mit diesem automatischen Werkzeug war es möglich, fehlende Alternativtexte, mangelhafte Überschriften-Strukturen etc. zu ermitteln.

Das in Deutschland wohl bekannteste Verfahren zur manuellen Prüfung war seit 2003 der BITV-Test. Dieser wurde seitdem stetig weiterentwickelt und stellt bis heute eines der wichtigsten Werkzeuge zur Ermittlung des Grads der Barrierefreiheit von webbasierten Inhalten dar. 
Für Software gab es, ebenfalls bereits seit Anfang der 2000er Jahre, die IBM-Checkliste. Für automatisierte Prüfungen von Software stellte Microsoft auch damals schon Tools wie inspect.exe, accCheck etc. zur Verfügung. Sie lieferten für Entwickler*innen vor allem in Verbindung mit manuellen Prüfungen sehr gute Hinweise zur barrierefreien Überarbeitung von Anwendungssoftware.
Die Standards entwickelten sich weiter, neue Prüfverfahren kamen hinzu, so dass man heute unter anderem neben dem BITV-Test als offiziell verfügbares Verfahren auch die Prüfverfahren für Anwendungssoftware und PDF-Dokumente des Projektes BIT inklusiv nutzen kann. In der europäischen Gesetzgebung wird für barrierefreie IT mittlerweile der Standard EN 301 549  zu Grunde gelegt.

Um Barrieren zu erkennen, sind also eine Fülle von Verordnungen, Gesetzen, Standards, Richtlinien und Experten-Verfahren verfügbar. Nutzer*innen ohne Expertenwissen müssen sich aber nach wie vor fragen, wie sie mit einfachen Mitteln einen Beitrag zur Entwicklung barrierefreier Anwendungen leisten können.

Dabei kann man die notwendige Expertise durchaus abgestuft betrachten:

1. Betroffene liefern über die Ausgabe ihrer Hilfsmittel wertvolle Infos
2. Expert*innen liefern in Kenntnis der notwendigen Standards und Richtlinien über die kombinierte Anwendung von Prüftools und Hilfsmitteln (sofern möglich, mit Blick auf den Quelltext) eindeutige Informationen über mögliche Barrieren
3. Das Windows-Betriebssystem besitzt eine Reihe von Einstellmöglichkeiten, die es auch Nicht-Expert*innen (in Grenzen) erlauben, Barrieren zu identifizieren
4. Einer der wichtigsten Indikatoren wird im Bereich der Barrierefreiheit oft vergessen: die Nutzerzufriedenheit

Die Nutzerzufriedenheit kann nicht nur im Bereich der Usability zum Haupt-Hinweisgeber für die notwendige Überarbeitung von Software genutzt werden, sondern auch zur Ermittlung von Barrieren. Denn wenn bei der Benutzung eines Programms Schwierigkeiten auftreten, dann wird in der Regel achselzuckend darüber hinweggesehen. Wenn es eine größere Anzahl solcher Schwierigkeiten gibt, dann wird das Programm oft bereits als unbrauchbar bezeichnet. Manchmal ist es aber auch so, dass man sich bei der Nutzung, unabhängig von der Tagesverfassung, unsicher fühlt. Diese diffuse Unsicherheit stellt, richtig genutzt, einen wertvollen Hinweis potenzieller Barrieren dar. Findet man nämlich heraus, an welchen Stellen solche nicht klar zu benennenden Gefühle auftreten, welcher Bereich einer Anwendung dafür besonders verantwortlich ist etc., kann oft schon das Feld potenzieller Barrieren eingegrenzt werden.

Während bei anfänglicher Übung im Überprüfen der Barrierefreiheit vermutlich Schriftgröße, Schriftschnitt oder Kontrast im Vordergrund stehen werden, werden mit etwas Übung auch Fehler in der Struktur, schwer verständliche Erläuterungen in Hilfetexten oder Abläufen identifiziert werden können. Der Hinweisgeber ist dabei nicht der geschulte, analytische Blick, sondern vielmehr etwas vage Gespürtes, das zwar deutlich die Stimmung beeinflusst, aber nur schwer benannt werden kann. Mit dem Fokus auf unser Befinden bei der Nutzung von Software werden wir zu Expert*innen, die Entwickler*innen sehr wertvolle Hinweise liefern.

Es gibt also vielfältige technische und nicht-technische Wege Barrieren zu erkennen. Ganz unabhängig davon, wie man sich mit Barrierefreiheit beschäftigt: Es geht oft weniger darum, sich technisch gut auszukennen, als das eigene Erleben bei der Nutzung von Software ernst zu nehmen.