Derzeit sorgt ein Beitrag von Anne Gibson auf A List Apart für Diskussion. Ausgangspunkt ist eine seit Jahren akzeptierte Definition des W3C, in der die Barrierefreiheit im Web als Nutzung des Webs durch Menschen mit Behinderung beschrieben wird. Die Autorin möchte den Bezug zu Behinderung durch einen Bezug zur Technologie ersetzen.
Hinweis: Eine englische Fassung dieses Beitrags wurde am 14. Februar 2015 als Accessibility is usability in context of disability veröffentlicht.
Webanbieter haben oft eine klar definierte Zielgruppe für eine Website vor Augen . Eine Eingrenzung der Zielgruppe erleichtert die Wahl von Marketing-Instrumenten oder der Ansprache. Eines tut die Festlegung der Zielgruppen aber bestimmt nicht: Die Nutzer einer Website festlegen. Gerade im Web sind die tatsächlichen Nutzer kaum zu ermitteln und es kann nie sicher sein, ob es beispielsweise ein Jugendlicher aus der Zielgruppe oder seine Großeltern sind, die den Einkauf mit einem bestimmten Rechner gerade tätigen. Genauso ist es mit Behinderung: Es ist nicht von vornherein klar, ob ein Nutzer bzw. ein Kunde aufgrund einer Behinderung auf bestimmte Merkmale der Barrierefreiheit angewiesen ist oder nicht.
Dabei geht es nicht um eine konkrete Behinderung. Barrierefreiheit berührt alle Aspekte des Webdesigns. Eine Webseite, die weitgehend barrierefrei ist, wird für alle Nutzer vorteilhaft sein und – vermutlich wichtiger – für keinen von Nachteil werden.
Die technische Betrachtung reicht nicht aus
Der eingangs angesprochene Beitrag von Anne Gibson beschreibt Herangehensweisen, um ein barrierefreies Webdesign zu erzielen, ohne sich mit dem Thema „Behinderung“ auseinandersetzen zu müssen. Es werden existierende Ein- und Ausgabegeräte benannt und wie sie in der Qualitätssicherung eingebunden werden können. Es werden auch weitere Maßnahmen zur Sicherung der Barrierefreiheit aufgeführt, die alle für sich unwidersprochen sinnvoll sind. Die Autorin kennt sich in der Materie vorzüglich aus und weiß um die Vermittlungsschwierigkeiten, wenn eine Website zugänglich und nutzbar auch für Menschen mit Behinderungen sein muss.
Die Kenntnisse über die Arbeitsweise von Menschen mit Behinderungen wird in dem Beitrag nur gestreift. Die Anforderungen der Barrierefreiheit werden in technische Kriterien übersetzt und der Nutzer (mit einer Behinderung) wird mehr oder weniger beiläufig berücksichtigt. Eine solche Reduzierung der Barrierefreiheit auf eine technische Betrachtung ist aus meiner Sicht aus folgenden Gründen unangemessen:
- Wenn ein bestimmtes Ein- oder Ausgabegerät benannt wird, muss es auch so bedient werden, wie vom (behinderten) Nutzer. Was nützt beispielsweise die Kenntnis über die Existenz von Screenreadern als Ausgabegerät, wenn die etlichen Tastaturbefehle nicht geläufig sind? Was nützt die Kenntnis über eine Kopfmaus, wenn die konkreten Einstellungen für deren Bedienung nicht bekannt sind? Insofern müssen sich Webentwickler mit den Hilfsmitteln und den Arbeitsweisen behinderter Nutzer auseinandersetzen, wenn sie Webseiten und -anwendungen barrierefrei entwickeln wollen.
- Selbstverständlich kann sich die Webentwicklung auf akzeptierte Dokumentationen und Kompatibilitätstabellen verlassen, um zugänglichen Code zu produzieren, aber ob dann ein Webinhalt barrierefrei ist oder nicht, hängt von vielen weiteren Faktoren ab. Das Totschlagargument gegen diese Herangehensweise ist aber, dass die Barrierefreiheit mit der Nutzung von Hilfsmitteln gekoppelt wird. Im barrierefreien Webdesign geht es zwar auch um eine technische Zugänglichkeit für Hilfsmittel, aber die Nutzbarkeit der Inhalte stellt die weitaus größere Herausforderung dar. Darüber hinaus kommen inhaltliche Aspekte hinzu, die von der Wahl sinnvoller Alternativtexte für Grafiken bis zum Einsatz von Gebärdensprachfilme reichen. Ich kann mir beim besten Willen nicht vorstellen, dass die Vielfalt an Themen und Szenarien mit einer Checkliste begegnet werden kann, ohne sich intensiv mit Behinderungen auseinandergesetzt zu haben.
- Schließlich ist der technische Fortschritt ein Problem. Wenn das W3C neue Technologien zu einem Webstandard macht, müssen sie zwar barrierefrei sein, aber für jede einzelne Technik reichen zwei beliebige Instanzen, um die Technik als zugänglichkeitsunterstützend und somit auch barrierefrei zu bewerten. Beispielsweise ist die barrierefreie Gestaltung von fortgeschrittenen Komponenten nur mit WAI-ARIA möglich; dabei funktionieren unter verschiedenen Browser-Screenreader-Kombinationen unterschiedliche Attribute unterschiedlich gut, d.h. einige Komponenten können nur für bestimmte Browser-Screenreader-Kombinationen zugänglich gemacht werden. Weiter setzt diese Politik voraus, dass Nutzer in der Regel mit aktueller Software arbeiten müssen, um moderne Webtechniken nutzen zu können.
Zu glauben, dass das Ausblenden des Begriffs „Behinderung“ die Bereitschaft und Fähigkeit der Webentwicklung verändert, um nutzbare Webseiten zu erzielen, halte ich für kurzsichtig. Die Gründe, warum Barrierefreiheit ein Dauerthema bleibt und bleiben wird, ist in der Haltung der Webentwicklung bzw. der Gesellschaft zu finden. Wer im Alltag keine Berührungspunkte mit Behinderungen und den daraus hervorgehenden Nachteilen hat, wird Barrierefreiheit nicht als Maßstab für die eigene Arbeit verwenden.
Das Ausklammern von Behinderung im Alltag hat sicherlich auch mit der eigenen Angst zu tun, etwa weil man sich nichts Schlimmeres vorstellen kann, als blind zu sein oder im Rollstuhl zu sitzen. Es hat aber auch mit allgemeinen Vorurteilen und Unwissenheit zu tun, etwa dass Menschen mit Behinderungen einen Computer nicht nutzen können. Dabei trifft das Gegenteil zu: Computer sind für behinderte Menschen nicht nur Arbeitsmittel, sondern auch Hilfsmittel. Diese Hilfsmittel setzen in manchen – aber nicht in allen – Situationen voraus, dass die Webentwicklung vernünftigen Code produziert.
Insofern kann die Webentwicklung wenig dafür, dass sie die Barrierefreiheit vergisst oder ausklammert – so läuft es in vielen anderen Bereichen des Lebens auch, sei es Architektur, Bildung oder Reisen. Aber den Begriff „Behinderung“ auszublenden, wenn es um Barrierefreiheit geht, wird diese Form der Benachteiligung nur noch verstärken.
Barrierefreiheit bleibt eng mit Behinderung verknüpft. Solange die allermeisten Webseiten nicht einmal den Minimalanforderungen der Barrierefreiheit genügen, kann kaum erwartet werden, dass die Webentwicklung die Barrierefreiheit besser umsetzt, wenn das Wort „Behinderung“ nicht fällt, im Gegenteil: Die Webentwicklung muss viel mehr mit Nutzern – auch behinderten Nutzern – arbeiten, damit alle Nutzer ein besseres Erlebnis im Web erfahren. Es kommt darauf an, den Nachteil, der durch eine Behinderung entsteht, zu verstehen und die Konsequenzen für die eigene Arbeit daraus zu ziehen.
Barrierefreiheit als Teil der UX
Meist ist es das Wissen über den Sinn einer Maßnahme, das den Weg für die Umsetzung frei macht. Schließlich werden auch andere „Features“ auf einer Webseite umgesetzt, auch wenn der Preis astronomisch hoch ist und der Nutzen kaum der Rede wert ist. Es ist eine Frage der Prioritätensetzung, ob Nutzer und somit die Barrierefreiheit in den Mittelpunkt der Webentwicklung gestellt werden.
Einmal mit barrierefreiem Webdesign konfrontiert, wird seitens mancher Verantwortlichen das Thema gerne mit unbegründbaren Gegenargumenten wie z.B. „Wir kennen unsere Nutzer“ begegnet. Bei einer repräsentativen Umfrage unter den Nutzern würde man vermutlich feststellen, dass ein beträchtlicher Teil der Nutzer farbenblind ist oder andere Erschwernisse hat. So kann bereits ein gebrochener Arm dazu führen, dass bestimmte Kriterien der Barrierefreiheit zeitweise wichtig werden. Auch andere Aspekte spielen eine Rolle, etwa die auf dem Nachttisch vergessene Lesebrille oder die kabellose Maus mit leerem Akku.
Auch wenn alle Nutzer persönlich bekannt sind, was in einem kleineren Intranet möglich ist, so sind doch viele individuelle Einschränkungen bei der Computerarbeit nicht allgemein bekannt. Teilweise ergeben sich Probleme der Nutzbarkeit erst im Laufe der Zeit. In einer – zugegebenermaßen etwas älteren – Studie von Microsoft wird deshalb davon ausgegangen, dass über 57 % aller erwachsenen Nutzer von Barrierefreiheit profitieren.
Trotzdem entsteht bei manch einem IT-Verantwortlichen eine diffuse Unsicherheit, wenn das Thema Barrierefreiheit auf den Tisch kommt. Es läuft ein Film ab, in dem Software nur aus monochromem Text dargestellt wird oder eine Anwendung ohne JavaScript laufen muss. Die Idee, behinderte Menschen gehören nicht zur Zielgruppe und auch nicht zur Nutzergruppe, blockiert manchen rationalen Gedanken. In jedem Fall gibt es oft eine Ablehnungshaltung und – wenn alle Argumente entkräftet wurden – wird schließlich die Kostenkeule rausgeholt.
In der Realität ist Barrierefreiheit genauso ein Teil der UX wie Technik, Kreativität und Gebrauchstauglichkeit. Ich würde sogar behaupten, dass Barrierefreiheit einen entscheidenden Einfluss auf UX hat, und nur wenn eine Webseite oder -anwendung barrierefrei ist, wird sie für eine Mehrheit der Nutzer positiv erlebt. Wo auch immer die Bedeutung der Barrierefreiheit genau angesiedelt wird, eine gute Software muss viele Parameter für ein positives Nutzungserlebnis der Nutzer zusammenbringen, wobei ein barrierefreies Webdesign ohne Zweifel dazu gehört.
Eine Abwehrhaltung ist gar nicht erforderlich. Wer sich nur im geringsten für Gebrauchstauglichkeit interessiert, ist bereits schon mit der Barrierefreiheit befasst. Barrierefreiheit ist die Gebrauchstauglichkeit vor dem Hintergrund einer Behinderung.
Ich kommentiere nur zum letzten Satz und damit zur Definition „Barrierefreiheit ist die Gebrauchstauglichkeit vor dem Hintergrund einer Behinderung.“ Ich kann mich damit aus mehreren Gründen nicht anfreunden und möchte das anhand einiger weniger Beispiele begründen.
# Beispiel Megamenüs im Kontext von Vergrößerung (nicht SR-Nutzung): Je größer ein Mega-Menü ist und je mehr aufgrund einer Sehschwäche / Sehbehinderung vergrößert werden muss, desto weniger gebrauchstauglich sind diese; sie würden jedoch (Kontraste, Fokus, lass ich mal außen vor, da anderer Punkt) i.d.R. durch eine formale Accessibility Prüfung kommen.
# Mehrere Wege führen oft zum Ziel. Damit beispielsweise Navigationsblöcke übersprungen bzw. Hauptinhalte besser erreichbar sind, können verschiedene Techniken eingesetzt werden: Ein Skip Link oder mehrere Skip Links oder versteckte Überschriften oder Landmarks. Wird Accessibility geprüft, dann wäre dieser Punkt (WCAG bzw. BITV 2.4.1) erfüllt. Aber: Nicht jede dieser Techniken ist für jede Webseite in gleichem Maße gebrauchstauglich und wenn alle verwendet werden, dann kann die Website sehr unusable werden.
Mir werden mit der o.g. Definition diese Unterschiede von Barrierefreiheit und Gebrauchstauglichkeit zu sehr verwischt. Sicher werden qualifizierte Berater bei der Entwicklung einer Website so beraten, dass diese barrierefrei nach WCAG 2.0 oder BITV 2.0 ist _und_ zugleich vor dem Hintergrund einer Behinderung gebrauchstauglich. Geht es jedoch nicht um Beratung, sondern um reines Testing, besteht bei der Mischung dieser Ebenen immer die Gefahr, dass man nicht mehr WCAG 2.0 / BITV 2.0 prüft. In qualifizierten Gutachten kann man dies lösen, indem man z.B. schreibt: Punkt X ist zwar durch die Verwendung von Y erfüllt, aus Gründen der besseren Usability vor dem Hintergrund einer Sehbehinderung / Screenreadernutzung / …, wird jedoch empfohlen Z zu verwenden. Oder an Beispiel der Mega Menüs: Erfüllt, es wird jedoch darauf hingewiesen, dass diese je nach individuell nötiger Vergrößerung weniger gebrauchstauglich sind.
Lange Rede kurzer Sinn und angelehnt an deine Definition: Aus meiner Sicht gibt es die Accessibility und eine Usability vor dem Hintergrund einer Behinderung.
Sicher gibt es für jedes Szenario gute Beispiele. Warum ich Barrierefreiheit in Bezug zu Usability stelle möchte ich auch mit einem Beispiel zeigen:
Wenn in einer Drag and Drop funktion die zu ziehenden Objekte und die Zielgebiete tastaturbedienbar und mit der erforderlichen Semantik (ARIA) ausgezeichnet werden, kann die Gebrauchstauglichkeit in Screenreadern nach wie vor „dürftig“ sein. Es ist eine hohe Konzentration seitens der Nutzer erforderlich, auch wenn die WCAG erfüllt ist. Damit die nötige Rückmeldung erfolgt (Objekt erfolgreich hier oder dort abgelegt) müssen zusätzliche Maßnahmen ergriffen werden (z.B. Live-Regionen). Ansonsten ist die Anwendung zwar WCAG-konform, aber in einem Screenreader dennoch kaum nutzbar.
Ausgangspunkt war der Artikel bei ALA, in der die Zugänglichkeit als Teil der Qualitätssicherung integriert wird, aber nicht die Nutzbarkeit. Ich meine, dass sich Barrierefreiheit auch auf die Nutzbarkeit ausgerichtet sein muss und die Nutzbarkeit hat nicht nur mit UX zu tun, sondern eben auch mit Effizienz und Effektivität.
Das bedeutet in Konsequenz dann allerdings, dass man sich von prüfbaren Kriterien verabschieden würde. Gerade „hoher Konzentrationsaufwand“ (Wie hoch? Ist der für alle gleich hoch? Wenn jemand ungeduldig ist, dann ist er evtl. höher?), aber auch Effizienz und Effektivität hängen ja nicht nur vom UI ab, sondern auch von Faktoren wie Vertrautheit mit Web, Vertrautheit mit dem Hilfsmittel, (tagesaktuelle) Konzentrationsfähigkeit, persönliche Vorlieben usw.
Was ich allerdings finde ist, dass man im Web den Begriff „Barrierefreiheit“ nicht ohne Bezug zu einem Standard oder einer Verordnung verwenden sollte. Besser finde ich immer zu sagen: „Barrierefreiheit nach XY“.