accessCast

Handlungsbedarf

In der letzten Folge hatten wir uns ein paar Gedanken dazu gemacht, wer für welche Teilaspekte des Barrierefreien Webdesigns zuständig ist. Heute gehen wir einen Schritt zurück und fragen uns, wie man die Accessibility grundsätzlich in einem Web-Projekt verankern kann.

Autor: tc

Dazu gehört natürlich zunächst einmal die Überzeugungsarbeit, den Handlungsbedarf in einem Projekt-Team oder im Verhältnis Dienstleister — Kunde aufzuzeigen. Und genau da fängt das Problem meistens schon an: mit der Erkenntnis, oder besser gesagt der mangelnden Erkenntnis, dass bei der betreffenden Website tatsächlicher Handlungsbedarf besteht. Bei vorhandenen Web-Auftritten, die zur Überarbeitung anstehen, lässt sich das Problembewusstsein generell in die folgenden vier Kategorien einteilen:

  1. Ignorieren und hoffen dass sich das Problem von selber löst.
  2. Barrierefreiheit quasi als Plug-In im Nachhinein dem Web-Auftritt überstülpen, nachdem der Job erledigt ist.
  3. Während der Entwicklung immer ein bisschen hier und da an den Stellschrauben drehen, wie es gerade passt oder nötig erscheint.
  4. Das Thema Accessibility bereits in der Konzeptionsphase einplanen und im gesamten laufenden Prozess als Ziel beibehalten.

Das erste Szenario können wir getrost überspringen, da hier die grundlegenden Voraussetzungen zur Erstellung eines barrierefreien Web-Auftritts fehlen. Es sei denn, die betreffende Organisation ist gesetzlich zur Einhaltung bestimmter Mindestanforderungen verpflichtet. Gerade bei der öffentlichen Hand hat die BITV in der Tat in den letzten Jahren schon einiges bewirkt, sodass diese »Management-Methode« nicht mehr anzutreffen sein dürfte. Für alle anderen gilt: ohne Problembewusstsein wird's nicht barriereärmer.

Das zweite Szenario ist, wie schon das erste, leider noch viel zu oft anzutreffen: Barrierefreiheit wird als ein technisches Ding angesehen, das man irgendwie auf dem Server installiert. Bei solchen Websites werden oftmals nach dem Launch noch irgendwelche Features nachgerüstet, mit denen grundlegende Probleme der gesamten Architektur oder der Inhalte überdeckt werden – oder vielleicht sogar überdeckt werden sollen? Zu erkennen ist diese Art von Websites meistens daran, dass sie zwar formell bestimmte Kriterien erfüllen, in der Praxis jedoch mit Hilfsmitteln behinderter Nutzer kaum zu gebrauchen sind.

Dabei wird häufig übersehen, dass Barrieren in den seltensten Fällen rein technischer Natur sind. Auch wenn man es mit diesem Ansatz vielleicht schafft, eine der ominösen Checklisten komplett abzuhaken – darum geht es bei Accessibility nicht. Es geht bei dem Thema immer um den Menschen, dem die Teilhabe am gesellschaftlichen Leben durch eine barrierefreie Nutzung erleichtert oder sogar erst ermöglicht wird.

Warnschild: Achtung, Baustelle!

Bei Websites der dritten Kategorie ist man schon ein gutes Stück weiter: irgendwer im Projektteam hat mal gehört, dass Barrierefreiheit kein Zustand ist, sondern ein Annäherungswert, dem man sich in einem Prozess nähert. Also wird im Zuge der Erstellung oder des Relaunches an manchen Stellen das Richtige gemacht, aber ohne eine offizielle Accessibility-Strategie bleibt es meist dabei.

Eventuell gab es hier schon Rückmeldungen von Menschen mit Behinderungen, dass sie bestimmte Inhalte der Website nicht nutzen können. Die Fokussierung auf das Abarbeiten von Beschwerden führt oftmals dazu, dass die Website auf ein bestimmtes Hilfsmittel wie zum Beispiel eine spezielle Version eines bestimmten Screenreaders hin optimiert wird - was auch nicht im Sinne eines barrierefreien Zugangs für sämtliche Behinderungsformen ist.

Oft werden bei solchen Websites Techniken eingesetzt, die vielleicht vor Jahren mal en vogue waren, von denen man aber heute weiss, dass sie nicht wirklich sinnvoll sind. Das Problem ist, dass das Netz in dieser Hinsicht nicht vergesslich ist (»»Cool URIs don‘t change«) und Tutorials zu veralteten Techniken auch heute noch für bare Münze genommen werden.

Womit wir in der vierten Kategorie, der Königsklasse angelangt wären:

»Das Thema Accessibility wird bereits in der Konzeptionsphase mit eingeplant und im gesamten Prozess als Ziel beibehalten.«

Diese Variante bietet die höchste Wahrscheinlichkeit, dass man hinterher mit einem weitestgehend barrierefreien Auftritt glänzen kann. Allerdings ist dies auch, und das muss man ehrlicherweise dazu sagen, die Variante mit dem höchsten Aufwand. Aufwand, der sich in der nötigen fachlichen Kompetenz der Beteiligten ausdrückt, aber auch Aufwand, der schon mit der benötigten Überzeugungsarbeit anfängt.

Wenn wir davon ausgehen, dass bei einem solchen Projekt bzw. bei den Beteiligten zumindest das Problembewusstsein schon vorhanden ist, dann entsteht hier trotzdem Aufwand in der Planungs- und Vorbereitungsphase, der sich direkt in Kosten niederschlägt. Sie können nicht davon ausgehen, dass alle am Projekt Beteiligten durch die Bank ein brauchbares Fachwissen über die speziellen Anforderungen der Barrierefreiheit in ihrem jeweiligen Fachgebiet haben. Dazu ist dieses Thema zum Beispiel in den Lehrplänen von Universitäten und Fachhochschulen oder Ausbildungsgängen noch viel zu wenig verankert.

Das Gute: wenn man im Vorfeld in das Training investiert, dann sind hinterher (also während der Umsetzung des Angebots) die Kosten für die Barrierefreiheit nahezu gleich – man macht dann halt alle Sachen einfach anders als bisher – sprich: gleich richtig.

Allerdings funktioniert dies nur, wenn das Thema Accessibility Rückendeckung von »ganz oben« hat, also das Management oder die Unternehmensleitung die Notwendigkeit akzeptiert und bereit ist, diese einmaligen Kosten zu tragen. Und da beginnt oftmals das Problem: wenn man auf das nächste Quartalsergebnis schielt, dann können einem diese einmaligen Kosten die Bilanz verhageln.

Die Schwierigkeit liegt hier in der Argumentation, dass es sich zunächst um weiche Faktoren und nicht direkt messbare Ergebnisse handelt, sondern um eine langfristige Investition, während die unmittelbaren Kosten ziemlich genau zu beziffern sind. Dabei ist eine Ablehnung durchaus nachvollziehbar: der menschliche Instinkt sagt fast automatisch »Nein«, wenn man aktuelle Zusatzkosten mit späteren Einsparungen begründet.

Weil aber barrierefreie Web-Angebote fast schon automatisch eine bessere Usability für den Nutzer, eine gesteigerte Performance auf dem Server und eine gewisse Investitionssicherheit durch Web-Standards bedeuten, dürfte diese Diskussion in den meisten Fällen pro Barrierefreiheit enden.

Merke: Barrierefreiheit kostet etwas: vor allem kostet es Überwindung.

Und auch wenn es erstmal teurer wird, spätestens beim nächsten Relaunch hat man nach unserer Erfahrung die zusätzlichen Kosten ganz schnell wieder drin. Denn ein wichtiges Merkmal barrierefreier Web-Angebote ist das »Mehr« an eingebauter Logik – sowohl in der gesamte Architektur als auch in der Gestaltung und der technische Umsetzung. Dieses Mehr an Logik erweist sich erfahrungsgemäß als enorm hilfreich, wenn Inhalte überarbeitet oder erweitert werden sollen oder auch schon dann, wenn der Kunde die Navigation auf einmal links statt rechts haben möchte.

Zumal die Kosten für das Ent-Lernen von »das haben wir immer so gemacht« und das Neu-Lernen von moderneren Techniken geradezu lächerlich gering sind im Vergleich zu einer 4c-Seite in der ADAC-Zeitung oder einem 30-Sekünder zur Prime-Time im Fernsehen. Dabei sollten diese Kosten für die Schulung der Projektbeteiligten streng genommen beim Dienstleister verbleiben und nicht auf den Kunden abgewälzt werden. Barrierefreiheit gehört mittlerweile zum guten Handwerk und die Beherrschung der nötigen Techniken darf und muss man mittlerweile von qualifizierten Dienstleistern erwarten.

Widerstände aus Sicht des Dienstleisters sind ebenso verständlich, aber sicher nicht im Sinne des Kunden und des verantwortungsvollen Umgangs mit Etat-Geldern: Standard-konforme und zugängliche Webseiten sind einfacher in Wartung und Pflege, spülen daher aber auch weniger Geld in die Kassen der Agentur.

Dabei sollte es auch im ureigensten Interesse des Dienstleisters liegen, immer auf die maximal erreichbare Qualität abzuzielen. Die Zielvorgabe, den Durchschnitt zu erreichen führt ganz automatisch zu einem Absacken der allgemeinen Qualität, das ist ein ganz einfaches mathematisches Rechenmodell.

Wie man denn nun die Barrierefreiheit in einem Entwicklungsprozess verankert ist Gegenstand langer Diskussionen. Ohne die Strukturen und Abläufe in einer Organisation oder die Etatgrößen zu kennen kann man kaum allgemeingültige Tipps zu diesem Thema geben – dazu sind diese zu individuell und von Faktoren abhängig, die unter Umständen einmalig sind. Trotzdem noch zwei Lesetipps zu dem Thema, leider wie so oft nur auf Englisch:

Der Artikel »Implementation Plan for Web Accessibility« von der Web Accessibility Initiative des W3C gibt Tipps, wie man, wie es auf neudeutsch so schön heisst, »Awareness« schafft, wie man Baustellen identifiziert, geeignete Software aussucht und Mitarbeiter und Kollegen schult. Das ganze in Form einer ziemlich langen Liste.

Viel ausführlicher ist die Artikelreihe »8-Step Implementation Model« bei WebAIM, in dem auch gleich noch verschiedene Szenarien mitgeliefert und intensiv diskutiert werden. Links wie immer am Ende der Mitschrift.

So, das war die sechsundzwanzigste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. In der nächsten Folge geben wir ein paar Tipps, wie man schon während der Erstellung oder des Umbaus eines Angebots die Qualität überprüfen kann.

Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags und . Bis zum nächsten Mal.