Re: Barriere freier Zugang zu elektronischen Medien

[daniel _at__ roedding.de (Daniel Roedding)]

Hallo,

> Klaus Graf <graf _at__ uni-koblenz.de> writes:
> > Doch wenn es Ihnen und unserer Gesellschaft ernst ist mit der
> > beruflichen und sozialen Integration behinderter Menschen, dann sind die
> > "Web accessibility" Standards heute schon beinahe ebenso wichtig wie die
> > Regeln für rollstuhlgängiges Bauen!

Kai Eichwalder schrieb:
> Die Befolgung der "Web Accessibility"-Standards vereinfacht das
> Gestalten der Webseiten nach einer kurzen Einarbeitungsphase enorm --
> auf einmal zeigt sich dann nämlich, dass man keine besonderen Tricks
> für bestimmte Browser mehr braucht, der HTML-Code insgesamt kürzer und
> besser wartbar wird, egal ob man HTML manuell oder irgendwie maschinell
> erzeugt.

Als die Diskussion um die neue Richtlinie in den letzten Wochen durch
die Medien geschwappt ist habe ich mir mal "Bobby" und die Dinge, die
so vom W3C geschrieben wurden, angeschaut.

Aus technischer Sicht habe ich ein ambivalentes Gefühl dabei.

Das W3C versucht, unter dem Mäntelchen der Barrierefreiheit alle
auf die neue (X)HTML-Version und verstärkten CSS-Einsatz umzuerziehen.
Das ist mit Blick auf eine Strukturtrennung Layout/Content vordergründig
sinnvoll. Übersehen wird aber, daß die Seitendarstellung am Client
in der Regel um so langsamer wird, je mehr CSS im Spiel ist. Auch für
die Browserstabilität ist zu viel CSS nicht unbedingt zuträglich.

In der Praxis kann es teilweise günstiger sein, mit klassischen
"Stütztabellen" im HTML-Text zu arbeiten, als eine aufwendige Objekt-
gliederung einzufügen und diese dann auf der CSS-Seite durchzuparame-
trieren. HTML-Puristen bekommen dabei natürlich sofort einen Schrei-
krampf, "Bobby" jault auch laut auf, und dennoch können solche Seiten
durchaus "barrierefrei" und bildschirmgrößenunabhängig gebaut werden.

Einen vergleichbaren Glaubenskrieg gibt es auch bei der Frage, ob man
nun Frames haben möchte oder nicht. Die W3C-Jünger sagen, daß
Frames "deprecated" sein. In der Praxis führt aber ein sinnfälliger
Einsatz von Frames dazu, daß für alle die Ladezeiten geringer werden,
weil die Navigation nicht jedes Mal neu mitgeliefert werden muß.
Bei dynamischen Systemen kommt hinzu, daß die Menge an dynamisch zu
generierenden Daten auch über die Serverlast und damit die Gesamt-
performance bestimmt: Web-Anwendungen, bei denen jede Seite volldynamisch
generiert wird, brauchen bei "frame-loser" Realisierung mehr
Serverpower und mehr Übertragungsbandbreite als ein mit Frames
realisiertes Pendant. Wer es nicht glaubt, möge sich mal eine
Website wie www.spiegel.de oder www.handelsblatt.com anschauen und
jeweils im Quelltext den Prozentsatz für "Navigation" und "Content"
ermitteln.

Technisches Fazit: Eine Spur an gesundem Menschenverstand, ein
Kontrollblick mit abgeschalteten Grafiken und ein Nachmittag mit einem
Text-only-Browser (lynx, w3m, ...) haben bezogen auf "Barrierefreiheit"
mehr Aussagekraft als die ganze religiös angehauchte Markup-Level-
Grundsatzdiskussion.

Es ist möglich, Seiten "barrierefrei" zu gestalten, bei denen ein
"Bobby" einen Herzinfarkt bekommt. Umgekehrt kann man auch Seiten
bauen, die mühelos durch "Bobby" durchlaufen, dafür aber keineswegs
von einem Blinden navigierbar sind, oder bei denen sogar jeder
Browser einfach deterministisch vor die Wand fährt...

Fazit: Ich halte es für verfehlt, Barrierefreiheit und CSS/XHTML-
Politik in einen Topf zu werfen. Die Kopplung einer technischen
Richtlinie an eine Sachrichtlinie, wie es hier gerade versucht wird,
kann ich nicht unterstützen.

Viele Grüße,
Daniel Rödding



-- 
Daniel Roedding                                       phone: +49 5252 9838 0
daniel _at__ roedding.de                                      fax: +49 5252 9838 20