Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Barrierefreiheit 2.0 – heute die Altlasten von morgen vermeiden

Wir haben noch nicht alle älteren Artikel nachbearbeitet. Das bezieht sich in der Regel nur auf die Codebeispiele, die noch nicht optimal dargestellt werden.

Barrierefreiheit 2.0 – heute die Altlasten von morgen vermeiden

Keine Frage, das Web wird deutlich dynamischer, Websites setzen immer häufiger auf DOM-Scripting oder AJAX. Die Richtlinien für Barrierefreiheit hinken der Technik jedoch hinterher. Tomas Caspers beleuchtet sieben Jahre alte Regeln im Zusammenspiel mit dem Web 2.0.

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…

Weiterlesen:

Kommentare

Christian Vogt
am 15.12.2006 - 14:45

Das Beispiel ist wirklich angebracht.
Ich finde die Verwendung solcher Applikationen auf vielen Seiten durchaus angebracht, aber auf der anderen Seiten gibt es auch viele Funktionen die ich als typischer Purist nicht wirklich Sinnvoll finde, da slidet es hier und swoosht da, und warum? Weil der Entwickler seinem Kunden/dem Besucher zeigen wollte was er drauf hat.

Schöner Artikel jedenfalls :-)

Permanenter Link

Bernhard
am 15.12.2006 - 19:10

Gibt es nicht vielleicht irgendwelche Möglichkeiten, Dinge, die den zentralen Inhalt einer Seite bilden und regelmäßig aktualisiert werden (Gebotspreise, News) auszuzeichnen, beispielsweise über Mikroformate?
Ansonsten wäre das vielleicht eine Idee für ein weiteres Anwendungsgebiet.
Oder noch besser wäre natürlich etwas, das direkt vom W3C in XHTML 2 implementiert wird.

Bei dem Auktionsbeispiel könnte man eine statische Variante anbieten, die nicht viel mehr als den Preis und ein Formular zum erneuten Bieten zur Verfügung stellt.
Wenn man sich etwas Gedanken macht, sollte es schon möglich sein, brauchbare Alternativen zu den AJAX-Varianten anzubieten.

Permanenter Link
Sylke Wienold

Sylke Wienold
am 16.12.2006 - 12:11

Schöner Artikel - wie immer. Ein bisschen stört mich aber, dass auch hier immer vom neuesten und modernsten ausgegangen wird. Beispielsweise: "Moderne Screenreader...." KLar, die könnens! Wer von den Betroffenen kann sich so ungefähr immer dann, wenn es neue Techniken zu unterstützen gilt einen neuen Screenreader leisten?
Und auch wenn man mal einfach von Barrierefreiheit im eigentlichen Sinne ausgeht - nicht jeder ist gleich vollblind und braucht wirklich einen Screenreader - die meisten neuen Seiten werden vollgestopft mit unübersichtlich angeordneten Informationen. Fast unüberwindlich für alle Leute die weniger als zwei Stunden täglich am Rechner verbringen. Und da bringt die allerschönste allerneueste Technik nichts.

Permanenter Link

Susanna Künzl
am 16.12.2006 - 17:07

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.

Da hier ein erfolgversprechender Ansatz ist, kann man sich nur wünschen, dass alle die, die nicht durch Gesetzesvorschriften zur wortwörtlichen Umsetzung der BITV gezwungen sind, innovative Kontepte entwickeln. Dennoch bleibt das Argument bestehen: Wer kann sich die neuesten Versionen der Tools leisten (Kasse zahlt nicht so oft wie man das wünscht)? Und nicht jeder hat den Nerv, auf Linux umzusteigen. Sollten die Webentwickler vielleicht mehr Zeit in die Information fu alternativen Betriebssystemen stecken, statt wieder mal zu versuchen, das Unmögliche für möglichst viele möglich zu machen?

Permanenter Link

alexander farkas
am 17.12.2006 - 14:55

flash und barrierefreiheit stecken wohl noch in den kinderschuhen und mir ist nicht klar, wann eine flashseite als barrierefrei gelten kann.

ein vergleich mit javascript:
javascript gilt ja nur dann als barrierefrei, wenn die verwendende seite 1. bei javascript-einsatz eingabe- und ausgabeunabhängig bleibt und 2. die seite bei ausgeschaltetem javascript weiterhin funktioniert.

auf flash übertragen müsste dass aber bedeuten, dass die flash-seite nicht nur eingabe-/ausgabe-unabhängig ist, sondern auch ohne flash funktioniert. gerade dass wird von denjenigen, die flash und zugänglichkeit miteinander vereinbaren wollen, nicht gefordert.

angesichts der tatsache, dass flash im vergleich zu javascript seltener vorausgesetzt werden kann, halte ich das aber für widersprüchlich. was haltet ihr davon?

ich muss zugeben, dass ich von flash nicht viel verstehe, aber meines wissens nach, kann man flash so "programmieren", dass es mit css und javascript vergleichbar ist und die informationen getrennt hiervon beispielsweise als xml abgelegt sind. von dort aus könnten die infos entweder in die flash-oberfläche gezogen oder in rudimentäres html gewandelt werden.

wenn man zusätzlich bedenkt das inhalte einer flash-seite - soll falsh eine zukunft haben - mit einem cms editierbar sein sollten, ist eine derartige trennung, wie sie bei den alten/herkömmlichen websprachen (html, css und js) gefordert/benutzt wird, gar nicht so weit hergeholt.

Permanenter Link

/T
am 18.12.2006 - 11:05

@Bernhard:

»Gibt es nicht vielleicht irgendwelche Möglichkeiten, Dinge, die den zentralen Inhalt einer Seite bilden und regelmäßig aktualisiert werden (Gebotspreise, News) auszuzeichnen, beispielsweise über Mikroformate?«

Ich fürchte, so etwas ginge weit über den sinnvollen Einsatzzweck von Mikroformaten hinaus. Zumal damit das Problem nur verlagert würde, denn auch hier bräuchte man eine breite Unterstützung durch die diversen User Agents, die das alles auswerten und präsentieren sollen. Wenn ich mir ansehe, dass verbreitete Screenreader auch im Jahr 2006 immer noch nicht den vollen Umfang von HTML 4 (geboren am 18. Dezember 1997, also genau heute vor neun Jahren!) untestützen, dann beschleichen mich arge Zweifel...

Permanenter Link

/T
am 18.12.2006 - 11:18

@Sylke:

»Wer von den Betroffenen kann sich so ungefähr immer dann, wenn es neue Techniken zu unterstützen gilt einen neuen Screenreader leisten?«

Genau für diesen Zweck bekommen Nutzer zum Beispiel Blindengeld. Und wenn der Screenreader im Rahmen einer beruflichen Tätigkeit benötigt wird, dann besteht ein Anspruch auf regelmäßige Updates, die zudem nicht wirklich teuer sind (besonders wenn man die Update-Kosten im Verhältnis zu den Gesamtkosten eines blindengerechten Arbeitsplatzes betrachtet, die auch regelmäßig von den Integrationsämtern übernommen werden müssen).

Für die private Nutzung muss es hingegen nicht immer gleich ein Expertensystem wie das des Marktführers sein, hier gibt es mittlerweile durchaus ernstzunehmende Alternativen im (kostenlosen) OpenSource-Bereich. Zudem es mit dem Erscheinen von Vista kein aktuelles Betriebssystem mehr gibt, was keine Sprachausgabe mehr ab Werk mit an Bord hätte

Permanenter Link
Tomas Caspers

Tomas Caspers (Autor)
am 18.12.2006 - 11:37

@alexander farkas:

»flash und barrierefreiheit stecken wohl noch in den kinderschuhen und mir ist nicht klar, wann eine flashseite als barrierefrei gelten kann.«

Jein. Das mit den Kinderschuhen ist nicht ganz korrekt. Barrierefreiheit und Flash ist zumindest seit Flash v.5 im Bereich des theoretisch Möglichen. In den folgenden Versionen wurde die Zugänglichkeit immer weiter verbessert, nicht zuletzt dank der unermüdlichen Arbeit von Leuten wie Andrew Kirkpatrick und Bob Regan, die ja auch mit zu Adobe gegangen sind. Seit ca. den Versionen 7-8 kann man wirklich zugängliche Inhalte in Flash erstellen, die auch für halbwegs moderne Hilfsmittel sehr gut nutzbar sind.

Natürlich gilt auch hier die Einschränkung, dass dazu der Entwickler wissen muss was er tut, aber das gleiche gilt für sämtliche andere Formate ja auch, inklusive HTML (mit dem man, wie wir alle wissen, auch so richtig schön viel Bockmist machen kann). Dass es geht hat ja gerade die Firma Pfizer bei der BIENE 2006 vorgeturnt.

»javascript gilt ja nur dann als barrierefrei, wenn die verwendende seite 1. bei javascript-einsatz eingabe- und ausgabeunabhängig bleibt und 2. die seite bei ausgeschaltetem javascript weiterhin funktioniert.«

Das ist Barrierefreiheit 1.0. Der Artikel hier handelt aber von der Version 2.0, also der direkten Zugänglichkeit von dynamischen Webinhalten auch und speziell für die Hilfsmittel behinderter Menschen. Das muss das Ziel sein, alles andere würde wieder nur in eine Zwei-Klassen-Gesellschaft führen...

Permanenter Link

alexander farkas
am 18.12.2006 - 12:16

@tomas

Das ist Barrierefreiheit 1.0. Der Artikel hier handelt aber von der Version 2.0...

d.h. man kann JavaScript als "must-have" definieren und ist weiterhin barrierefrei?

Permanenter Link
Tomas Caspers

Tomas Caspers (Autor)
am 18.12.2006 - 12:48

Nach den Regeln der kommenden (?) WCAG 2.0 sowieso, hier gibt es das (neue) Konzept der sogenannten »Baselines«, also Mindesttechnologien, die man für die sinnvolle Nutzung eines Angebots voraussetzen darf. Wenn man sowas in seine »baseline assumption« reinschreibt und dann natürlich auch die Regeln für modernes Skripting berücksichtigt, ja, dann darf man das Resultat auch barrierefrei nennen.

Permanenter Link

Gerhard
am 20.12.2006 - 22:02

Javascript wird von vielen Browsern nicht oder nur teilweise unterstützt und ist daher meiner Meinung nach allerhöchstens für Spielereien geeignet. Ein nur für einige Browser verfügbares Plugin vorauszusetzen halte ich für alles andere als barrierefrei.

Permanenter Link

Tomas Caspers
am 21.12.2006 - 16:35

»Javascript wird von vielen Browsern nicht oder nur teilweise unterstützt«

Stimmt, so zum Beispiel in Netscape 1.1. Oder Internet Explorer 2. Und natürlich in den beiden am weitesten verbreiteten Webbrowsern Amaya und Lynx.

Nur der Vollständigkeit halber:
* HTML wird von vielen Browsern nur teilweise unterstützt
* XHTML wird von vielen Browsern nur teilweise unterstützt
* CSS wird von vielen Browsern nicht oder nur teilweise unterstützt
* PNG wird von vielen Browsern nicht oder nur teilweise unterstützt
* ...

Also »allerhöchstens für Spielereien geeignet?

Permanenter Link

alexander farkas
am 21.12.2006 - 17:48

dazu verlier ich mal paar worte:

die oben genannte baseline alte ich auch für problematisch, da ich glaube, dass keine sinnvolle begrenzung stattfindet. welche technologien vorausgesetzt werden können, sollte von 3 dingen abhängen:

1. wie nötig ist diese technologie um dieses "feature" umzusetzen
2. wie gut wird diese technologie (auch von aktuellen assistiver software/hardware) unterstützt.
3. was passiert, wenn die technologie nicht vorhanden ist? (fällt das [inhaltliche] angebot komplett weg, nur teilweise oder bezieht sich die technologie nur auf spielereien und/oder sinnvolle, aber nicht inhaltliche, zusatzfeatures)

zu javascript: ich kenne keinen der mit einem browser surft, welcher javascript nicht oder sehr schlecht unterstützt. ebenfalls kenne ich keinen der javascript ausgeschaltet hat.

Permanenter Link

alexander farkas
am 21.12.2006 - 17:56

ach ja, die 3 punkte, die ich oben genannt habe, sind keine "k.o.-punkte" sondern sollten gegeneinander abgewogen werden.

Permanenter Link

Die Kommentare sind geschlossen.