accessCast

Am Mikrofon heute Manfred »majo« Heinze, Links zum Selberdrücken gibt's wie immer in der Mitschrift.

Der Text ist als Artikel im Adventskalender der Webkrauts erschienen, wo bis zum 24. Dezember jeden Tag ein neues Türchen zu Themen wie Webstandards, Content Management, Barrierefreiheit, Web 2.0 usw. aufgemacht wird. Einige Artikel werden wir hier in loser Folge auch als Podcast veröffentlichen - heute gibt es einen Artikel von Tomas Caspers zum Thema:

Barrierefreiheit 2.0 – heute die Altlasten von morgen vermeiden

Ein gemeinsamer Nenner aller Dinge, die als Web 2.0 durchs Netz geistern ist ein Mehr an Dynamik, ein Mehr an Interaktion des Nutzers mit dem Angebot und darüber hinaus mit anderen Nutzern: das Lesen-Schreiben-Ausführen-Web. Will man die Barrierefreiheit von dynamischen, Web-basierten Anwendungen sicherstellen, dann stößt man schnell an die Grenzen der Richtlinien.

Die geltenden Richtlinien für barrierefreie Webinhalte, die WCAG 1.0 des W3C bestehen nun schon seit beinahe sieben Jahren in unveränderter Form. Ein Nachfolger ist zwar in der Entwicklung, der Zeitpunkt der Fertigstellung steht jedoch in den Sternen. Da wundert es nicht, dass die Web Content Accessibility Guidelines in der Version 1.0 für viele Dinge im Web 2.0 nicht anwendbar sind oder modernere Techniken wie sauberes DOM-Scripting sogar effektiv unmöglich machen, auch wenn diese für die Erstellung Web-basierter Anwendungen zwingend nötig sind.

Dieses Manko kann man den Richtlinien nicht zum Vorwurf machen; stammen sie doch aus einer Zeit, als das Web größtenteils aus, wie es im W3C-Sprech so schön heißt, »strukturierten Dokumentensammlungen« bestand. Für Websites, die lediglich aus statischen Inhalten ohne Interaktionsmöglichkeiten für den Nutzer bestehen sind die Richtlinien, wenn auch mit gewissen Abstrichen, nach wie vor anwendbar.

Rückwärtsgang oder Vorwärtsgang?

Das Web und die verwendeten Techniken haben sich jedoch seit Inkrafttreten der Richtlinien massiv weiterentwickelt. Das vom W3C auch schon mal als »worst invention ever« bezeichnete JavaScript hat in den letzten zwei Jahren eine phänomenale Wandlung vom Pfuiwort zu einer allgemein anerkannten Technik für die Erstellung von Web-basierten Applikationen hingelegt. Wer hätte gedacht, dass man mittlerweile Flash zusammen in einem Satz mit Barrierefreiheit erwähnen darf? Das Programm hat sich von einer verpönten Spielwiese zu einem ernstzunehmenden Werkzeug für die Erstellung zugänglicher Rich-Media-Inhalte gemausert. Der englische Accessibility-Experte Mike Davies meint dazu: »Its time to admit, Flash is part of the web accessibility toolbox.«

Auch die von Menschen mit Behinderung vielfach eingesetzten Hilfsmittel sind längst dem unzureichenden Stand der Technik entwachsen, denen die »Until User Agents…«-Klauseln der WCAG 1.0 begegnen sollten. Moderne Screenreader kommen mit zeitgemäßen Scripting-Techniken und auch mit barrierefrei aufbereiteten Flash-Inhalten sowie gut strukturierten PDF-Dokumenten sehr gut zurecht.

Wenn man dynamische Webinhalte mit echten Screenreader-Nutzern testet (und das ist dringend zu empfehlen – Barrierefreiheit ist keine Fingerübung im Abhaken von Checklisten), stellt man oft fest, dass die meisten Hürden gar nicht technischer Natur sind. Vielfach liegt es an einer Mischung aus konzeptionellen Mängeln im Angebot selbst und dem ungewohnten Umgang der Nutzer mit dynamischen Web-Applikationen, resultierend aus der Erwartungshaltung, dass das Web ein weitestgehend statisches Medium sei.

Der theoretische Part

Nach wie vor fordern die Richtlinien von den Anbietern dynamischer Inhalte, zusätzlichen Aufwand in parallele statische Versionen zu stecken, da die WCAG von Hilfsmitteln ausgehen, für die diese Techniken in der Tat ausgesprochen problematisch waren. Man beachte die Betonung auf »waren«. Staatliche Anbieter brauchen gar nicht erst versuchen, dieses Paradoxon aufzulösen – sie sind per Verordnung zur Einhaltung der Richtlinien verpflichtet:

BITV 6.2

Es muss sichergestellt sein, dass Äquivalente für dynamischen Inhalt aktualisiert werden, wenn sich der dynamische Inhalt ändert.

BITV 6.3

Es muss sichergestellt sein, dass mittels Markup-Sprachen geschaffene Dokumente verwendbar sind, wenn Scripts, Applets oder andere programmierte Objekte deaktiviert sind.

Privatwirtschaftlich organisierte Anbieter können sich jedoch der eigentlich spannenden Frage zuwenden: wie stellt man die direkte Zugänglichkeit von dynamischen Webinhalten sicher?

Aus Sicht der Anbieter wie auch aus Sicht der Nutzer scheint der Einsatz lange verpönter Techniken wie AJAX sinnvoller als die von den Richtlinien eingeforderten statischen Alternativen. Die verlangten statischen Alternativen sind zudem in Zeiten von Google Office, Excel 2007, Basecamp und .Mac Webmail keine wirkliche Alternative mehr, sondern fördern eher noch die digitale Spaltung, wenn sie nicht sogar konzeptionsbedingt unmöglich sind.

Der Praxisteil

Nehmen wir ein erdachtes, aber durchaus realistisches Szenario: bei einem bekannten Internet-Auktionshaus laufen gleichzeitig tausende Auktionen ab; gleichzeitig wollen zehntausende Bieter wissen, wie das aktuelle Höchstgebot ist. Die Seiten, die kurz vor Ablauf der Auktionen immer wieder neu geladen werden, sind, wie für dieses Auktionshaus typisch, eher etwas zu groß geraten. Das Auktionshaus hat also ein permanentes Problem mit der Serverlast, die Nutzer haben ein permanentes Problem mit den Antwortzeiten des Servers. Und das alles nur, um zu erfahren, ob sich eine vielleicht vierstellige Zahlenfolge geändert hat und man nicht mehr der Höchstbietende ist.

Alleine aus einer simplen Abwägung von Kosten und Nutzen heraus ist es sowohl für das Auktionshaus wie auch für dessen Nutzer ist hier der Einsatz von AJAX oder ähnlichen Techniken sinnvoll. Das jeweils aktuelle Höchstgebot wird in Echtzeit per Skript ausgetauscht, ohne das jedes Mal die kompletten Seiten neu geladen werden. Die von den WCAG eingeforderte statische Alternative gibt es weiterhin (weil ja schon vorhanden) und die Richtlinien zu Barrierefreiheit sind damit (zumindest auf dem Papier) erfüllt.

Dumm nur:
mit der statischen Alternative gewinnt man keine Auktion mehr, da diese zwar WCAG-konform ist, aber damit auch langsamer.

Das Fazit

Tests der WaSP Accessibility Task Force haben ergeben, dass Screenreader nahezu die gleichen Probleme mit Änderungen in Seiten oder Anwendungen haben, egal ob sie dynamisch erfolgt sind oder durch einen kompletten Neuaufbau der Seite. Die Ursache der Probleme scheinen also nicht dynamische Änderungen per Skript zu sein, sondern Änderungen generell.

Es kann eigentlich nur im ureigensten Interesse der Nutzer assistiver Hilfsmittel wie Screenreader, Lupenprogrammen etc. sein, dass Ihre Schnittstellen ins Web 2.0 dessen Möglichkeiten auch vollständig ausnutzen, sie korrekt umsetzen und so eine gleichberechtigte Teilnahme von Menschen mit Behinderungen ermöglichen.

Um dies zu erreichen muss sich die Erkenntnis durchsetzen, dass die Web Content Accessibility Guidelines des W3C lediglich ein Drittel der Richtlinien zur Barrierefreiheit ausmachen. Auch die User Agent Accessibility Guidelines (UAAG) und insbesondere die Authoring Tools Accessibility Guidelines (ATAG) sind ebenso wichtig, um das umfassende Ziel eines barrierefreieren Web 2.0 zu erreichen.

Wenn jedoch weiterhin die gesamte Verantwortung auf die Webentwickler abgewälzt wird, die mit Interimslösungen ihren Redaktionssystemen, Autorenwerkzeugen, aber auch den Browsern und Hilfsmitteln auf die Sprünge helfen müssen, die sich ihrerseits nicht im mindesten an die Standards halten, dann werden damit die Altlasten von morgen geschaffen. Und Interimslösungen können, wie wir alle wissen, ziemlich langlebig sein…

So, das war mal wieder eine Ausgabe unseres accessCast. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von Einfach für Alle unter den Tags Barrierefreiheit, JavaScript, Hilfsmittel und Web 2.0.