accessCast

Zum Start unserer BITV-Reloaded-Serie haben wir eine Tabelle veröffentlicht, in der die Arbeiten zur Erfüllung der einzelnen Bedingungen den Beteiligten wie Kunde, Konzepter, Designer, Programmierer und Redakteur zugeordnet werden. Viele Aufgaben sind eindeutig zuzuordnen, wie zum Beispiel die Gewährleistung von ausreichenden Kontrasten für sehbehinderte Nutzer – dies ist Sache des Grafikers. Oder die Verknüpfung von Formularelementen mit ihren Beschriftungen via LABEL – hier sind die Frontend-Entwickler gefragt, die das HTML umsetzen. Ein ganze Reihe von Punkten ziehen sich jedoch wie ein roter Faden durch das ganze Projekt - zum Beispiel die Textalternativen bzw. Untertitel für multimediale Inhalte: der Konzepter muss sie vorsehen, der Grafiker in der Oberfläche berücksichtigen, der Programmierer muss sie technisch ermöglichen und in der laufenden Pflege verursachen sie ebenso laufenden Aufwand.

Dabei sind die Zuordnungen in dieser Tabelle immer nur der frühestmögliche Zeitpunkt, um spätere Fehler zu vermeiden. Wenn zum Beispiel in den grafischen Entwürfen das Thema der ausreichenden Kontraste nicht berücksichtigt wurde, dann kann man diesen Fehler zwar im Nachhinein an der fertigen Website noch korrigieren – nur: dann wird's teurer. Gleiches gilt für alle anderen Punkte: wenn man an der richtigen Stelle ansetzt, dann bekommt man diese Punkte noch kosten- und aufwandsneutral oder zumindest mit vertretbarem Mehraufwand in das fertige Produkt eingearbeitet. Accessibility ist kein Plug-In, das man in eine bereits fertige Website installiert - es ist eine andere Art der Haltung gegenüber dem Nutzer.

Der wichtige erste Schritt

Sämtliche Beteiligten sollten sich bereits in der Planungsphase ein grundlegendes Verständnis davon aneignen, was Barrierefreiheit für ihr Projekt bedeutet, warum dieses Thema wichtig ist und wie man die richtigen Menschen und Werkzeuge für diesen Job auswählt.

Die Literatur zu diesem Thema ist wie üblich vorzugsweise auf Englisch, aber ein guter Einstieg in das Thema bietet die britische Spezifikation PAS 78 mit dem Titel »Guide to good practice in commissioning accessible websites«. Links gibt's wie immer in der Mitschrift. Das W3C hat ebenfalls eine ganze Reihe Anleitungen veröffentlicht, wie man das Thema Barrierefreiheit in Projektplänen berücksichtigen sollte. Auf den Seiten der Web Accessibility Initiative finden sie diese in der Navigation unter dem Punkt »Managing Accessibility«. Auch diese Dokumente sind generell in englischer Sprache verfasst. Ausnahmen wie die übersetzte Checkliste der wichtigsten Barrieren und ein deutschsprachiges Mapping der WCAG 1.0-Checkpunkte auf die verschiedenen Formen von Behinderung bestätigen diese Regel.

Einige im Netz kursierende Listen von Dienstleistern, die besonders zugängliche Webseiten liefern können, sind hingegen mit Vorsicht zu genießen. Hier wird oft lediglich anhand eines eingeschränkten Kriterienkatalogs getestet, wie sehr das Produkt ebendiesen Kriterienkatalog erfüllt. Damit kann man aber im Ernstfall nur beweisen, dass man den Kriterienkatalog gemeistert hat. Ob und wie diese Angebote auch von Menschen mit Behinderung getestet wurden und vor allem: wie diese Tests ausgefallen sind kann man aus diesen Listen nicht ableiten.

Zum Verständnis der Problematik von Barrieren gehört das Wissen um die Hintergründe für die Existenz der jeweiligen Checkpunkte der WCAG bzw. Bedingungen der BITV. Bei vielen Punkten wird der Sinn erst klar, wenn man ihn aus der Sicht der Nutzer mit Behinderungen betrachtet: welche Barrieren entstehen für welche Nutzer, wenn ein Punkt nicht erfüllt ist. Die Richtlinien können hier nur einen ersten Ansatz bieten, zum besseren Verständnis muss man sich tatsächlich tiefer in das Thema einlesen.

Die weit verbreitete Checklisten-Mentalität verleitet nach unserer Erfahrung sehr schnell dazu, die Barrierefreiheit auf ein rein technisches Thema zu reduzieren. Hiergegen hilft einerseits die Lektüre der zum Verständnis der Richtlinien wichtigen Techniken beim W3C und die möglichst frühe Verteilung der Verantwortlichkeiten für die einzelnen Teilbereiche in einem Projekt. Idealerweise gibt es in allen Projektteams eine Person, die für das Thema Barrierefreiheit verantwortlich ist und die, wenn es sein muss, alle anderen immer wieder damit nervt.

Dabei reicht es wie gesagt nicht, wenn dieses Thema erst dann auf den Tisch kommt, wenn das Kind schon in den Brunnen gefallen ist. In der Phase der Umsetzung des Frontends kurz vor dem Start eines Webangebotes kann man zwar theoretisch noch viele Fehler ausbügeln, die sich in den vorhergehenden Projektphasen eingeschlichen haben. Allerdings riskiert man in dieser Phase, dass dann entweder die Accessibility oder der Launch-Termin gekippt werden müssen. Bei Angeboten, die Kraft Gesetzes zur Barrierefreiheit verpflichtet sind, muss die Entscheidung in einem solchen Fall für die Verschiebung des Starttermins fallen; bei kommerziellen Angeboten wird, so hat es die Erfahrung gezeigt, die Accessibility oftmals auf einen späteren Zeitpunkt verschoben und im Netz landet dann ein für viele Menschen unzugängliches Angebot.

Die Aufteilung der BITV nach Verantwortlichkeiten ist natürlich eine sehr vereinfachte Darstellung, bzw. nur ein Drittel der Wahrheit. Zur barrierefreien Nutzung eines Web-Angebots gehören zusätzlich noch Dinge, auf die man als Anbieter oder als verantwortlicher Webentwickler keinen oder nur sehr begrenzten Einfluss hat.

Die Werkzeuge

Die Hersteller von Autorenwerkzeugen wie Dreamweaver und Frontpage, großen und kleinen Content Management Systemen, aber auch Blog-Tools wie Wordpress und Movable Type müssen ihr Drittel der Verantwortung für ein barrierefreies Netz ebenso tragen. Viele Punkte der BITV lassen sich nur umsetzen, wenn dies von den Autorenwerkzeugen überhaupt erst ermöglicht und unterstützt wird. Ein Redaktionssystem, dass bei Bilddaten automatisch den Copyright-Vermerk als Alternativtext einfügt scheitert damit schon am allerersten Checkpunkt der Richtlinien und wird wohl auch mit dem Rest seine lieben Nöte haben.

Ein Tipp für Anbieter bei der Auswahl eines Redaktionssystems: falls Ihnen ein Anbieter verspricht, dass ein System selbstverständlich WCAG Level AAA bzw. BITV Priorität 2 vollautomatisch erfüllt, dann sollten Sie hellhörig werden – denn das geht gar nicht. Fragen Sie den Anbieter dann, ob er schon mal was von den »Authoring Tool Accessibility Guidelines« des W3C, den Richtlinien für Autorenwerkzeuge gehört hat und wie sein Produkt da abschneidet. Falls bei Ihnen gerade die Investition in ein neues Redaktionssystem ansteht finden Sie weitere Tipps in unserem Podcast vom 13. Dezember 2006 zum Thema »CMS und Webstandards«.

Diese weithin unbekannten Richtlinien lassen sich jedoch nicht nur auf den Output eines Redaktionssystems anwenden; mit ihr lässt sich ebenso bewerten, ob das System auf der Eingabeseite von Menschen mit Behinderungen zu bedienen ist. Zudem fällt man als Anbieter ebenso unter die Ägide der ATAG, sobald man es Nutzern in seinem Webangebot ermöglicht selbst Inhalte einzustellen, und seien es nur Kommentare in einem Weblog – auch hier handelt es sich streng genommen bereits um ein Autorenwerkzeug. Diese Liste ließe sich noch beliebig erweitern – alle Programme, die über einen »Als HTML speichern…«-Knopf verfügen, müssen sich mindestens die folgenden Fragen gefallen lassen:

• Fördert oder verhindert das Werkzeug die Erstellung und Pflege von barrierefreien Inhalten? Gibt es überhaupt Möglichkeiten, zum Beispiel Textalternativen für Nicht-Text-Inhalte wie Bilder und Multimedia einzupflegen?
• Werden nach den Richtlinien sauber eingepflegte Inhalte 1:1 übernommen oder ›dekoriert‹ das System diese Inhalte nach seiner Vorstellung mit eigenem Code um? Besonders berüchtigt sind hier Systeme, die auch im Jahre 2007 noch hartverdrahtete Layout-Tabellen und font-Tags benutzen.
• Falls vorgefertigte Templates verwendet werden: sind diese in den anwendbaren Punkten WCAG-konform?
• Falls einige dieser Fragen negativ beantwortet werden müssen: gibt es als letzten Ausweg noch die Möglichkeit, die Inhalte vor der Auslieferung an den User auf dem Server zu säubern?
• Bei immer wiederkehrenden Problemen mit dem Autorenwerkzeug sollten Sie ein Prozedere entwickeln, wie diesen Problemen schon im Vorfeld begegnet werden könnte, oder wie diese Probleme zumindest im Nachgang automatisch bereinigt werden.

Die Ausgabeseite

Womit wir beim letzten Drittel angelangt wären: alle Anstrengungen um ein barrierefreies Webangebot sind für die Katz', wenn sie von den Browsern und Hilfsmitteln gar nicht, nur unzureichend oder fehlerhaft unterstützt werden. Zwar gibt es hierfür ebenso eine passende Richtlinie beim W3C, die »User Agent Accessibility Guidelines« (UAAG), aber auf deren Einhaltung haben Anbieter und Ersteller von Webseiten naturgemäß den geringsten Einfluss. Hier liegt die Verantwortung bei den Nutzern, sich für ihre speziellen Bedürfnisse passende Soft- und Hardware zu beschaffen oder durch den Arbeitgeber beschaffen zu lassen.

Dazu gehört die Bereitschaft des Nutzers, sich mit den zur Verfügung stehenden Hilfen und Anpassungsmöglichkeiten in seinem Browser zu beschäftigen. Dazu gehört auch die Bereitschaft, sich im Ernstfall nach Alternativen umzusehen. Für Blinde und Sehbehinderte bietet hier der Informationspool Computerhilfsmittel INCOBS einen ersten Einstieg mit Testberichten und weiteren Beratungsleistungen. Das bundesweite Kompetenz- und Referenzzentrum »barrierefrei kommunizieren!« unterhält eine Datenbank zu Behinderungskompensierenden Techniken für Computer im Allgemeinen und Internet im Speziellen. Im englischsprachigen Raum gibt es das hervorragende Angebot »My Web My Way«, das von AbilityNet zusammen mit der BBC erstellt wurde. Hier finden Sie einfach zu verstehende Anleitungen, wie die verschiedenen Betriebssysteme wie Windows, MacOS und Linux an die ganz speziellen persönlichen Bedürfnisse anzupassen sind.

Ein Beispiel für die Notwendigkeit, dass alle Beteiligten an einem Strang ziehen ist die leidige Debatte um Bemaßungen in Pixel. Gemäß WCAG ist die Deklaration von Schriftgrößen in px erlaubt, da es sich um eine relative Maßeinheit handelt. Als Gegenargument hört man dann, dass der Internet Explorer so gesetzte Schrift nicht skalieren könne – was nicht ganz korrekt ist: er kann es, die Option dazu ist nur sehr gut in den Einstellungen versteckt. Der Browser ist damit UAAG-konform. Aber wie viele Layouts, die auf Pixel setzen, sind in der Realität noch wirklich brauchbar, wenn man die Schrift auf Extragroß stellt? Verwenden stark sehbehinderte Nutzer nicht ab einem gewissen Grad der Sehbehinderung eine spezielle Lupensoftware, mit der diese ganze Debatte zumindest für sie überflüssig wird?

Wie sie sehen kann eine vollkommen barrierefreie Web-Nutzung nur dann möglich sein, wenn alle Beteiligten zusammenarbeiten.

So, das war die vierundzwanzigste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. In der nächsten Folge schauen wir uns mal etwas detaillierter an, wie man die Ideen des Barrierefreien Webdesigns in Arbeitsabläufe integrieren kann. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter dem Tag BITV, WCAG, ATAG und UAAG. Bis zum nächsten Mal.